[ptx] Re: Enblend suggestion: focus score weighting

[Pablo d'Angelo]

On Thu, 17 Jun 2004, Andrew C Mihal wrote:

> On Thu, 17 Jun 2004, Pablo d'Angelo wrote:
> 
> > I have already thought about something like that, maybe correlating small
> > area patches and using only one patch if the correlation coefficient is too
> > low.
> 
> What if the ghost is partially inside the overlap area and partially 
> outside the overlap area?

Well, thats a hard problem. A simple heuristic might choose
discard the area that leaves the overlap area (in the image that contains
the partial ghost, cut by the image border.

> Then I think you want to keep it. But how to 
> identify the boundary of the ghost? This seems very hard.

I don't think the boundary would be needed, just an area based approach,
that adjustes the masks. however, I see problems with small
missregistrations, because a simple correlation will fail in that
case.

> Then there are problems like two ghosts that are partially-in,
> partially-out, and also overlap themselves. Then what?

Hmm, thats very hard.. but what would a human do in that case? Probably
start using the clone tool.

> > Something else: I have worked on vigra's import/export module to support
> > arbitrary image types with alpha channel, and the hugin cvs contains
> > functions to to this, in case you're interested in that.
> 
> Excellent. I think the only remaining piece is a file-backed image class
> and corresponding accessors. Enblend can't afford to have the entire image
> in memory I think. I'll go through my equations again and see if I really
> need this, and how much memory it would acutally cost in the worst-case
> through the entire program.

I have thought about something like that as well. However I planned
requesting a specific ROI, and load that into memory, and use that.
But the problem there is that remapped zenith and nadir images will be HUGE,
because they span the whole width.

A completely disk based image might be needed for really big images.
In the meantime we might get away with mmap'ing a temp file, and use that
with vigra::BasicImageView. However I have no idea well the kernel responds
to the typical traversals how they accur in image processing.

> My plan is to use the image loader you described, and return the resulting 
> combination of mask image and regular image as a boost variant. Then the 
> main blending loop will be a templatized visitor on that variant. I want 
> to have exactly one codebase for all of the image types. Thoughts? 

I have to read about variants first. However, the functions I have written
so far, always expect an image and a mask, for example:

/** Transform image, and respect a possible alpha channel */
template <class SrcImageIterator, class SrcAccessor,
          class SrcAlphaIterator, class SrcAlphaAccessor,
          class DestImageIterator, class DestAccessor,
          class AlphaImageIterator, class AlphaAccessor,
          class TRANSFORM>
void transformImageAlpha(vigra::triple<SrcImageIterator, SrcImageIterator, SrcAccessor> src,
                         std::pair<SrcAlphaIterator, SrcAlphaAccessor> srcAlpha,
                         vigra::triple<DestImageIterator, DestImageIterator, DestAccessor> dest,
                         std::pair<AlphaImageIterator, AlphaAccessor> alpha,
                         vigra::Diff2D destUL,
                         TRANSFORM & transform,
                         PanoramaOptions::Interpolator interpol,
                         utils::MultiProgressDisplay & progress)

Where would boost::variant come into play?

ciao
  Pablo