[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNU Guile-CV 0.1.8 released
GNU Guile-CV 0.1.8 released
Sun, 17 Dec 2017 23:28:30 -0200
GNU Guile-CV 0.1.8 is released.
Guile-CV - Image Processing and Analysis in Guile - is a Computer Vision
functional programming library for the Guile Scheme language.
Based on Vigra (Vision with Generic Algorithms - a C++ image processing
and analysis library), Guile-CV comprises a direct binding to Vigra C (a
C wrapper to most of the Vigra functionality), enriched with pure Guile
scheme algorithms, all accessible through a nice, clean and easy to use
high level API.
Guile-CV is natively multi-threaded, and takes advantage of multiple
cores, using high-level and fine grained application-level parallelism
constructs available in Guile, based on its support to POSIX threads.
Here are the compressed sources and a GPG detached signature [*]:
This released was bootstrapped with the following tools:
-] gcc (Debian 7.2.0-17) 7.2.1 20171205
-] autoconf (GNU Autoconf) 2.69
-] automake (GNU automake) 1.15.1
-] libtool (GNU libtool) 2.4.6
-] makeinfo (GNU texinfo) 6.5
-] pdflatex 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian)
-] guile-2.2 2.2.3
-] guile-lib-1.0 0.2.5.1
-] vigra from the source, last commit here:
fb427440d - June 28, 2017
-] vigra_c from the source, last commit here:
691b189b0 - Oct 25, 2017
* Changes since 0.1.7
Vigra C >= commit 691b189b0 Oct 25, 2017
A clipping bug has been fixed in vigra_exportgrayimage_c,
vigra_exportrgbimage_c and vigra_exportrgbaimage_c. A new
vigra_clipimage_c function is available and Guile-CV uses it.
** Configuring Guile for Guile-CV
I finally got my hands on how to configure Guile's raised exception
system (special thanks to Daniel Lloren) so it does not 'blow' the repl
upon errors anymore, while using Guile-CV (or manipulating any other big
structures for that matters, huge lists, arrays, sfri-4 bytevectors
As a consequence, the manual has been updated and now covers both
Guile's repl-print and raised exception system configuration, either
globally, or individually: it is highly recommended for all users, even
those who are already using Guile-CV I mean, not just new users, to very
carefully read and apply these two recommendations.
** Interface changes
Previously, these two procedures were respectively named im-fill and
im-fill-channel, but that was a bit ambiguous.
New optional keyword, #:exclude-on-edges, for which the default is #f.
Return n-label, not n-object. The number of labels correspond to the
highest label value + 1: earlier version of Guile-CV, prior to version
0.1.8, did return the number of objects, which correspond to the
highest label value. This was less then optimal, since not only 0.0 is
a label, but other procedures, im-features for example, do consider
and return a feature object for the background as well.
Note that Vigra C functions return the label highest value, but the
vigra-label-all function starts to label using 1.0, so in this case,
the label highest value is also the number of label used, hence
im-label-all-channel has to return 'n-object' and not '(+ n-object
1)', fixed. I don't like this, for me it is inconsistent, and
im-label-all should start to label using 0.0 as well, so I mailed the
Vigra folks, let's see...
Consistency between im-label, im-label-all and im-features. All these
already named their argument 'n-label', but it actually ment 'n-object'.
I changed all this - and the segmentation related code as well - so it
is consistent everywhere in the code. And now, the n-label argument
value also correspond to the length of the list of features returned,
so much better.
Vigra C functions, at the contrary, expect 'n-object', or expressed
differently, expect the label highest value, which correspond to (-
n-label 1). This is also consistent everywhere in the code now.
Now accepts more then one image.
** New interfaces
Though undocumented still, I list it her too: we had and-l already,
and there are (well known among schemers) situations where you need a
function (not a macro)...
Composite images only differs to others in the sence that they can
have more then 3 channels, any number of channels actually, the 4th
_not_ being the traditional alpha channel. Each channel holds on
specific information, depending on the application domaim. It is
sometime necessary to visualize these though, in which case they must
be 'converted' to RGB images, hence this new procedure. This is a
'work in progress': as it is, it will only work if the composite image
has 4 channels. In this first implementation, the algorithm will
super impose the 4th channel to the RGB's, so one says 'white pixels
always win' (this because the 4th channel is (generally) associated
with the White 'color').
** Removed interfaces
It was a bad idea to make this internal procedure public, and users
can call (apply im-=? ...) anyway.
** Performance improvements
Calls im-rgb->gray-1, which was unnecessary calling float-round at
each step, and I also noticed that recursive tail call procedures have
a tiny penalty compared to loop, so rewrote both. Now, in addition,
both procedures will split their work in between as many core as
available, except if the parameter %use-par-map has been set to #f.
On my laptop - i5-2450M CPU @ 2.50GHz × 4 and 5.7GB of mem - both
procedures are now 3 to 4 times faster.
Labels are 'discrete' floats, by definition, so we can use = instead
of float=?, which is 3 to 4 times faster.
Area, left, top, right, bottom values are discrete floats, use
float->int, not float-round.
Till Guile-3.0 becomes available, I decided to temporarily rewrite the
math, linear algebra and logical 'low level' procedures in C. Tests
performed on my laptop - i5-2450M CPU @ 2.50GHz × 4 and 5.7GB of mem -
using GRAY and RGB test images of 2718 x 1732 show gains in the range
of 20x to 100x faster, depending on the operation and whether images
involved have 1 or more channels (though in Guile-CV, unless the user
sets the %use-par-map parameter to #f, all multi channel operations
are multi threaded).
Because all memory allocation still is done in scheme, and not in C, I
am very comfortable with this approach, as I said, till we have an AOT
compiler that compiles fixed size floating points and small integers
operations and vector loops for these that runs as fast as in C, and
I am pretty confident that it will happen, maybe not tomorrow, but it
** Bug fixes
* Bug reports
Please report bugs to address@hidden
* Mailing lists
For the time being, Guile-CV uses Guile's mailing list:
address@hidden is for general user help and discussion;
address@hidden is used to discuss most aspects of Guile-CV,
including development and enhancement requests.
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig
file and the corresponding tarball. Then, run a command like this:
gpg --verify guile-cv-0.1.8.tar.gz.sig
If that command fails because you don't have the required public
key, then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys A3057AD7
and rerun the 'gpg --verify' command
Description: OpenPGP digital signature
|[Prev in Thread]
||[Next in Thread]|
- GNU Guile-CV 0.1.8 released,
David Pirotte <=