Image Processing and Analysis in Guile
a Computer Vision functional programming library
That commit introduces - kindly implemented by Benjamin Seppke upon our request - the following new features: centre of mass, perimeter, skewness, kurtosis.
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.
Previously, these procedures were using the name 'inverse', but that was not 'optimal', fixed.
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.
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.
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.
was returning #f for BLACK and WHITE images, so either composed of eiher 0.0 or 255.0, fixed.
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.
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'.
All linear algebra matrix methods now accept any number of images or channels. Note that due to the inherent checks between lines and columns of intermediate 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 …
Updated so its interface is 'identical' to im-map and friends, and a typical call now looks like: im-collect what i1 i2 i3 … (instead of im-collect images what).
the width and height of the result normalized image were inadvertently inverted, now fixed.
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.
This is the first public release of Guile-CV, earlier releases were made available to GNU evaluators and Savannah hackers only.
packages: inputenc, fontenc, lmodern, xcolor, booktabs, siunitx, iwona
The GNU evaluation of Guile-CV has been completed on March the 11th, 2017, but due to backlog, we've been informed then that its approval step would take another five weeks, so we decided to upload it on Savannah non gnu in the mean time, done!
A couple of months ago, we started to work on Guile-CV, a Computer Vision functional library for the Guile Scheme language, and now is the right time for it to be evaluated to be part of the GNU Project.