Colour/brightness correction (was:hugin update)

[alexandre jenny]

Hi,

The mathematician in the house speaking : (I'm new in the list, so let's
introduce myself by an answer) ...
The algorithm used to remap the color and brihtness in the latest
version of panotools is quite straitforward, but useless !!!! Why ?
Because it works this way :
 - from the ancor image, let's find the neightboors.
 - do
 -   first neightboor, do an histogram adjustement with 256 variables.
Easy to do with a good solver and a good constraint.
 -   make the same transform with the new corrected picture
 - until no picture left.
The big issue of this approach is when doing a 360° pictures. Let's
imagine it here :
"Picture 1, picture 2, picture 3, picture 4"
Picture 1 is connected with some controls point with picture 4.
You choose a reference picture : let says it is the 3.
Algo : starting with picture 3
  3 : it's neightboor is 2 -> correction ( solve picture 3-2 constraint
)
  new picture to work with is 2
  
  2 : it's neightboor is 1 -> correction ( solve picture 2-1 constraint
)
  new picture to work with is 1
    
  1 : it's neightboor is 4 -> correction ( solve picture 1-4 constraint
)
  new picture to work with is 4

  And it's stops because there's no more picture to correct. 

What's the problem ? It never take into account the constraint beetween
picture 4 and 3. And you can see a major histogram distance is the
debug.txt for such a case.
It's not the good way to solve this problem. The solution would to
create every histogram and solve a big problem of 4 * 256 variable with
4 constraints. And not 3 small 256 variable with 1 constraints. The
neightboorhood solving is not the good way to do it. But the constraint
calculation is good.

That's my answer.

Now let introduce myself a little. I'm making panorama as hobby and I
love that. But moreover I would like to participate in the hugin
project, I think it has really much potentiality.
I am actually working in a feature extration tools that could be used
with hugin. Every of you I think have read this
http://www.cs.ubc.ca/~mbrown/panorama/panorama.html. That's exactly what
I'm rewritting. I have already the SIFT feacture extractor. I just need
some more routines to be able to find pair of picture and place them
approximately. My option is not to do a full panorama tools from picture
to pano, but to generate a hugin or ptgui project directly with the good
parameters. I called this project PtPrepros (panoTools preprocessor) and
it should be available in a week or two. The only big issue I have is a
licencing problem. I have to ask Dr Lowe for that.

Next, I have some question. I rewriting my feature extractor in cpp
(tested in matlab) and I'm willing to use vigra to do it (that would
allow a direct use in hugin with no rewrite). But I go a strange problem
with the library. After having a full install of everything needed for
vigra, I run into a problem with the jpg library init. When I use this
library it crashs, without, it's good. (I'm on windows 2k with visual
studio .net). I checked with different version of the libjpeg with no
luck. It seems to be in the library init before you get in the main
function. Any idea ?

Alexandre Jenny


-----Message d'origine-----
De : ptx-bounces at email-lists.org [mailto:ptx-bounces at email-lists.org] De
la part de Bruno Postle
Envoyé : lundi 10 novembre 2003 22:31
À : PTX mailing list
Objet : Re: Colour/brightness correction (was:hugin update)


On Mon 10-Nov-2003 at 09:36:18 +0100, Pablo d'Angelo wrote:
> 
> I've just read 
> http://www.path.unimelb.edu.au/~dersch/cbcorrect/cb.html

> That article says that all overlapping pixels are used, except those 
> cropped away with the Sx1,x2,y1,y2 crop option.

I mustn't have been paying attention, or I'm describing an earlier
version of ptstitcher..

> Helmut's description says:
> 
>  "The algorithm now included in PTStitcher calculates gradation-curves
for
>   each colour channel which match the corresponding histograms."

Do you think he is saying that it fits a spline curve to the histogram?
I can imagine that there is an algorithm that derives a transformation
to map one spline onto another.

>   "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"
> 
> It would be nice to know this transformation :)

Is there a mathematician in the house?

-- 
Bruno