[ptx] [Fwd: Re: panoramic pictures color adjustments]

[Pablo d'Angelo]

Hi all,

>>Actually, I have planned to add a similar feature to hugin/nona. My
>>experience with the correction from PTStitcher was that for panoramas
>>with many images the correction did introduce color casts. Probably
>>due to error propagation. I also think that vignetting might
>>influence the correction result. Hopefully the new, soon to be
>>released vignetting correction in hugin/nona will also improve this.
> 
> 
> In fact, most error propagation seems to be caused by over/underflow 
> with low-dynamic images. Correcting with truncated over-white or 
> under-black pixels leads to strange results. Maybe we can exclude those 
> pixels from the correction process.
> 
> Vignetting correction is a good news. I will look it with attention.

Together with the vignetting correction I have also added the linear
transformation of gray/rgb values to nona.

They are usual variables in the script
(see http://hugin.sourceforge.net/docs/nona/nona.txt for a complete list)

# K0a, K0b     linear color/grayvalue correction coefficients for each channel
# K1a, K1b        (for grayscale images Only K0a, K0b is used):
# K2a, K2b        i_red = K0a * i_red + K0b
#                 i_green = K1a * i_green + K1b
#                 i_blue = K2a * i_blue + K2b
#               This correction is applied after the vignetting correction.

Actually, while writing this, I remember that PTStitcher does use a complete
graduation curve during color adjustment, not just a linear transform of the
pixel values.

See http://www.path.unimelb.edu.au/~dersch/cbcorrect/cb.html for the
PTStitcher approach. However, this website does not have detailed
information how they are calculated. Any idea how its is done?

>>Ideally I'd like to use an algorithm that estimates all adjustments
>>at the same time. For this a regularized estimation might be useful,
>>which punishes high deviations from the original images (maybe only
>>in userselectable images).
> 
> 
> I think there's no ideal automatic solution. One of my challenges is a 
> 360 deg. set of pictures with various exposition conditions (3 of them 
> with direct sun). No way to correct it. When I get some spare time,  I 
> will try to correct 3 overlapping images using one of them as 
> reference. If I get some more time, I will try to construct a 
> dependance graph of all images and find a way to make a regularized 
> correction. It remembers me the N-body problem.

Hugin already contains code to construct a dependance graph and contains
code to analyse the overlap.

For the future radial vig. correction degree estimation I also need the same
information, so I will probably adapt that code sometime in the next month
or so.

> I am a poor website publisher. Maybe you could publish it in the hugin 
> package, if the quality is good enough for hugin.

I'll just add it in the tools directory. Actually your program could also be
integrated into enblend quite easily, I think. Enblend checks the overlap
(the histogram calculation could be added there), and the correction step
could be applied after that.

Do we really need to do a brute force search, or is

ciao
  Pablo