GNU Guile-CV 0.1.8 released

GNU Guile-CV 0.1.8 released

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 8661 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]