GUI complexity

[Pablo d'Angelo]

Hi!

On Thu, 24 Apr 2003, Bruno Postle wrote:
> On Thu 24-Apr-2003 at 01:42:11AM +0200, Pablo d'Angelo wrote:

> It's worse than that; a, b & c vary depending on the focus distance
> too.
>
> This is something for advanced users, who may need to optimise a, b
> & c for every panorama - If you are not building high-resolution 360
> degree spherical panoramas, then you can generally ignore these
> effects.

Hmm, jup. thats something for the advanced mode then.

> > 2. crop the image (optional, I never needed this so far).
>
> Scanned photos again, especially with negative/transparency
> scanners, the crop settings are likely to be the same for all
> pictures (You could just make a decision to only support digital
> cameras :-)

:) well if I would write the program just for myself, then the
features needed for digicams will be in first, because thats all I
have (right now).

> > 3. select an "anchor" image, and set its position (like in
> >    PTAssembler). this position should not be moved by the optimizer.
> >    This is very useful, especially since I take many pics free hand,
> >    and they usually have some rotation and are not shot completely
> >    level.
>
> True, though the H & V control point parameters are very important
> for getting everything level - In which case you are unlikely to
> want to fix all of the roll, pitch & yaw parameters for the anchor
> image.

I haven't played alot with them yet. but I'll do once whe have a
working program.

> (With architectural photography, you often want to optimise roll,
> pitch & yaw for every image)

but in the end, a global optimization step might change them back to
something that make them fit together, after you have optimized each
one of them to get straight skyscrapers, or?

> > 3. select control points (unfortunately needed I guess), but as much
> >    help as possible should be offered. This is the point where I
> >    really want to go a step further than the other GUI's.
>
> I think a lot of this could be completely automated, perhaps even
> selection of control points, though the user would have to align
> everything by eye first.

That would be the ultimate goal. But I don't have an exact idea how
this should work with a wide range of images yet, I might have to dig
into some more image processing literature.

> > 6. set output panorama parameters (if we can display the panorama
> >    or a preview inside the gui, we might be able to give the user the
> >    ability to select a crop region for the final image etc.)
>
> Bear in mind that PTOptimizer optimises images _into_ the output
> format, so you have to select output parameters before you can
> optimize.

Hmm, so the optimization strategy is different for each output format?
I thought it would be the same. Why would it affect the optimization,
the optimizer "just" determines the position of the images and
distortion variables. The position of the images do not change when
selecting a different output format, just the reprojection is changed, or?

I noticed that PTOptimizer outputs the control points with coordinates
on the final image. And also the unit for the control point distance
are pixels of the panorama output.

> Also, once all the input image parameters are decided, this output
> format is irrelevant, you could "render" into any number of
> different output formats.

so why should the output format influence the estimation of image
parameters (when you say that they are output format independant).

On the code side: I'll take a look at wxwin in the next days and I'll
try to port my control point picker to wxwin, so that I can give a
more qualified statement than: I just like qt more. After that I'll
decide if I'll stick to qt or join the wxwindows development.

ciao
  Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP