traditional preview
Yuval Levy
I recall there was some reason to keep the old preview next to the new
one. Is this still the case, or can we forego the old preview and work
with the new one only?
The background of my question: I want to continue to move functionality
into the new preview (e.g. the crop and projection from the stitcher
tab) to fast preview. But this will make the the fast preview a
mandatory step in the workflow, and it will make the old preview even
more obsolete.
I personally have not used the old preview for ages. Anything I am
missing that was there and I no longer recall?
Yuv
Bruno Postle
>
>I recall there was some reason to keep the old preview next to the new
>one. Is this still the case, or can we forego the old preview and work
>with the new one only?
The 'old' Preview is somewhat more accurate, it doesn't have the
problems the Fast Preview sometimes has with images getting
scrambled, but the main thing is that it is currently the only way
to show HDR stacks with tonemapping - It isn't clear that this
could be done at all in the Fast Preview.
We discussed merging it into the Fast Preview, i.e. adding another
button that switched the 'mode' to 'slow'.
--
Bruno
Seb Perez-D
>
> On Thu 08-Oct-2009 at 17:46 -0400, Yuval Levy wrote:
>>
>>I recall there was some reason to keep the old preview next to the new
>>one. Is this still the case, or can we forego the old preview and work
>>with the new one only?
>
> The 'old' Preview is somewhat more accurate, it doesn't have the
> problems the Fast Preview sometimes has with images getting
> scrambled, but the main thing is that it is currently the only way
> to show HDR stacks with tonemapping - It isn't clear that this
> could be done at all in the Fast Preview.
>
Also, the normal preview is the only one accurate enough for white
balance and exposure correction. The Fast preview will show strange
colours.
Cheers,
Seb
Kornel Benko
(And yes, I know the button Photometrics in fast preview)
Kornel
--
Kornel Benko
Kornel...@berlin.de
Yuval Levy
> The 'old' Preview is somewhat more accurate, it doesn't have the
> problems the Fast Preview sometimes has with images getting
> scrambled, but the main thing is that it is currently the only way
> to show HDR stacks with tonemapping - It isn't clear that this
> could be done at all in the Fast Preview.
Seb Perez-D wrote:
> Also, the normal preview is the only one accurate enough for white
> balance and exposure correction. The Fast preview will show strange
> colours.
Kornel Benko wrote:
> I am using it, when optimizing for exposure.
thank you all for reminding me.
Bruno Postle wrote:
> We discussed merging it into the Fast Preview, i.e. adding another
> button that switched the 'mode' to 'slow'.
does this mean that it is unlikely that the accuracy of the Fast Preview
will be improved?
and what was the result of the merger discussion?
the only difference visible to me in the *chroma* around the preview is
that Fast Preview (FP) does not have the Output dropdown in the Preview
Options, that in the Traditional Preview (TP) is used to set the Output
to HDR/LDR.
how about (STEP 1) merging them visually with one single dropdown,
Output, having three choices: FAST, LDR, HDR. The first one would be in
FP, the other two would be in TP. The non applicable buttons in the
toolbar would be grayed out?
That toolbar is actually the next thorn in my eyes. There are too many
buttons. We have a report that because of too long translation texts,
the toolbar is larger than the window and some actions are not available.
How about (STEP 2) changing it into a menu?
Panorama
- Center
- Fit
- Sraighten
- Crop
- Numeric Transform
- Field of View (from current Stitcher tab)
- Canvas (from current Stitcher tab)
- Crop (from current Stitcher tab)
- Projection (currently a dropdown in the Preview Options)
Images
- All
- None
- {list of the individual images}
View
- Output (FAST/LDR/HDR)
- Photometrics (FP only, maybe could be summarized under Output?)
- Identify (FP only)
- Show Control Points (FP only)
- Blend mode (from Preview Options, currently meaningful for TP only)
- EV (from Preview Options)
- Auto (TP only)
- Update (TP only)
- Layout (TP only)
and we'd be left with (STEP 3) adding the tabs to the menu:
Workflow
- Assistant
- Images
- Camera and Lens
- Crop
- Control Points
- Optimizer
- Exposure
- Stitcher
I've broken this down into three steps. The goal is to turn the preview
to the hub from which all action is started.
many of the menu points would call up a palette-like window. The palette
is as small as possible to cover the least of the preview. of course
those function that requires large images (like Crop and Control Points)
will display in separate, full size windows (maybe on top of the preview
itself?)
each incarnation of the palette-like window would have a single purpose.
It would have a small number of fields to deal with. the new user won't
be confused by the quantity of choices (and could be guided through the
different palettes by the assistant); the fancy user could have many
palettes open at the same time and juggle between them. The expert user
could access each palette by a keyboard shortcut (they are menus). We'd
break the complexity of the stitcher tab into manageable chunks and
achieve a consistent interface.
this is all work in progress thinking. I like to have a rough idea of
where I am going before starting to move more elements around than I've
already did. The numeric transform was a good exercise and a fix of
something that already exist in the current context. before patching and
fixing more - even if I will just stop at STEP 1 for a start, I want to
have a sense of direction.
IMO the (Fast) Preview should become the hub and everything else should
float around it.
thoughts?
Yuv
Bruno Postle
>>
>> The 'old' Preview is somewhat more accurate, it doesn't have the
>> problems the Fast Preview sometimes has with images getting
>> scrambled, but the main thing is that it is currently the only way
>> to show HDR stacks with tonemapping - It isn't clear that this
>> could be done at all in the Fast Preview.
>Also, the normal preview is the only one accurate enough for white
>balance and exposure correction. The Fast preview will show strange
>colours.
Is this the case even with the 'Photometrics' button enabled in the
Fast Preview?
--
Bruno
Seb Perez-D
>
> Is this the case even with the 'Photometrics' button enabled in the
> Fast Preview?
I must say I hadn't noticed this button. Gosh, if a frequent user like
me misses this, I can only imagine how daunting Hugin can look like
for a newbie... ;-)
Cheers,
Seb
Bruno Postle
>
>does this mean that it is unlikely that the accuracy of the Fast Preview
>will be improved?
I think it is very dependent on the graphics hardware.
>and what was the result of the merger discussion?
..to do it later, after the Layout mode was done.
>the only difference visible to me in the *chroma* around the preview is
>that Fast Preview (FP) does not have the Output dropdown in the Preview
>Options, that in the Traditional Preview (TP) is used to set the Output
>to HDR/LDR.
It doesn't set the output of the project to HDR, it just implements
HDR merging and basic tonemapping in the Preview window itself.
>how about (STEP 1) merging them visually with one single dropdown,
>Output, having three choices: FAST, LDR, HDR. The first one would be in
>FP, the other two would be in TP. The non applicable buttons in the
>toolbar would be grayed out?
Yes we need to group some stuff together.
>That toolbar is actually the next thorn in my eyes. There are too many
>buttons. We have a report that because of too long translation texts,
>the toolbar is larger than the window and some actions are not available.
>How about (STEP 2) changing it into a menu?
Maybe, I would certainly like to free up some of the empty space to
make the preview canvas itself bigger, and a 'full screen (F11)'
mode has long been on the wishlist. Definitely something that needs
mockups.
There are some buttons that do similar things, and some buttons that
are mutually exclusive, these are an opportunity to merge stuff
together.
I know we all hate the Office Ribbon, but I quite like the buttons
that are also pull-down menus - I don't know if wxwidgets implements
this.
This is all becoming imminent, the autocrop feature and the fast
preview will both add buttons to the Fast Preview window.
--
Bruno
James Legg
> On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote:
> >
> >does this mean that it is unlikely that the accuracy of the Fast Preview
> >will be improved?
>
> I think it is very dependent on the graphics hardware.
There are a few constants that alter the quality / speed tradeoff. They
can be changed. I wanted to keep the preview fairly responsive on less
powerful machines, so the accuracy should be easily improved, at a cost
to speed. The constants could be tweaked, set based on hardware
specifications, or made a preference.
Here's where they are:
The number of pixels of image data used is set here:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TextureManager.cpp?revision=4005&view=markup#l_423
A too high value could cause a sudden performance drop on some hardware,
but I think the current value is quite cautious, and inappropriately low
when stacked images are used.
There are two ways of remapping the images. The transformations are
calculated by the CPU, but more accurate remapping requires transfering
more data to any dedicated graphics hardware, and then rendering there.
The quality level of the TexCoordRemapper, which maps evenly spaced
points on the panorama to the input images, is set here:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TexCoordRemapper.cpp?revision=3479&view=markup#l_27
There are several constants for the VertexCoordRemapper, which remaps
points on the input images into the panorama:
http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/VertexCoordRemapper.cpp?revision=3721&view=markup#60
This remapper is adaptive: it adds detail where it thinks it is
necessary. You can increase the maximum detail level or change how it
decides when there is already enough.
The colour correction is more tricky. Most new graphics hardware is
programable, which would allow us to make an hdr mode, improve the
difference mode, and make photometric correction work well. However,
many existing machines don't support custom shaders, so we are stuck
with a fixed-function graphics pipeline. We can get exposure and white
balance correction this way, but is a bit of hack. The other colour
transforms need the photometrics mode, which does the colour transform
like the traditional preview (and changing the parameters causes a
potentially very long delay in this mode).
> >the only difference visible to me in the *chroma* around the preview is
> >that Fast Preview (FP) does not have the Output dropdown in the Preview
> >Options, that in the Traditional Preview (TP) is used to set the Output
> >to HDR/LDR.
>
> It doesn't set the output of the project to HDR, it just implements
> HDR merging and basic tonemapping in the Preview window itself.
>
> >how about (STEP 1) merging them visually with one single dropdown,
> >Output, having three choices: FAST, LDR, HDR.
Also layout mode belongs in this menu, and maybe the control point
display mode as well.
> >That toolbar is actually the next thorn in my eyes. There are too many
> >buttons. We have a report that because of too long translation texts,
> >the toolbar is larger than the window and some actions are not available.
>
> >How about (STEP 2) changing it into a menu?
>
> Maybe, I would certainly like to free up some of the empty space to
> make the preview canvas itself bigger, and a 'full screen (F11)'
> mode has long been on the wishlist. Definitely something that needs
> mockups.
>
> There are some buttons that do similar things, and some buttons that
> are mutually exclusive, these are an opportunity to merge stuff
> together.
>
> I know we all hate the Office Ribbon, but I quite like the buttons
> that are also pull-down menus - I don't know if wxwidgets implements
> this.
There isn't a menu toolbar item in wxWidgets, but it does allow any
control to be added to a toolbar, so a combo box will do.
http://docs.wxwidgets.org/stable/wx_wxtoolbar.html#wxtoolbaraddcontrol
> This is all becoming imminent, the autocrop feature and the fast
> preview will both add buttons to the Fast Preview window.
The GTK widget library will (optionally but by default) add a menu
containing toolbar items that don't fit on the toolbar on the edge of
it. I can't find a similar feature in wxWidgets, and it doesn't just
work on wxGTK. :-(
A normal menu bar seems appropriate, as we continue to add features to
the preview.
-James
T. Modes
> how about (STEP 1) merging them visually with one single dropdown,
> Output, having three choices: FAST, LDR, HDR. The first one would be in
> FP, the other two would be in TP. The non applicable buttons in the
> toolbar would be grayed out?
Number 1: Currently fast preview and normal preview are both listen to
panorama changes. When both are active (but only one hidden) we can
get problems with performance, especially with big projects.
Number 2: In fast preview the difference mode is only activated when
graphic card is capable to do it. So when switch from fast to ldr/hdr
you also need to refresh the normal/difference mode box.
> Images
> - All
> - None
> - {list of the individual images}
harder to do a fast switch of visibility of single images.
which you will need is hidden by another palettes. And we can not
significant reduce the size of the single tabs. I like the tabbed user
interface.
> IMO the (Fast) Preview should become the hub and everything else should
> float around it.
>
> thoughts?
With the current implemtation you can open a big project and start
working. When finish the optimising the can open the preview, wait a
little time - or a little more time, and check the result.
When the fast preview becomes the hub, you start opening a project,
now you have to wait until all images are loaded (take a coffee
break ;-), and then you can start working.
Thomas
allard
view, the fast preview could be enhanced with:
-shortcut keys, especially for the different modes that determine what
the mouse does (crop, drag, identify etc). I've always liked the way
Labview implemented this (though you have know how to activate it
since a few versions): the <tab> button scrolls through the different
modes. That means you don't have to remember the shortcuts.
-settings in the preferences that determine the quality/speed trade-
off.
-customizable toolbars, so you can choose what is immediately
available and what goes into a menu
-Better colour/exposure accuracy without the huge delays. Probably
impossible for older hardware. Maybe combined with something that can
detect and display what your hardware is capable of so that this point
can be improved for those who have the right stuff, and others can
find the reason why it's not.
I realize some of these things are probably not easy to implement,
it's just to say what my ideal world would look like.
Yuval Levy
mockup attached. please read the (long, sorry) email addressing most
comments expressed. thanks to everybody who participated in this round
of feedback. if there is enough interest, as the next step I will
implement the attached tabbed palette without touching / removing
anything from the Stitcher tab for now.
Seb Perez-D wrote:
> I must say I hadn't noticed this button. Gosh, if a frequent user like
> me misses this, I can only imagine how daunting Hugin can look like
> for a newbie... ;-)
yes. we must simplify. break down complexity into manageable chunks.
keep coming your ideas in this thread.
Bruno Postle wrote:
> I think it is very dependent on the graphics hardware.
I thought OpenGL works also without GPU accelleration? I'm working on my
Centrino dynobook with integrated Intel graphics (915) and the Fast
Preview works as I expect it to do. Or maybe I am missing on GPU-only
features? Anyway, users with older hardware will have to live with
"graceful degradation".
>> and what was the result of the merger discussion?
>
> ..to do it later, after the Layout mode was done.
from your ribbon/buttons comment it sounds as if this is not an option.
> It doesn't set the output of the project to HDR, it just implements
> HDR merging and basic tonemapping in the Preview window itself.
I'll have to disambiguate my thoughts. "Preview Output" is what I mean
and what I understand on the Preview windows. I have not implemented
this in the mockup (yet).
> I would certainly like to free up some of the empty space to
> make the preview canvas itself bigger, and a 'full screen (F11)'
> mode has long been on the wishlist. Definitely something that needs
> mockups.
initial "palette" mockup attached. Icons will need to be designed. Have
not thought of full screen mode yet - IMO it is a no brainer and when
the fast preview is the hub it should open full screen only.
> There are some buttons that do similar things, and some buttons that
> are mutually exclusive, these are an opportunity to merge stuff
> together.
personally I'd do away with the toolbar; and put the most important
buttons for it on the first, maybe customizable palette tab.
another option I can imagine is for users with two displays to expand
all the tabs into a single big palette.
> This is all becoming imminent, the autocrop feature and the fast
> preview will both add buttons to the Fast Preview window.
So more or less at the same time as Layout integration? Should we go
ahead and integrate autocrop?
T. Modes wrote:
> Number 1: Currently fast preview and normal preview are both listen to
> panorama changes. When both are active (but only one hidden) we can
> get problems with performance, especially with big projects.
good point. maybe merging them into one single view is not a good idea
on the back-end, even if it looks good in the front end.
people have expressed enough views why it is worth keeping the
traditional preview, or at least its features. Any other ideas how this
can be done without maintaining the current confusing situation of two
previews at the same hierarchical level?
> Number 2: In fast preview the difference mode is only activated when
> graphic card is capable to do it. So when switch from fast to ldr/hdr
> you also need to refresh the normal/difference mode box.
yes. I only work with a highly *un*capable graphic card, so I probably
miss on many of the good options.
>> Images
>> - All
>> - None
>> - {list of the individual images}
>
> I like the images in the toolbar. When moving to a menu it would be
> harder to do a fast switch of visibility of single images.
agree. Having toyed a little bit more with wxWidgets and understood the
limits of menus, I rather have them as a "palette" (see below).
> I don't like the floating palette behavior. In this case the palette
> which you will need is hidden by another palettes. And we can not
> significant reduce the size of the single tabs. I like the tabbed user
> interface.
I like tabbed palette. One single palette with all the tools you need.
See the attached mockup (actually screenshots with non-functional XRCs -
if there is interest I can go about and fill the XRCs with function).
The tabbed palette is not higher than the current menu + toolbars +
images (which I'd like to replace). The tabs are identified by icons
(need to be designed) because I don't like how text stretches tabs and
buttons. I have not tried to associate tooltips with them.
Maybe it would be useful to have three variations:
(1) tabbed palette integrated in the fast preview window (i.e. single
window mode)
(2) floating tabbed palette (mockup)
(3) large expanded palette (for dual screen / power users)
I'm not sure if default should be (1) or (2). (1) is more newbie
friendly IMO.
My wish for the images would be one additional tab in the mockup, with a
single horizontal list of the images, scrollable left/right.
> Performance! (especially with big projects)
For now I try to make only changes that do not affect it, but...
> With the current implemtation you can open a big project and start
> working. When finish the optimising the can open the preview, wait a
> little time - or a little more time, and check the result.
> When the fast preview becomes the hub, you start opening a project,
> now you have to wait until all images are loaded (take a coffee
> break ;-), and then you can start working.
... we'll have to get around this. Lukas suggested a second, lower
priority thread (in another ML-thread I have yet to answer). The UI
should be functional / responsive even when the images are not loaded in
the preview, with placeholders being filled as time passes by.
allard wrote:
> -shortcut keys
yes. consider them on the todo list.
> -customizable toolbars
I'd still prefer no toolbar at all, but maybe a tab in the palette where
a user can add a few "quick access" buttons to the functions he uses more.
> -Better colour/exposure accuracy without the huge delays. Probably
> impossible for older hardware.
this is a little bit more for the long haul, and for the OpenGL experts.
I'm currently only dipping my toes in C++ and getting into wxWidgets.
> I realize some of these things are probably not easy to implement,
> it's just to say what my ideal world would look like.
thanks for sharing your thoughts.
Yuv
AKS-Gmail-IMAP
for the final product composition, the crop feature should be expanded
to include cropping individual images in context with the final product.
Allan
Yuval Levy
there are two different crops: input crop (individual images) and output
crop (output panorama).
I hope that at some point we'll have a context menu when right-clicking
on an input image on the layout (and maybe even on the distorted
preview), to open the image in the (existing) croppying window; to open
it in a (work in progress based on a gsoc2008 project) mask editor; to
select it for the left or right half side of the CP editor.
future stuff
Yuv
Rogier Wolff
> initial "palette" mockup attached. Icons will need to be designed. Have
> not thought of full screen mode yet - IMO it is a no brainer and when
> the fast preview is the hub it should open full screen only.
I hate programs that think they are the only one on my computer and
go full-screen automatically.
If I'm working with a single program I may want to dedicate 80-90% of
my screenspace to this program, but almost never "all".
So to me "full screen" is 90% of my pixels. Or maybe 45% on my dual
screen setup...
All this tells you is that this is a personal preference.
Options:
- Make it a preference setting.
- just start up the way the user left it last time.
- both of the above. (settings: normal window, full size, leave at previous)
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Rogier Wolff
> priority thread (in another ML-thread I have yet to answer). The UI
> should be functional / responsive even when the images are not loaded in
> the preview, with placeholders being filled as time passes by.
Really, showing previews should be almost instantaneous. But why
aren't they?
I have a computer running several CPUs at several billions of
operations per second per CPU.
I (the human) can only process about 2 Mpixels at about 1 FPS (unless
they are highly correlated as in a movie).
With 4 bytes per pixel, we're talking about 10Mbytes per second of
throughput to create an almost instantaneous feedback! Should be no
problem with almost 10 billion operations per second available? No?
Waiting minutes for a preview to open is totally unneccesary.
So where does the difference come from? A large project has a
destination resolution of several gigapixels. Several billion pixels!
This is usually stored as jpeg which is CPU intensive to decode.
Or it is stored as a TIFF, which is disk-intensive to load. (*)
The preview however only deals with up to two megapixels of visual
information. Why process billions of pixels when only just over a
million matter?
How can we implement this?
As soon as we get told about an image, we should start off a thread
that decompresses the jpeg, reduces the resolution by half, and caches
the result (on disk!) somewhere. Repeat until the images are very
small. Say less than 64 pixels in both directions. (in JPEG there may
even be shortcuts you can take if you want to just find out the sum of
each 4 adjacent pixels! You can skip decoding all higher-freqency
coefficients)
This should happen just once.
Now, for a preview, a quick calculation will tell you that the two
opposite corners of an image in the preview window lie for example 200
pixels apart. Then grabbing the 256x192 thumbnail for the preview is
going to be adequate.
Similarly, showing the whole image in the control-point editor,
requires only access to a lower-resolution version of the
image. Zooming in to 100%, actually only requires access to PART of
the full image. So even then it could be made unneccesary to decode
the whole 10 megapixels of my camera.
Roger.
(*) the tiffs are so large, we should assume they do not fit into
memory.
Yuval Levy
> I hate programs that think they are the only one on my computer
me too.
> and go full-screen automatically.
me not because I try to do one thing at a time. I find it more
efficient, at least when I'm not interrupted.
> - just start up the way the user left it last time.
that's the way it is now, and I'll leave it like that. I suspect more
people will come with the same objection. It's like trying to stop
smoking...
Yuv
Yuval Levy
> Really, showing previews should be almost instantaneous. But why
> aren't they?
now this one was an excellent piece of analysis. I agree 100%.
> As soon as we get told about an image, we should start off
this is what I tried to approximate with my primitive use of the idle
time (assuming that immediately after loading an image the software goes
in idle mode, which is where modern CPU spend most of their time)
> a thread
a separate thread would be more efficient indeed.
> that decompresses the jpeg, reduces the resolution by half, and caches
> the result (on disk!) somewhere. Repeat until the images are very
> small. Say less than 64 pixels in both directions. (in JPEG there may
> even be shortcuts you can take if you want to just find out the sum of
> each 4 adjacent pixels! You can skip decoding all higher-freqency
> coefficients)
>
> This should happen just once.
this is a very interesting strategy. disk space is cheap nowadays and
does not suffer the addressing limitations of RAM. however we can't
assume that disk space is unlimited, especially when people work with
very large projects. And we need to leave enough disk space for later
stages of the process (enblend). So add to it some disk space
calculations to prevent errors like "could not write to file".
also, aren't there intermediate image formats that are faster to load
from disk into memory than TIFF and JPEG?
that said, caching on disk the images, even at full resolution, would be
very helpful to me. I often stitch from a network drive just because I
am too lazy to copy the files from the network drive to the local drive
and back (and because the local drive is not backed up like the network
drive is).
for the resolution scaling, wouldn't it make sense to go powers of two
from the initial scaling?
> Now, for a preview, a quick calculation will tell you that the two
> opposite corners of an image in the preview window lie for example 200
> pixels apart. Then grabbing the 256x192 thumbnail for the preview is
> going to be adequate.
>
> Similarly, showing the whole image in the control-point editor,
> requires only access to a lower-resolution version of the
> image. Zooming in to 100%, actually only requires access to PART of
> the full image. So even then it could be made unneccesary to decode
> the whole 10 megapixels of my camera.
I love this kind of thinking; and I hope that one of our student turned
master wizards on this list will pick up on it and make it come true.
Yuv
J. Schneider
sorry for stepping in so late, I just would like to stress a few things
that are important to me:
Single buttons for images should definitely stay! They could be more
space saving if desired. They are very important for my workflow to be
easily accessible and visible all at the same time. I would hate to find
them in dropdown menus like in the stitcher tab.
(Of course I haven't got a clue how these single buttons are handled in
very big projects like I never have myself.)
Buttons that indicate a mode that the preview window is in or what a
click will do (e.g. drag, crop) and that can be switched on or off are
very good tools to keep the user oriented about what he is doing. I
guess for beginners they are even more helpful.
Button size could be reduced quite a lot and text could be wrapped.
Currently they are spaced with about 2 button-widths of whitespace in
between (at least on Windows). So I think you could fit even more
buttons even on small screens. (Is there any design guideline that says
down to how few pixel width hugin should be working?)
I am not sure if I like the palettes approach. They tend to be where you
don't need them and I guess I'm going to move them around all the time.
What I would like to have is a combined window containing the preview in
e.g. the upper half and the rest, tabbed as is, in the lower. With a
movable divider between. As an option. I find it important to be able to
have e.g. the cp tab full screen.
A first (easy?) step to make the preview the hub could be to make the
existing shortcuts of the normal hugin window work from within the
preview window.
Yuval Levy wrote:
> good point. maybe merging them into one single view is not a good idea
> on the back-end, even if it looks good in the front end.
But maybe back-ends can be kept separate and their output directed to
the one preview window, depending on the mode it is set to? (Thoughts of
a non-programmer)
> people have expressed enough views why it is worth keeping the
> traditional preview, or at least its features. Any other ideas how this
> can be done without maintaining the current confusing situation of two
> previews at the same hierarchical level?
Here I agree, it is confusing and that's why I find merging a really
good idea from the front-end view.
regards
Joachim
Bruno Postle
>
>> IMO the (Fast) Preview should become the hub and everything else should
>> float around it.
>Performance! (especially with big projects)
>With the current implemtation you can open a big project and start
>working. When finish the optimising the can open the preview, wait a
>little time - or a little more time, and check the result.
So automatically starting with the Preview could only work if Hugin
loads images in the background and allows full editing, saving and
even quitting before the last photo is opened.
--
Bruno
Bruno Postle
>
>mockup attached. please read the (long, sorry) email addressing most
>comments expressed. thanks to everybody who participated in this round
>of feedback. if there is enough interest, as the next step I will
>implement the attached tabbed palette without touching / removing
>anything from the Stitcher tab for now.
I don't think there is enough functionality here to justify a tabbed
palette, how much space would all this stuff take up in one frame?
This needs to be a pop-up window just for stuff that can otherwise
be done with the mouse in the Fast Preview, but which on occasions
need to be modified numerically.
So, the panorama pixel size is an output 'quality' setting, and
needs to be on the Stitcher tab; the Projection pull-down is a
central function of the Preview and has to be on the preview proper.
> >> and what was the result of the merger discussion?
> > ..to do it later, after the Layout mode was done.
>
>from your ribbon/buttons comment it sounds as if this is not an option.
We can still add buttons, the problem is that the spacing between
buttons is scaled to the largest text - On a 1280 pixel display the
English version of the Preview window has enough space for all
proposed buttons.
It is broken with German apparently, but with Chinese there is
enough space for twice as many buttons. Maybe the fix is as simple
as abbreviating the German translation?
> > It doesn't set the output of the project to HDR, it just implements
> > HDR merging and basic tonemapping in the Preview window itself.
>
>I'll have to disambiguate my thoughts. "Preview Output" is what I mean
>and what I understand on the Preview windows. I have not implemented
>this in the mockup (yet).
People have assumed (incorrectly) that selecting 'HDR' in the
Preview window enabled floating-point linear output when stitching.
This suggests the GUI isn't as clear as it should be.
>So more or less at the same time as Layout integration? Should we go
>ahead and integrate autocrop?
It works, I haven't tested it to see how slow it can be with big
projects - i.e. if it is still in need of a progress indication.
I was also going to add a button to the Fast Preview, which would be
an obvious modification of the existing Crop button (but didn't find
time). It isn't going to break everything, and if we decide to
release without it, the button can be simply removed from the XRC
file.
--
Bruno
Yuval Levy
> I don't think there is enough functionality here to justify a tabbed
> palette, how much space would all this stuff take up in one frame?
not yet. when the fast preview will become the hub, the tabbed palette
will contain many more functions.
> This needs to be a pop-up window just for stuff that can otherwise
> be done with the mouse in the Fast Preview, but which on occasions
> need to be modified numerically.
for mouse driven users true. for users who prefer to juggle with the
number it is the other way around.
actually I am trying to design something that can be either "docked" or
a floating pop-up. In both cases, horizontal, not taller than the
current toolbar+images list, and will actuall replace the toolbar +
images list, with the images list being one of the tabs.
> So, the panorama pixel size is an output 'quality' setting, and
> needs to be on the Stitcher tab;
disagree. this is where the complexity of the Stitcher tab starts:
mixing workflow with panorama settings. The Stitcher tab shall be
workflow only. And eventually will become a tab in the palette as well.
> the Projection pull-down is a
> central function of the Preview and has to be on the preview proper.
if the palette is docked. If not it is floating. Consider the tabbed
palette as *the* control - with the exception of those actions that are
taken on the images or on the preview themselves (identifying CP
manually; cropping; masking; dragging; etc.)
>>from your ribbon/buttons comment it sounds as if this is not an option.
>
> We can still add buttons, the problem is that the spacing
no, the problem is the quantity of buttons. makes it useless.
> Maybe the fix is as simple
> as abbreviating the German translation?
that's not a fix, that's a hack.
> People have assumed (incorrectly) that selecting 'HDR' in the
> Preview window enabled floating-point linear output when stitching.
> This suggests the GUI isn't as clear as it should be.
indeed. the GUI should be completely remodeled and for this we need to
break out of the current frame of mind.
>> So more or less at the same time as Layout integration? Should we go
>> ahead and integrate autocrop?
>
> It works, I haven't tested it to see how slow it can be with big
> projects - i.e. if it is still in need of a progress indication.
I've tested it on a 30 pictures project on the dynobook and a progress
indication would be appreciated.
> I was also going to add a button to the Fast Preview, which would be
> an obvious modification of the existing Crop button (but didn't find
> time). It isn't going to break everything, and if we decide to
> release without it, the button can be simply removed from the XRC
> file.
Yes, go ahead. We need more drawings / icons.
Yuv
Yuval Levy
> So automatically starting with the Preview could only work if Hugin
> loads images in the background and allows full editing, saving and
> even quitting before the last photo is opened.
that's the goal. I started reading about threading in wxWidgets.
Yuv
T. Modes
I don't like the tabbed palette. This a nothing other than a
**ribbon**. So you could use a wxRibbon in wx3.0. But I don't like
this control, it hides to much controls and you have to continously
changing the tab.
E. g. if you want to change output size and crop. First you go to
image size and input the image size. Now you have to switch to the
crop tab. You start entering values. But now you don't see whats the
width. Also go you back to image size tab. And so on...
And when you want to add more functions to this tab you will end with
many tabs, because every tab has a limited size. And the tabs are
wider than the window width. And now you are in a circle.
Other idea: We could add a menu bar. In this case we could remove the
captions of the buttons and use a button size like the main window. So
we would save a lot of space. Also the Select all and Select none
buttons could go the the images buttons panel below, maybe at the
first position. And so we could win more space.
Thomas
Bruno Postle
>
>Other idea: We could add a menu bar. In this case we could remove
>the captions of the buttons and use a button size like the main
>window. So we would save a lot of space.
The main window button-bar used to have captions, but they got lost
along the way. I suspect that most people don't know what these
buttons do and never use them.
>Also the Select all and Select none buttons could go the the images
>buttons panel below, maybe at the first position. And so we could
>win more space.
Yes, the select all/none buttons definitely belong together with the
image button strip.
BTW Thanks for implementing the F11 full screen mode, this makes a
big difference on the 800x480 eepc screen.
--
Bruno
Bruno Postle
>Bruno Postle wrote:
>> I don't think there is enough functionality here to justify a tabbed
>> palette, how much space would all this stuff take up in one frame?
>
>not yet. when the fast preview will become the hub, the tabbed palette
>will contain many more functions.
I'm not excited by this idea that the Preview window will require a
permanent floating toolbox. It will take up screen space wherever
you put it, so this functionality should just be properly integrated
into the Preview window itelf.
Transient pop-up windows for specialist functionality like keyboard
entry is a good thing.
>disagree. this is where the complexity of the Stitcher tab starts:
>mixing workflow with panorama settings. The Stitcher tab shall be
>workflow only. And eventually will become a tab in the palette as well.
Sounds like you are recreating the existing GUI, but with the
Preview attached to the bottom of the main frame.
>if the palette is docked. If not it is floating. Consider the tabbed
>palette as *the* control - with the exception of those actions that are
>taken on the images or on the preview themselves (identifying CP
>manually; cropping; masking; dragging; etc.)
Still not convinced. The tabbed widget has been abused by
Hugin/PTGui to indicate workflow, it really is best when it is used
to indicated different 'aspects' or 'views' of the same object.
This would develop into something like this: the whole Preview is a
tabbed interface, with the tabs named 'Compose', 'Crop', 'Layout',
'Slow' for the different 'modes' that we already have.
The Compose tab would be 'drag mode', but there would be visible
buttons for Straighten, Centre and Fit, text entry boxes for numeric
transform, FoV, sliders for HFoV and VFoV and all the projection
stuff we already have.
The Crop tab would be 'crop mode', there would be an Autocrop button
and text entry boxes for panorama pixel size and crop window. This
could later gain vector-mask editing functionality.
I'm not 100% convinced by this either, it's a lot like the 'ribbon'
thing.
--
Bruno
Yuval Levy
T. Modes wrote:
> I don't like the tabbed palette.
OK, I understood. Consider my mockup dead. It's back to the drawing
board. I gained some interesting insights from these discussions.
Yuv
Yuval Levy
as I said, this mockup is dead. That said...
Bruno Postle wrote:
> I'm not excited by this idea that the Preview window will require a
> permanent floating toolbox. It will take up screen space wherever
> you put it, so this functionality should just be properly integrated
> into the Preview window itelf.
from my point of view whether floating or embedded: it uses up the same
surface of the screen, so the "take up screen space" argument does not hold.
There are many meanings to "properly integrated".
To me it means: implement the function so that it takes up the least
amount of space necessary.
> Transient pop-up windows for specialist functionality like keyboard
> entry is a good thing.
I don't see keyboard entry as specialist functionality. to me it is
central part of my workflow and the way I work with Hugin.
>> disagree. this is where the complexity of the Stitcher tab starts:
>> mixing workflow with panorama settings. The Stitcher tab shall be
>> workflow only. And eventually will become a tab in the palette as well.
>
> Sounds like you are recreating the existing GUI, but with the
> Preview attached to the bottom of the main frame.
yes, my bad. as I said, consider that mockup dead. The hierarchical
positioning of the palette vs. preview was wrong. my bad.
> Still not convinced. The tabbed widget has been abused by
> Hugin/PTGui to indicate workflow, it really is best when it is used
> to indicated different 'aspects' or 'views' of the same object.
agree. and we have strictly *nothing* that indicate workflow. to add
complexity, our workflow is not that linear (as in: you could skip on
some tabs; come back to other tabs later in a different order, etc).
I currently don't see any efficient way to represent the workflow. First
of all, *the* workflow does not exist. There are many different
variations - too many to hard-code them in any sort of linear
representation. The workflow is dynamic. I think the workflow should not
be at the top of the hierarchy of the interface (as it currently is,
with the tabs). And I made the mistake of putting the fast preview at
the top of the hierarchy. I am now convinced that there is no single
aspect that deserves that spot, and we should enable the user to view
the different aspects / dimensions, one or two at the time.
> This would develop into something like this: the whole Preview is a
> tabbed interface, with the tabs named 'Compose', 'Crop', 'Layout',
> 'Slow' for the different 'modes' that we already have.
>
> The Compose tab would be 'drag mode', but there would be visible
> buttons for Straighten, Centre and Fit, text entry boxes for numeric
> transform, FoV, sliders for HFoV and VFoV and all the projection
> stuff we already have.
>
> The Crop tab would be 'crop mode', there would be an Autocrop button
> and text entry boxes for panorama pixel size and crop window. This
> could later gain vector-mask editing functionality.
>
> I'm not 100% convinced by this either, it's a lot like the 'ribbon'
> thing.
I think it is going into the right direction. Need some more time to think.
Yuv
Bruno Postle
>Bruno Postle wrote:
>
>> Hugin/PTGui to indicate workflow, it really is best when it is used
>> to indicated different 'aspects' or 'views' of the same object.
>
>agree. and we have strictly *nothing* that indicate workflow. to add
>complexity, our workflow is not that linear (as in: you could skip on
>some tabs; come back to other tabs later in a different order, etc).
For anyone who wants to know, the tabbed workflow dates back to
before the first 'autopano' control point generator appeared.
Historically the design of Hugin was based on the idea was that you
loaded photos in the Images tab, entered your lens settings in the
Camera and Lens tab, manually added control points in the Control
Points tab, Optimised then Stitched in the Stitcher tab.
i.e. you moved from left to right as you went, I even think the tabs
were numbered 1, 2, 3 etc...
With a control point generator and the Assistant, the workflow
becomes 'Load, Align, Create', and the tabs are only used to fix
things if this goes wrong - In whatever order makes sense.
If the Preview becomes the main interface, this 'Load, Align,
Create' workflow needs to move to the Preview.
--
Bruno
AKS-Gmail-IMAP
right tab concept of Load, Align, Exposure and Create. It should stay.
What I see (and do) in the two Previews is "Compose". For me,
"Compose" is the missing tab and in it should be access to all the
processes required to visualize and compose the final image, including
cropping the individual images in remapped context if such is
possible, which I know is possible, just tell the programmers its not
possible and they will do it.
Allan
Pit Suetterlin
>
> Hi all
>
> I recall there was some reason to keep the old preview next to the new
> one. Is this still the case, or can we forego the old preview and work
> with the new one only?
At least on my Laptop (no real 3D, uses Mesa) the fast preview (very) often
scrambles the images, so I have to use the old preview to see something...
Pit
--
Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit
Institute for Solar Physics
Tel.: +34 922 405 590 (Spain) P.Suet...@royac.iac.es
+46 8 5537 8534 (Sweden) Peter.Su...@astro.su.se