hugin comments
Pablo d'Angelo
pablo at mathematik.uni-ulm.de
Wed Jul 23 01:51:37 BST 2003
Hi together,
I finally had a look at hugin, after Kai-Uwe added lots of new code in
the last few days :-)
So here are some comments and ideas I got while running the current
cvs version.
> > > The Optimizer tab is empty, I guess it hasn't been done yet?
> >
> > I'am about to integrate it in the first and second tab likewise to
> > the ptx mockup. Is this ok for the workflow? The Optimizer would
> > remain as a button in the Panorama tab.
>
> I think so, optimizing is something that you might want to do at any
> stage of the process, there is no need to go to a specific 'tab' to
> do it - Maybe it could live in the toolbar (next to save, copy,
> paste etc..) where it is always visible.
Jep, this is what I thought as well. right now the optimizer settings
are distributed over 3 tabs, which can be annoying if one wants to
change optimisation settings between optimizer runs.
Sorry for not answering sooner, now you already added it there.
> Here's an idea:
>
> What if the optimizer button in the first tab (where only roll,
> pitch & yaw are visible in the table) only optimized roll, pitch &
> yaw?
Hmm, I don't think that we should offer a lot of "different" optimize
buttons. This will be very confusing to the user. I think one central
optimizer window (or tab), like in ptgui or ptassembler is quite ok,
and all we need.
There, the decisions what to optimize should be done. maybe we can offer
different optimize profiles. Each Profile would then specify which
variables are optimized. maybe even a "auto optimize" button that
applies some well "proven" series of optimize profiles.
The only optimizer related setting that I do not want to move to the
optimizer window is the linking of the Lens variables. imho they should
stay in the Lens tab.
Speaking of the lens tab, I have some ideas as well:
Right now the Image <-> Lens mapping is not very intuitive. I'm thinking
about a tab with two listviews. (one for the lenses, and one for the
images). It is also a killer if one wants to optimize some specific lens
settings, because he will have to change optimization flags through for
all lenses, with selecting them by using the Lens combobox.
Inherit setting should only be possible for each lens, since it
doesn't make sense to link two different lenses together (at least to
me).
On the code side, I have also noticed that there are many small
LensEdit::dChanged(), LensEdit::aChanged() ... and so on functions.
I would use three lensChanged() function:
- LensVariableChanged(), uses UpdateVariablesCmd to set image specific
variables
- LensChanged(), uses ChangeLensCmd, to change the Lens itself.
The Panorama class will then automatically
change the Variables in all affected images.
This is also the command where the links
should be set (links are global for all
"instantiations" of a lens)
- LensForImageChanged(), uses SetImageLensCmd, to change the lens of an
image.
I don't see a problem in the fact that these functions read multipe
LineInput fields instead of only the one that changed. The time spend
converting strings to doubles is not a performance killer, and nobody
will ever notice it, so its not needed to make a program more complicated
just to save a few conversion ;) (IMHO)
Right now the Panorama class creates a lens automatically when the first
Image is added. Maybe this should be changed, and the GUI should create
a lens first (from EXIF data, or from a lens database or from scratch.)
The general idea with the commands is that each command leads to a
complete and consistend Panorama state. So whenever the need for direct
manipulation of the PanoramaClass arises, or you need multiple commands
to archive an action, please let me know. Its likly a design bug in the
Panorama* classes, or maybe there is a better way, that I overlooked.
Maybe I should create an xrc file that shows what I've been thinking.
ciao
Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP
More information about the ptX
mailing list