[ptx] Re: Re: Brightness/colour correction in pano12 and nona

[Gellule]

Thank you Rick,

Since both N_A and N_B are from integer to integer, there is certainly a 
need for randomization somewhere. To invert N_A, one can interpolate between 
the integer values. Then comes a question: is there a rule for the random 
distribution to use to interpret floating intensities to integer 
intensities? This is sort of new to me.

I agree with Rick on the second part. It however seems that with such an 
intensity correction (assuming that we are not mistaken on what PSStitcher 
does) and enblend, I obtain much decent results than without the brightness 
correction. (Yes, I forgot to lock the exposure/aperture.)

As a side comment, this aperture/exposure lock worries me a little. Since 
digital cameras have a finite dynamical range, shouldn't we let them adapt 
the exposure time so that we optimize the information in each individual 
image? Locking the aperture sounds OK with me since it may impact 
vignetting, DOF... If so, that makes the case for a brightness correction 
even stronger.

And a last question, somewhere related to the current issue: are there image 
formats with more than 8bits/channel, for extended dynamical range?

Thanks,

-Gellule

"Rik Littlefield" <rj.littlefield at computer.org> wrote in message 
news:4380E5D2.4080800 at computer.org...
>I agree with Gellule's interpretation.
>
> In practice, I think it should not be much problem that N_A is not
> strictly increasing.  By definition, flat sections in N_A will occur
> only in regions where no pixels have those values in A.  So if the basic
> model is right, no pixels in B (at least not many) will end up mapping
> to those sections of N_A.  Using some average over the flat region seems
> OK.  Maybe less risk of banding if for each pixel in a flat region of
> N_A you pick a random value from among the possibilities..
>
> Bear in mind that this whole model assumes that matching the histograms
> within the whole overlap region will match colors on a pixel by pixel
> basis.  This is true under idealized conditions, but it breaks down if
> different portions of the overlap region had different shifts.  For
> example, you can expect less than perfect correction if radial falloff
> causes a left-to-right gradient in one image but right-to-left in the
> other.  Radial falloff should be corrected  in each image separately,
> before attempting to correct one image against another.  (And accurately
> correcting for radial falloff requires knowing the actual
> light-level-to-pixel-value gradation curve, not just some idealized
> gamma, but that's another story.)
>
> --Rik
>
> Gellule wrote:
>
>>Hello,
>>
>>I have a group of pictures for which the best result is achieved with
>>PTStitcher with brightness correction and then enblend. It seems to me 
>>that
>>it would be interesting to have the brightness/color correction in nona. 
>>Is
>>that a wanted/planned feature? Would an explanation of what H.Dersch might
>>mean help?
>>
>>The gradation curves N(I) seem to be the integration of the histograms 
>>n(I):
>>   N_A(I) = Sum_{i in [0;I]} n_A(i)    for n_A(i) the histogram of image A
>>   N_B(I) = Sum_{i in [0;I]} n_B(i)    for n_B(i) the histogram of image B
>>
>>The correction from image B to image A would then follow:
>>A pixel of intensity I in image B should become a pixel of intensity
>>N_A^-1(N_B(I)).
>>
>>Basically, you end up with (almost) exactly the same histrogams.
>>Unfortunately, N_A is a discrete function and not strictly increasing 
>>(don't
>>know if those are the proper mathematical terms), and there must be some
>>subtleties to add in the implementation in order to get the thing working.
>>
>>Thank you for Hugin.
>>
>>-Gellule
>>
>>
>>"Pablo d'Angelo" <pablo.dangelo at web.de> wrote in message
>>news:41EA3340.6000809 at web.de...
>>
>>
>>>Hi!
>>>
>>>Just stumbled upon this when searching for another mail...
>>>
>>>Bruno Postle wrote:
>>>
>>>
>>>>While I was looking around in adjust.c, there seems to be all the
>>>>code used by PTStitcher to do brightness/colour correction of image
>>>>pairs:
>>>>
>>>>  void GetColCoeff ( Image *src, Image *buf, double ColCoeff[3][2] )
>>>>  void ColCorrect ( Image *im, double ColCoeff[3][2] )
>>>>  void DoColorCorrection ( Image *im1, Image *im2, int mode )
>>>>
>>>>Could this be useful in nona?
>>>>
>>>>
>>>I believe this is an old version of the correction algorithm, not the one
>>>described on
>>>
>>>http://www.path.unimelb.edu.au/~dersch/cbcorrect/cb.html
>>>
>>>Regarding that page, the description is a bit sparse on implementation
>>>details.
>>>
>>>Quote from H.Dersch:
>>>================================
>>>
>>>
>>>>If two images are perfectly colour balanced, their histograms are
>>>>identical. The algorithm now included in PTStitcher calculates
>>>>gradation-curves for each colour channel which match the corresponding
>>>>histograms. These gradation curves are then used to correct image B.
>>>>There are several advantages of this method:
>>>>[...]
>>>>The curves used for correction are calculated using a transformation
>>>>of the histograms, and are exact (at least under usually applicable
>>>>assumptions), not mere optimizations. They refer to the best fit
>>>>obtained using 256 variables for each channel. In other words: If the
>>>>image can be adjusted, this method will find the correct curves for
>>>>performing this adjustment.
>>>>
>>>>
>>>Does anyone know what kind of transformation he uses? My first idea would
>>>have been minimisation of the error between the histograms, using
>>>numerical optimisation.
>>>
>>>ciao
>>>  Pablo
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>