which preview?

[Yuval Levy]

so we have two preview windows: fast and traditional. Do we need both of
them for 0.8.0 and if yes which one should be the main one and how do we
attract user attention to the second one?

my impression is that currently we can not simply get rid of the
traditional preview.
- the traditional preview has an option to show LDR/HDR which the fast
does not have
- fast preview sometimes has artefacts (e.g. at the 360° seam of
equirectangular input) and sometimes does not display properly
- has anybody tested fast preview extensively, e.g. on gigapixel
projects that have been stitched before with the traditional preview?

also it would be good to bring to the preview pane those settings
affecting the preview that are currently in the Stitcher tab, i.e.
panorama, field of view, canvas size and crop.

given all the above, would it be an idea to:
- make the panorama preview into a simple tab, like any other tab
- on that tab, there would be a switch to choose between the fast and
the normal preview
- on that tab, the user would manipulate those parameters that affects
how the output looks like, i.e. the projection, FOV, canvas size, crop
- on the stitching tab, only the second half would stay
(output/processing/file formats)
- the preview tab would fit between the exposure tab and the stitcher tab

Yuv

[Seb Perez-D]

On Mon, Jan 26, 2009 at 21:54, Yuval Levy <goo...@levy.ch> wrote:
>
> so we have two preview windows: fast and traditional. Do we need both of
> them for 0.8.0 and if yes which one should be the main one and how do we
> attract user attention to the second one?

The fast preview is quite useful BUT it is still buggy - it happens
(not reproducibly but quite consistently) that it keeps reloading the
images as soon as they change, and the fast preview becomes useless. I
have then to restart hugin (linux x86_64). I am not sure tabbing the
previews would solve this issue.

Cheers,

Seb

[J. Schneider]

Yuval Levy schrieb:

> given all the above, would it be an idea to:
> - make the panorama preview into a simple tab, like any other tab

I like to have the preview window next to the main window to see changes
immediately, without switching to the preview.

> - on that tab, there would be a switch to choose between the fast and
> the normal preview

Switch sounds good - but not on a tab.

regards
Joachim

[Bruno Postle]

On Mon 26-Jan-2009 at 15:54 -0500, Yuval Levy wrote:

>my impression is that currently we can not simply get rid of the
>traditional preview.

>- the traditional preview has an option to show LDR/HDR which the fast
>does not have
>- fast preview sometimes has artefacts (e.g. at the 360° seam of
>equirectangular input) and sometimes does not display properly

- fast preview doesn't do 'difference' mode

>- has anybody tested fast preview extensively, e.g. on gigapixel
>projects that have been stitched before with the traditional preview?

Nope.

>also it would be good to bring to the preview pane those settings
>affecting the preview that are currently in the Stitcher tab, i.e.
>panorama, field of view, canvas size and crop.

These are all available already in the fast preview. Except for
canvas pixel size, but this is an output format option much like
TIFF vs. JPEG.

>given all the above, would it be an idea to:
>- make the panorama preview into a simple tab, like any other tab

The tabs don't have much space, I'm sure some users really want to
have the preview 'full-screen' on a second monitor - Especially now
the fast preview is responsive at full resolution.

Say you have four monitors: you might give hugin, both previews and
the PTBatcher queue one monitor each ;-)

Ultimately (post 0.8.0), I think a really interesting project would
be to make the fast preview the 'main' frame of hugin and merge the
Assistant with this window. The other tabs which are hardly used by
most users can be two modeless utility windows: Images, Camera and
Lens and Crop; and Optimiser and Exposure. The Stitcher can be a
modal window.

This is something like Ippei's original part II plan and would make
a good summer of code project.

--
Bruno

[Seb Perez-D]

On Tue, Jan 27, 2009 at 00:02, Bruno Postle <br...@postle.net> wrote:
>
> - fast preview doesn't do 'difference' mode
>

There is a difference dropdown, and when you hover over the images it
shows the differences between the images under the mouse pointer. IMHO
this is even better than the traditional difference mode.

Seb

[Lukáš Jirkovský]

First, I like and use both.

My idea is to add Fast preview button next to Preview panorama. Then
make Fast preview to open by default in assistant's align mode. And
possibly add some setting to preferences where anyone can change the
which one use for align.

2009/1/27 Seb Perez-D <sbp...@gmail.com>:

I think the traditional difference mode is more more accurate.

[Simon Oosthoek]

Bruno Postle wrote:

> Ultimately (post 0.8.0), I think a really interesting project would
> be to make the fast preview the 'main' frame of hugin and merge the
> Assistant with this window. The other tabs which are hardly used by
> most users can be two modeless utility windows: Images, Camera and
> Lens and Crop; and Optimiser and Exposure. The Stitcher can be a
> modal window.
>

Oh I can see it now, you have this fancy globe-like grid (think
holodeck) and you drop/load a bunch of image in/onto it and it starts
thinking, the images (when linked together) snap into place and
gradually the panorama builds up. If groups of unconnected images are
found, they sort of bob around each other but kind of like repelling
magnets. IF all images have found a place, you hear a kind of chime or
whatever and the FOV is optimised and all the other parameters are
calculated and shown as they become ready. The projection selection is
like a kind of dial in a corner and the globe-grid (if still visible)
deforms with each projection selection.

I could live with that ;-)

Cheers

Simon

[Bruno Postle]

On Tue 27-Jan-2009 at 09:45 +0100, Lukáš Jirkovský wrote:
>
>My idea is to add Fast preview button next to Preview panorama. Then
>make Fast preview to open by default in assistant's align mode.

That should be enough for 0.8.0.

>And possibly add some setting to preferences where anyone can
>change the which one use for align.

I don't think this is necessary, the Align button is for people who
accept the defaults.

--
Bruno

[Bruno Postle]

On Tue 27-Jan-2009 at 08:35 +0100, Seb Perez-D wrote:
>
>There is a difference dropdown, and when you hover over the images it
>shows the differences between the images under the mouse pointer.

I hadn't noticed, I need to get the manual updated...

Another reason for keeping the old preview around is that it will
take advantage of the nona-gpu code.

--
Bruno

[Andrew Mihal]

I expect that nona-gpu will not be efficient for rendering the
previews, due to the overhead of compiling GLSL code for each input
image and transferring the data back from the GPU to the CPU before
drawing it in the preview window. The approach used by the GL preview
is superior in this situation.

This is related to the bug Yuval put in the tracker, which I attached
a comment to.

If the frame rate and quality of the GL preview are determined to be
insufficient, it should be possible to adapt the nona-gpu approach to
produce vertex shader programs that would offload the mesh
transformation from the CPU onto the GPU. I apologize for not looking
at the actual implementation of the GL preview before making this
suggestion. This might be nonsense.

Andrew

[Pablo d'Angelo]

Andrew Mihal schrieb:

> I expect that nona-gpu will not be efficient for rendering the
> previews, due to the overhead of compiling GLSL code for each input
> image and transferring the data back from the GPU to the CPU before
> drawing it in the preview window. The approach used by the GL preview
> is superior in this situation.

I haven't looked into your GLSL code generation yet, but are the
parameters (hfov, r,p,y etc.) also compiled into the GLSL code for each
image?

> This is related to the bug Yuval put in the tracker, which I attached
> a comment to.
>
> If the frame rate and quality of the GL preview are determined to be
> insufficient, it should be possible to adapt the nona-gpu approach to
> produce vertex shader programs that would offload the mesh
> transformation from the CPU onto the GPU. I apologize for not looking
> at the actual implementation of the GL preview before making this
> suggestion. This might be nonsense.

The OpenGL preview is quite fast, even on systems without hardware
acceleration, as the software texture mapping routines seem to be
reasonably optimized. The main problem is that the GL preview uses a
forward mapping to generate the mesh, and this complicates matters at
zenith, nadir and the 360 deg seam.

ciao
Pablo

[Yuval Levy]

Bruno Postle wrote:
>> also it would be good to bring to the preview pane those settings
>> affecting the preview that are currently in the Stitcher tab, i.e.
>> panorama, field of view, canvas size and crop.
>
> These are all available already in the fast preview. Except for
> canvas pixel size, but this is an output format option much like
> TIFF vs. JPEG.

I don't see the HFOV/VFOV in any of the preview windows?

canvas pixel size and crop should be part of the preview. To me, the
output format has with rendering, while the preview windows with setting
up the visible part of the rendering effort. TIFF vs. JPEG is not a
visible choice, FOV/canvas/crop are.

> Ultimately (post 0.8.0), I think a really interesting project would
> be to make the fast preview the 'main' frame of hugin and merge the
> Assistant with this window. The other tabs which are hardly used by
> most users can be two modeless utility windows: Images, Camera and
> Lens and Crop; and Optimiser and Exposure. The Stitcher can be a
> modal window.

for a stitching application (i.e. Hugin), that would be nice.

something that I would find more interesting is to add Python bindings
to the code, so that it can be accessed via Python scripts. wxPython is
a very mature GUI toolkit (and uses the same wxWindows as Hugin) that
would enable much more variation.

Then the whole workflow could be dynamically adjusted to the process at
hand.

Yuv

[Andrew Mihal]

Hi Pablo,
Yes, the parameters are compiled in to the shader programs, which
are regenerated for each image in the project. You could pull these
values out as "uniform" parameters to the GLSL shader program, but I
did not do this. There is a limit on the number of parameters you can
have - I think it is 64.

Andrew

[Bruno Postle]

On Fri 30-Jan-2009 at 23:32 -0500, Yuval Levy wrote:
>
>I don't see the HFOV/VFOV in any of the preview windows?

There are sliders for field of view in both previews.

>canvas pixel size and crop should be part of the preview. To me, the
>output format has with rendering, while the preview windows with setting
>up the visible part of the rendering effort. TIFF vs. JPEG is not a
>visible choice, FOV/canvas/crop are.

I would say pixel resolution is just a quality level and unrelated
to composition.

--
Bruno

[Yuval Levy]

Bruno Postle wrote:
> On Fri 30-Jan-2009 at 23:32 -0500, Yuval Levy wrote:
>> I don't see the HFOV/VFOV in any of the preview windows?
>
> There are sliders for field of view in both previews.

stupid me, that's so obvious. but then again, I prefer the numeric input
field because it gives me more precision and is faster.

> I would say pixel resolution is just a quality level and unrelated
> to composition.

pixel-resolution yes. crop no. unless you tell me that I can move the
crop lines inside the preview window, but even then, I prefer the
numeric input field because same as above.

Yuv

[Bruno Postle]

On Sat 31-Jan-2009 at 17:54 -0500, Yuval Levy wrote:

>Bruno Postle wrote:
>>
>> There are sliders for field of view in both previews.
>
>stupid me, that's so obvious. but then again, I prefer the numeric input
>field because it gives me more precision and is faster.

You have the numeric input in the Stitcher tab, the preview is where
all the interactive pointy-clicky stuff is.

>> I would say pixel resolution is just a quality level and unrelated
>> to composition.
>
>pixel-resolution yes. crop no. unless you tell me that I can move the
>crop lines inside the preview window, but even then, I prefer the
>numeric input field because same as above.

Yes the new fast preview has a great mode for adjusting crop:

http://wiki.panotools.org/Hugin_Fast_Preview_window#Crop

..again there is numeric input in the stitcher tab if you need it.

--
Bruno

[Yuval Levy]

Bruno Postle wrote:
> You have the numeric input in the Stitcher tab, the preview is where
> all the interactive pointy-clicky stuff is.

If the Panorama Preview is to become the future hub for all panorama
stitching, the separation of numeric input and interactive pointy-clicky
stuff as implemented now is obsolete (not to say it is inconsistent).

What is important to me is to have all the relevant controls accessible
in a single spot. Dispersing them on two different windows (acutally
more, there is no reason why the numeric transform should be hidden in a
pop up window behind a toolbar button) which are potentially on two
different screens at very large scrolling distance is inefficient.

if there are two windows, one should be preview only (i.e. interactive
pointy-clicky stuff *inside* the panorama determined by the FoV and
crop) and the other should be control.

Moreover, the sliders for the FoV are neat when the preview is small.
Sliding them on a 1920x1200 display is a much bigger (i.e. slower)
movement than it should be. I'd simply put them next to the respective
numeric values and make them 360 pixel long - a resolution of one degree
per mouse-tick is enough for the FoV.

The control panel would be a remodeled stitcher tab which eventually
will become a modal window of the preview window. I'd let it float on
the preview window, and keep it vertical in design so that people with
two display can put it next to the preview window/display without having
to travel long distance with the mouse to reach it.

I'd separate it in the following areas, top to bottom:

1. The toolbar that is currently on top of the preview window without
the Num. Transf. button

2. Preview Options (only Blend mode and EV)

3. Projection - the current projection drop down

4. FoV - the current FoV numeric fields in a column, next to them
sliders of 360px length for the pointy-clicky interaction and the
existing Calculate FoV button.

5. Canvas Size - the current width/height (for which there is no
pointy-clicky control at the moment

6. Crop - ok as is now

All of the above is what I need to control the preview (even if I agree
with your previous message that the Canvas Size is more stiching related
than preview related, but if the Crop is in pixel (which I believe it
should be to allow for finer grained control) then the Canvas Size
belongs above.

The rest is in a processing / stitching area defining Output, File
Formats, Processing, etc. Could be on a separate window, Output.

> Yes the new fast preview has a great mode for adjusting crop:
>
> http://wiki.panotools.org/Hugin_Fast_Preview_window#Crop

great indeed, although in Windows it flickers too much and stays gray
long times - must release the mouse more often than I want to get some
feedback.

The white controls are unintuitive, but once understood they are great
to work with.

I'd add a way to maintain the aspect ratio by holding down a modifier
key (shift).

I'd make the semi-transparent (sides) and completely transparent
(corners) controls all semi-transparent and either red or blue (all the
same color, and use the same color for the crop border too). I'd shape
them as large/bold bidirectional arrows with the point of the outward
arrow slightly outside the crop box. I would not let them touch corners
as they do now, because it makes them look like some weird transparency
pattern more than like controls inviting interaction. Scaling them as
the crop becomes small is OK.

Yuv

[AKS-Gmail-IMAP]

That was also my reaction. I now recognize the controls as a shaded
variation of GIMP's crop interface. The control would be intuitive for
me if the rectangles are instead triangles pointing into the image
portion to remain much like a carpenter's mark that indicates which
side of a cut line the wood should remain undisturbed by a saw blade.

On Feb 1, 2009, at 11:32 AM, Yuval Levy wrote:
>
>> Yes the new fast preview has a great mode for adjusting crop:
>>
>> http://wiki.panotools.org/Hugin_Fast_Preview_window#Crop
>
>