Strange behavior in linear_stretch with HDRI (6.6.1-4)

[fmw42]

I think for an exact algorithm one should not use histograms but go straight into an array the size of the image. Note that since the array would only contain 1 value per pixel, instead of 3, of would only increase memory into 133% of the original image anyway.

Your concept would be exact. However, in my opinion, I don't think this is practical (too time consuming) as you have to sort the whole image by graylevel for each channel. That is why a histogram with bins is used to speed things up.

I am not a programmer, so would not know where to point you.

[rnbc]

Actually not on gray-level, but on both min-channels-level and max-channels-level.

Sorting an array of a few million elements is trivial, and at most you use as much space as the image itself, for grayscale images, or 1/3 as much for RGB.

[snibgo]

ImageMagick originated in the days when CPUs were measured in MHz not GHz, and memory in MB not GB. Perhaps an option could be added to IM to either:

(a) change the number of bins from 1024 to a user-defined number, say 1 million.
(b) not to use bins at all, but pixel values.


And I do like rnbc's idea of an option that changes the definition of "clipping" (both burn and black-out) from "luminance" (or whatever IM currently uses) to "any colour channel".

[fmw42]

-contrast-stretch can work channel by channel. it is -linear-stretch that works either on all channels together or on luminance. It has been too long since I did quite some research on this to remember. As I said before, Anthony and I have had numerous discussions about some better algorithm that takes the best of both techniques. But he has not had time to implement anything. But the more discussion now the better, before anything is implemented.

[rnbc]

As I said I will give it a try.

My main problem right now is I'm doing a university work in HDR image processing, besides my regular daytime job. So I'm a bit short on time... but if I can get some time to understand ImageMagick's framework I'll implement this before September. Otherwise it will have to wait a few months...

Thanks for the ideas!

[anthony]

First. the -auto-level and -auto-gamma are part of a set of new functions that will eventually replace the current invocations of the -normalize, -contrast-stretch -linear-stretch all of which were ill defined and difficult to understand, exactly what they did.

What I want to see is a more 'generalised' handling where the various options and methods
can be controled more exactly.

The new functions were going to be named -histogram ???? methods, and were going to make maximum use of 'level' style stretching (for accuracy), with minimal use of histogram binning for reassigning colors. They would also make use of extra 'channel swicthes'

Some notes about this was given in..
http://www.imagemagick.org/Usage/bugs/f ... auto-level
Though these are not my core notes.

The -auto-level operator makes direct use of the exact 'maximum and minimum values' without resorting to the use of 'histogram bins', making it a more 'mathematically correct' normalization.
It also made use of a 'new' channel switch called 'sync', which by default is turned on.
For example
-channel RGB,sync -auto-level

When 'sync' is enabled, operators that understand this flag would adjust all color channels in sync, that is in the same way.

I am planing to make ALL histogram operators understand this flag, as well as other options to provide the more exact controls that was needed.

I had planned to work on this during the new year break, but morphology got my attention instead.
I just never seem to get time otherwise, and lack of people programming IM is the major problem.




Internally, all histogram function should be added to and moved into the 'histogram.c' module. However it seems Cristy has added many functions into this module, which I don't know about, but seems to be histogram generator functions.

Before this functions were placed in the module 'enhance.c' which is also where the normalize and 'level' functions live.

The function MinMaxStretchImage() is what performs the actual 'auto-level' operation, and for 'color percentage' clipping of the histogram.

[rnbc]

I had planned to work on this during the new year break, but morphology got my attention instead.
I just never seem to get time otherwise, and lack of people programming IM is the major problem.

I will definitely try to help once I have time!

I think some of these functions don't need histograms to work, and will in fact be more accurate and possibly faster if you just copy&order the array of pixel values and use the ordered array to extract needed values. This uses more memory, that's a given, but memory is cheap nowadays.