Hello, GNU Guile-CV 0.1.8 is released. * About 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. http://www.gnu.org/software/guile-cv/ * Download Here are the compressed sources and a GPG detached signature [*]: http://ftp.gnu.org/gnu/guile-cv/guile-cv-0.1.8.tar.gz http://ftp.gnu.org/gnu/guile-cv/guile-cv-0.1.8.tar.gz.sig 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 ** Dependencies 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 im-fill-holes im-fill-holes-channel Previously, these two procedures were respectively named im-fill and im-fill-channel, but that was a bit ambiguous. im-scrap New optional keyword, #:exclude-on-edges, for which the default is #f. im-label im-label-channel im-label-all im-label-all-channel 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... im-features 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. im-binary? Now accepts more then one image. ** New interfaces im-clip im-clip-channel im-reconstruct im-and-channel im-or-channel im-xor-channel im-=-channel? im-binary-channel? or-l 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)... im-composite->rgb 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 im-list=? It was a bad idea to make this internal procedure public, and users can call (apply im-=? ...) anyway. ** Performance improvements im-rgb->gray im-threshold 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. im-fill-holes Labels are 'discrete' floats, by definition, so we can use = instead of float=?, which is 3 to 4 times faster. im-features Area, left, top, right, bottom values are discrete floats, use float->int, not float-round. im-min im-min-channel im-max im-max-channel im-range im-range-channel im-add im-add-channel im-subtract im-subtract-channel im-multiply (value) im-multiply-channel (value) im-divide (value) im-divide-channel (value) im-and im-and-channel im-or im-xor-channel im-or im-xor-channel im-=? im-=-channel? im-binary? im-binary-channel? im-rgb->gray im-fill-holes im-fill-holes-channel im-threshold im-reconstruct im-particle-clean 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 will happen. ** Bug fixes * Bug reports Please report bugs to bug-guile-cv@gnu.org * Mailing lists For the time being, Guile-CV uses Guile's mailing list: guile-user@gnu.org is for general user help and discussion; guile-devel@gnu.org is used to discuss most aspects of Guile-CV, including development and enhancement requests. David [*] 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