# ;; -*- mode: org; coding: utf-8 -*-

#+TITLE: Guile-CV NEWS

#+BEGIN_COMMENT

Copyright (C) 2016 - 2018
Free Software Foundation, Inc.

This document is part of GNU Guile-CV.

Copying and distribution of this file, with or without modification, are
permitted in any medium without royalty provided the copyright notice
and this notice are preserved.  This file is offered as-is, without any
warranty.

#+END_COMMENT


               Guile-CV - History of user-visible changes
               ==========================================

                  Please send Guile-CV bug reports to

                          bug-guile-cv@gnu.org


* Latest News

** April 2018

Guile-CV version 0.1.9 is released.

** Changes since 0.1.8

Here is a summary of visible changes since version 0.1.8. See GNU
Guile-CV's [[http://git.savannah.gnu.org/cgit/guile-cv.git][git summary]] and [[http://git.savannah.gnu.org/cgit/guile-cv.git/log/][git log]] for a complete description.

*** Dependencies

Vigra C >= commit a2ff675f4 April 15, 2018

  new interface vigra_nonlocalmean_c (introduced in Jan 2018), has an
  argument that has been renamed;

  the vigra_medianfilter_c function (updated in Jan 2018 as well) takes
  an additional 'out-of-bound strategy' argument.

*** New interfaces

im-median-filter
im-median-filter-channel
im-nl-means
im-nl-means-channel

*** Bug fixes

latex-pdftoppm

  in the module (cv support latex) - undocumented but quite usefull
  procedure, to 'prepare' text to be added to images (see im-compose) -
  the optional keyword [#:res 72] argument was actually not used in the
  core of the procedure, fixed.


* Older News

** December the 18th, 2017

Guile-CV version 0.1.8 is released!

Here is a summary of the changes since version 0.1.7. See GNU Guile-CV's
git summary [1] and git log [2] for a complete description:

	[1] http://git.savannah.gnu.org/cgit/guile-cv.git
	[2] http://git.savannah.gnu.org/cgit/guile-cv.git/log/

*** 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 wether 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 confortable 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 prety confident that it will happen, maybe not tomorrow, but it
  will happen.

**** Bug fixes

** October the 23rd, 2017

Guile-CV version 0.1.7 is released!

Here is a summary of the changes since version 0.1.6. See GNU Guile-CV's
git summary [1] and git log [2] for a complete description:

	[1] http://git.savannah.gnu.org/cgit/guile-cv.git
	[2] http://git.savannah.gnu.org/cgit/guile-cv.git/log/

*** Changes since 0.1.6

**** Dependencies

Vigra C >= commit a38f361 Sep 18, 2017

  That commit introduces - kindly implemented by Benjamin Seppke upon
  our request - the following new features: centre of mass, perimeter,
  skewness, kurtosis.

**** Interface changes

im-save
im-show

  Adding an optional (scale #f) argument.  Till now, images pixel values
  would be always scaled at save time, unless saving the file using tif.
  This was really less then optimal because (a) tif preserves values,
  but no image viewer knows how to display these Guile-CV 32 bits float
  images (they beleive these are RGBA images) and (b) scaling at save
  time totally destroyed the results of im memory calcuations ... What we
  really want here, most of the time at least, and hence it becomes the
  default from now on, is what is called 'clipping': pixel values are
  ‘clipped’, which means that values < 0 are saved as 0, values > 255
  are saved as 255, and otherwise are saved unchanged.

im-invert
im-channel-invert
f32vector-invert
f64vector-invert

  Previously, these procedures were using the name 'inverse', but that
  was not 'optimal', fixed.

**** New interfaces

k-make
k-make-circular-mask
k-size
k-width
k-height
k-channel
kernel?
k-ref
k-fast-ref
k-set!
k-fast-set!
k-offset
k-fast-offset
k-display
im-convolve
im-convolve-channel
im-gaussian-sharp
im-gaussian-sharp-channel
im-sharpen
im-sharpen-channel

%pi
%2pi
%pi/2

**** New features

**** New GRAY features

major-ev-x major-ev-y minor-ev-x minor-ev-y
major-axis minor-axis angle
center-mass-x center-mass-y
perimeter
skewness kurtosis
circularity aspect-ratio roundness

**** New RGB features

major-ev-x major-ev-y minor-ev-x minor-ev-y
major-axis minor-axis angle
center-mass-x center-mass-y
perimeter
skewness-r skewness-g skewness-b
kurtosis-r kurtosis-g kurtosis-b
circularity aspect-ratio roundness

**** Bug fixes

im-set!
im-images?

  both procedures have been 'relaxed' and do not check anymore that
  either the value or pixel values respectively are in the [0 255]
  range, as doing so was actually incorrect: images need to be
  normalized and scaled (as in bringing their pixel values in the [0
  255] range) only to be displayed, but otherwise, their should be no
  such limitations.

im-binary?

  was returning #f for BLACK and WHITE images, so either composed of
  eiher 0.0 or 255.0, fixed.

** August the xx, 2017

Guile-CV version 0.1.6 is released!

Here is a summary of the changes since version 0.1.5. See GNU Guile-CV's
git summary [1] and git log [2] for a complete description:

	[1] http://git.savannah.gnu.org/cgit/guile-cv.git
	[2] http://git.savannah.gnu.org/cgit/guile-cv.git/log/

*** Changes since 0.1.5

**** Interface changes

im-normalize
im-normalize-channel:

  Adding an optional #:key (val 255.0), since we need to be able to
  normalize to specific values in some circumstances, such as, for
  example, to normalize gray level co-occurrence matrices.

f32vector-reduce:

  The arguments order has been changed for 'vector proc default' not
  'proc default vector', because it is the order we use in im-reduce and
  im-reduce-channel - as [almost] all other im-* procedures or methods
  take an image as their first argument.  As a user, it is also a bit
  more naturel, imo at least, to 'reduce image using proc, return
  default if the image is empty'.

im-add
im-add-channel
im-subtract
im-subtract-channel
im-multiply
im-multiply-channel
im-divide
im-divide-channel:

  All linear algrebra matrix methods now accept any number of images or
  channels.  Note that due to the inherent checks between lines and
  columns of internediate results, im-multiply-channel and
  im-divide-channel methods arguments must be a series of at least one
  tuple(s) composed of three values - channel width height - represented
  in the manual as: c1 w1 h1 c2 w2 h2 c3 w3 h3 …

im-collect:

  Updated so its interface is 'identical' to im-map and friends, and a
  tipical call now looks like:  im-collect what i1 i2 i3 … (instead of
  im-collect images what).

**** New interfaces

im-range
im-range-channel
im-min
im-min-channel
im-max
im-max-channel
im-map
im-map-channel
im-reduce
im-reduce-channel
f32vector->s32vector
f32vector-range
s32vector-range
s32vector-min
s32vector-max
s32vector-reduce
s32vector->f32vector


**** Bug fixes

im-normalize:

  the width and height of the result normalized image were inadvertently
  inverted, now fixed.

f32vector-matrix-multiply:

  the sub results were inadvertently using 'n' instead of 'p' to compute
  their destination position in the 'n x p' cells returned result
  f32vector, now fixed.

** July the 24th, 2017

Guile-CV version 0.1.5 is released!

Here is a summary of the changes since version 0.1.4. See GNU Guile-CV's
git summary [1] and git log [2] for a complete description:

	[1] http://git.savannah.gnu.org/cgit/guile-cv.git
	[2] http://git.savannah.gnu.org/cgit/guile-cv.git/log/

*** Changes since 0.1.4

**** Interface changes

dark -> black
light -> white

  both in the source code (optional kw default values)
  and in the documentation

**** New interfaces

im-delineate
im-delineate-channel
im-distance-map
im-distance-map-channel
im-canny
im-canny-channel
im-xor
f32vector-xor-at-offset

**** Bug fixes

Import export test-suite
Error message for im-gaussian-gradient
Documentation typo fixes
Histogram gray legends below their histogram

** May the 23rd, 2017

Guile-CV version 0.1.4 is released!

	This is the first public release of Guile-CV, earlier releases
	were made available to GNU evaluators and Savannah hackers only.

Here is a summary of the changes since version 0.1.3.2. See GNU
Guile-CV's git summary [1] and git log [2] for a complete description:

	[1] http://git.savannah.gnu.org/cgit/guile-cv.git
	[2] http://git.savannah.gnu.org/cgit/guile-cv.git/log/

*** Changes since 0.1.3.2

New Dependencies
----------------

New (or earlier unspecified) dependencies:

	Makeinfo >= 6.3
	Latex
	  (any modern latex distribution will do)
	  documentclass:
		standalone
	  packages:
	        inputenc, fontenc, lmodern, xcolor, booktabs, siunitx,
		iwona

Incompatible API change:
------------------------

	im-properties:
		renamed im-features

	im-*grey* procedures and methods:
		renamed im-*gray*
		dito for arguments
		GREY -> GRAY in the documentation

	colour -> color
	COLOUR -> COLOR:
		both in the source code (arg and kw arg names)
		and in the documentation

	f32vector-* procedures
		use #:key, not #:optional

	im-padd
	im-padd-channel
		accept a #:color optional keyword argument

	f32vector-multiply
		renamed f32vector-matrix-multiply

New procedures:
---------------

	f32vector-inverse
	f32vector-reduce
	f32vector-mean
	f32vector-std-dev
	im-add
	im-add-channel
	im-subtract
	im-subtract-channel
	im-multiply
	im-multiply-channel
	im-divide
	im-divide-channel
	im-inverse
	im-inverse-channel
	im-compose
	im-compose-channels
	im-particles
	im-particle-clean
	im-histogram

** March the 12th, 2017

Guile-CV version 0.1.3 is released, the next maintenance release for
the 0.1 series.

*** Changes since 0.1.2

Updating headers for a non GNU project style.

Guile-CV is under evaluation to see whether it will be part of GNU.  We
have just been informed that the evaluation is going to take some time:
fine, but we wantto make the project public right now, hence this
release, so the Savannah folks can start the nongnu evaluation.

** March the 9th, 2017

Guile-CV version 0.1.2 is released, the next maintenance release for
the 0.1 series.

	Special note:
	-------------

	The special note written for Guile-CV version 0.1.1 is still
	applicable to this release, see below.

*** Changes since 0.1.1

New procedures:
---------------

	im-copy-channel, im-properties, im-scrap

** Februrary the 18th, 2017

Guile-CV version 0.1.1 is released, the next maintenance release for
the 0.1 series.

	Special note:
	-------------

	(a) that this release is not made 'public' yet, because it is
	still under evaluation to see whether it will be part of GNU or
	not: if yes, fine; if not, I would need to change all
	occurrences of 'Guile-CV' to 'Guile-CV' and all copyright
	notices from 'Free Software Foundation, Inc.' to myself;

	(b) see INSTALL for tarball location during the evaluation
	period.

*** Changes since 0.1.0

Incompatible API change:
------------------------

	Fixing im-flip to refer to a plane rather then an axis: Vigra
    flips (their terminology is reflect, not flip) images and channels
    with respect to an axis, not by reference to a plane. In our
    opinion, this is [unnecessarily] confusing, so we decided to go
    ahead and fix this in Guile-CV.  See the manual (and commit ff62dfa
    for further details and if you are interested to read the source
    code modifications).

New functionality:
------------------

	im-load, im-save: support for RGBA images has been added

	support for image transposition and normalization

New procedures:
---------------

	im-rgba->rgb, im-rgba->grey

	im-transpose, im-transpose-channel, im-normalize,
	im-normalize-channel

	im-add, im-add-channel, im-substract, im-substract-channel,
	im-multiply, im-multiply-channel, im-divide, im-divide-channel

