GUI overhaul

[T. Modes]

Hi group,

I overhauled the GUI of Hugin. I've taken some ideas from some
discussions on the list and also some own ideas. The main goal was to
reduce the complexity for beginners, but keep the full flexibility for
advanced users. For beginners only a reduce set of features is shown.
But the advanced user can activate it when needed.
Also the lens tab was removed. The functions moved to the images tab.
The images tab is now the main tab. The optimizer master switches has
also been moved to the images tab. When optimizer master switches are
selected, the optimizer and photometric optimizer tab are hidden. This
result in a cleaner interface (when using the master switches the
listboxes below had no function, there occupied only a lot of space).
And most of the work can done on the images tab. (Input + Optimisation
on images tab; output on stitcher tab).

When needing the advanced optimizer then set the optimizer to custom,
then the optimizer tab is shown. Also the optimizer tabs have been
extended. Beside customizing the optimize vector you can also change
image variables directly on these tabs (no need to switch to images/
lenses tab any more ;-) ).

I committed the code to an own branch gui_overhaul (not yet to the
default branch). I did some testing and hope that it works. But there
can be some bugs left. Please test and give feedback. Maybe we can
improve it further.
If there are no objection, then it could go into default branch.

Thomas

[Robert Krawitz]

On Sat, 5 May 2012 11:22:04 -0700 (PDT), T. Modes wrote:
> Also the lens tab was removed. The functions moved to the images tab.

Good. This distinction has always seemed gratuitous.
--
Robert Krawitz <r...@alum.mit.edu>

MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[arclance]

I tried building your gui_overhaul branch but it failed.

[ 82%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
ImagesPanel.cpp.o
In file included from /usr/include/c++/4.4/backward/hash_set:60,
from /usr/include/boost/pending/container_traits.hpp:
23,
from /usr/include/boost/graph/detail/
adjacency_list.hpp:31,
from /usr/include/boost/graph/adjacency_list.hpp:324,
from /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
hugin_gui_overhaul/src/hugin_base/algorithms/optimizer/ImageGraph.h:
36,
from /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
hugin_gui_overhaul/src/hugin_base/algorithms/optimizer/PTOptimizer.h:
216,
from /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
hugin_gui_overhaul/src/hugin1/PT/PTOptimise.h:30,
from /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
hugin_gui_overhaul/src/hugin1/hugin/ImagesPanel.cpp:49:
/usr/include/c++/4.4/backward/backward_warning.h:28:2: warning:
#warning This file includes at least one deprecated or antiquated
header which may be removed without further notice at a future date.
Please use a non-deprecated interface with equivalent functionality
instead. For a listing of replacement headers and interfaces, consult
the file backward_warning.h. To disable this warning use -Wno-
deprecated.
Linking CXX shared module _hsi.so
[ 82%] Built target _hsi
[ 82%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
CommandHistory.cpp.o
[ 82%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
PanoPanel.cpp.o
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp: In member function ‘virtual void
ImagesPanel::panoramaChanged(PT::Panorama&)’:
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp:192: error: cast from ‘void*’ to ‘int’
loses precision
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp:214: error: cast from ‘void*’ to ‘int’
loses precision
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp: In member function ‘void
ImagesPanel::OnGroupModeChanged(wxCommandEvent&)’:
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp:571: error: cast from ‘void*’ to ‘int’
loses precision
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp: In member function ‘void
ImagesPanel::OnOptimizerSwitchChanged(wxCommandEvent&)’:
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp:582: error: cast from ‘void*’ to ‘int’
loses precision
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp: In member function ‘void
ImagesPanel::OnPhotometricOptimizerSwitchChanged(wxCommandEvent&)’:
/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
hugin1/hugin/ImagesPanel.cpp:593: error: cast from ‘void*’ to ‘int’
loses precision
[ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
NonaOptionsDialog.cpp.o
[ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
HDRMergeOptionDialog.cpp.o
make[2]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/ImagesPanel.cpp.o]
Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/all] Error 2
make: *** [all] Error 2

[Harry van der Wolf]

Hi Thomas,

2012/5/5 arclance <arclan...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

I get another error message on OSX:
In file included from /Users/Shared/development/hugin_related/ExternalPrograms/repository/include/wx-2.8/wx/mac/private.h:4,
                 from /Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp:52:
/Users/Shared/development/hugin_related/ExternalPrograms/repository/include/wx-2.8/wx/mac/carbon/private.h: In function 'Rect* wxMacGetPictureBounds(Picture**, Rect*)':
/Users/Shared/development/hugin_related/ExternalPrograms/repository/include/wx-2.8/wx/mac/carbon/private.h:1375: warning: 'QDGetPictureBounds' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:1958)
/Users/Shared/development/hugin_related/ExternalPrograms/repository/include/wx-2.8/wx/mac/carbon/private.h:1375: warning: 'QDGetPictureBounds' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:1958)
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp: In member function 'bool wxTreeListItem::IsBold() const':
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp:950: warning: comparison is always false due to limited range of data type
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp: In member function 'void wxTreeListMainWindow::PaintItem(wxTreeListItem*, wxDC&)':
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp:3388: error: 'max' is not a member of 'std'
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp: In member function 'void wxTreeListMainWindow::PaintLevel(wxTreeListItem*, wxDC&, int, int&, int)':
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/treelistctrl.cpp:3589: error: 'max' is not a member of 'std'

[Bruno Postle]

On Sat 05-May-2012 at 12:58 -0700, arclance wrote:
>I tried building your gui_overhaul branch but it failed.
>
>[ 82%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/

>PanoPanel.cpp.o
>/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
>hugin1/hugin/ImagesPanel.cpp: In member function ‘virtual void
>ImagesPanel::panoramaChanged(PT::Panorama&)’:
>/media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
>hugin1/hugin/ImagesPanel.cpp:192: error: cast from ‘void*’ to ‘int’
>loses precision

I see the same error on fedora f16, this is with gcc-4.6.3.

--
Bruno

[arclance]

I am using #! 10 64bit BPO (debian squeeze+backports) and gcc-4.6.3.
I just built the latest default branch to check if some change there
was causing the error and it built with no problems.

[T. Modes]

Thats strange. I tested on f15, there it works. Now I installed f16,
and also here it works.

Nevertheless I modified the code and committed (works here on Windows
and f16). I hope, it compiles now also for you.

Thomas

[Bruno Postle]

On 6 May 2012 09:11, "T. Modes" <Thomas...@gmx.de> wrote:
> >
> > I see the same error on fedora f16, this is with gcc-4.6.3.
>
> Thats strange. I tested on f15, there it works. Now I installed f16,
> and also here it works.
>
> Nevertheless I modified the code and committed (works here on Windows
> and f16). I hope, it compiles now also for you.

Thanks, the build now works for f16 and f17. I'll try running it later if my children let me get anywhere near a computer.

--
Bruno

[Stefan Peter]

Dear arclance

> hugin1/hugin/ImagesPanel.cpp: In member function �virtual void
> ImagesPanel::panoramaChanged(PT::Panorama&)�:
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp:192: error: cast from �void*� to �int�
> loses precision
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp:214: error: cast from �void*� to �int�
> loses precision
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp: In member function �void
> ImagesPanel::OnGroupModeChanged(wxCommandEvent&)�:
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp:571: error: cast from �void*� to �int�
> loses precision
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp: In member function �void
> ImagesPanel::OnOptimizerSwitchChanged(wxCommandEvent&)�:
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp:582: error: cast from �void*� to �int�
> loses precision
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp: In member function �void
> ImagesPanel::OnPhotometricOptimizerSwitchChanged(wxCommandEvent&)�:
> /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> hugin1/hugin/ImagesPanel.cpp:593: error: cast from �void*� to �int�

> loses precision
> [ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
> NonaOptionsDialog.cpp.o
> [ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
> HDRMergeOptionDialog.cpp.o
> make[2]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/ImagesPanel.cpp.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/all] Error 2
> make: *** [all] Error 2
>

We have the same error in the nightly build for all AMD64 builds.
Further information can be found at
https://launchpad.net/~hugin/+archive/nightly/+packages

This indicates that some changes in trunk are the cause for this error.

Regards

Stefan Peter

--
"In summary, I think you are trying to solve a problem that may not
need to be solved, using a tool that is not meant to solve it, without
understanding what is causing your problems and without knowing how
the tool actually works in the first place :)"
Jeffrey J. Kosowsky on the backuppc mailing list

[arclance]

> > hugin1/hugin/ImagesPanel.cpp: In member function virtual void
> > ImagesPanel::panoramaChanged(PT::Panorama&) :
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp:192: error: cast from void* to int
> > loses precision
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp:214: error: cast from void* to int
> > loses precision
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp: In member function void
> > ImagesPanel::OnGroupModeChanged(wxCommandEvent&) :
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp:571: error: cast from void* to int
> > loses precision
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp: In member function void
> > ImagesPanel::OnOptimizerSwitchChanged(wxCommandEvent&) :
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp:582: error: cast from void* to int
> > loses precision
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp: In member function void
> > ImagesPanel::OnPhotometricOptimizerSwitchChanged(wxCommandEvent&) :
> > /media/Linux_Data/Programs_CB10/Hugin/src/hugin/hugin_gui_overhaul/src/
> > hugin1/hugin/ImagesPanel.cpp:593: error: cast from void* to int

> > loses precision
> > [ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
> > NonaOptionsDialog.cpp.o
> > [ 83%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/
> > HDRMergeOptionDialog.cpp.o
> > make[2]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/ImagesPanel.cpp.o]
> > Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > make[1]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/all] Error 2
> > make: *** [all] Error 2
>
> We have the same error in the nightly build for all AMD64 builds.

> Further information can be found athttps://launchpad.net/~hugin/+archive/nightly/+packages

>
> This indicates that some changes in trunk are the cause for this error.
>
> Regards
>
> Stefan Peter
>
> --
> "In summary, I think you are trying to solve a problem that may not
> need to be solved, using a tool that is not meant to solve it, without
> understanding what is causing your problems and without knowing how
> the tool actually works in the first place :)"
> Jeffrey J. Kosowsky on the backuppc mailing list

> We have the same error in the nightly build for all AMD64 builds.

> Further information can be found athttps://launchpad.net/~hugin/+archive/nightly/+packages

>
> This indicates that some changes in trunk are the cause for this error.
>
> Regards
>
> Stefan Peter

If by trunk you mean the default branch it builds fine for me.

[arclance]

Thanks it builds now though it crashes if you change the user
experience level without any images loaded.

hugin: /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
hugin_gui_overhaul/src/hugin_base/panodata/Panorama.h:211: virtual
const HuginBase::SrcPanoImage& HuginBase::Panorama::getImage(size_t)
const: Assertion `nr < state.images.size()' failed.
Aborted

There also appears to be no difference between the beginner, advanced,
and expert settings except on the optimizer tab which shows the X, Y,
and Z columns under advanced and expert but not beginner.
The optimizer and exposure tabs are not hidden in beginner, advanced,
or expert mode.
The optimizer tab is much harder to use now since there is no way to
activate an entire column with one click, same for the exposure tab.
The user must click the box for every image in a column they want to
activate or deactivate, there was a button to do this before.
You moved to optimizer master switches to the images tab but they are
nearly unusable there since the user can not see what effect the
different settings have without changing to the optimizer tab.
You moved to exposure master switches to the images tab but they are
nearly unusable there since the user can not see what effect the
different settings have without changing to the exposure tab.
If you want to put the the master switches on the images tab please
leave them on the other tabs, your layout is much more compact than
the old one, they do not take up much room, and you only want advanced
users to see these tabs anyway.
When you removed the lenses tab you did not move all of its
functionality to the images tab as you said.

Also the lens tab was removed. The functions moved to the images
tab.

There is no way there to set the lens parameters that were previously
found on the lens tab on the images tab.
I found this was actually moved to the optimizer tab but the columns
are only labeled with a single letter and not the actual variable
names as they were before.

[T. Modes]

> Thanks it builds now though it crashes if you change the user
> experience level without any images loaded.
>
> hugin: /media/Linux_Data/Programs_CB10/Hugin/src/hugin/
> hugin_gui_overhaul/src/hugin_base/panodata/Panorama.h:211: virtual
> const HuginBase::SrcPanoImage& HuginBase::Panorama::getImage(size_t)
> const: Assertion `nr < state.images.size()' failed.
> Aborted
>

Fixed now.

> There also appears to be no difference between the beginner, advanced,
> and expert settings except on the optimizer tab which shows the X, Y,
> and Z columns under advanced and expert but not beginner.

Thats wrong. The possible selections in the drop down boxes on the
images tab show also different values depending on the GuiLevel.

> The optimizer and exposure tabs are not hidden in beginner, advanced,
> or expert mode.

The are hidden depending on the master optimizer switches and not on
the GuiLevel.

> The optimizer tab is much harder to use now since there is no way to
> activate an entire column with one click, same for the exposure tab.
> The user must click the box for every image in a column they want to
> activate or deactivate, there was a button to do this before.

This can be done now with the context menu.

> You moved to optimizer master switches to the images tab but they are
> nearly unusable there since the user can not see what effect the
> different settings have without changing to the optimizer tab.
> You moved to exposure master switches to the images tab but they are
> nearly unusable there since the user can not see what effect the
> different settings have without changing to the exposure tab.
> If you want to put the the master switches on the images tab please
> leave them on the other tabs, your layout is much more compact than
> the old one, they do not take up much room, and you only want advanced
> users to see these tabs anyway.

The master switch say what will be optimized. So I don't need the long
lists to see it again. Also the lists are read only and will confuse a
new user.
If the master switch is doubled on the optimizer tab, we can't hide
the optimizer tabs any more.

> When you removed the lenses tab you did not move all of its
> functionality to the images tab as you said.
>
>     Also the lens tab was removed. The functions moved to the images
> tab.
>
> There is no way there to set the lens parameters that were previously
> found on the lens tab on the images tab.

Again, use the context menu.

Thomas

[arclance]

> > The optimizer tab is much harder to use now since there is no way to
> > activate an entire column with one click, same for the exposure tab.
> > The user must click the box for every image in a column they want to
> > activate or deactivate, there was a button to do this before.
>
> This can be done now with the context menu.
>

Where?
I could not find a way to toggle a whole column on or off in the right
click menu.

> > You moved to optimizer master switches to the images tab but they are
> > nearly unusable there since the user can not see what effect the
> > different settings have without changing to the optimizer tab.
> > You moved to exposure master switches to the images tab but they are
> > nearly unusable there since the user can not see what effect the
> > different settings have without changing to the exposure tab.
> > If you want to put the the master switches on the images tab please
> > leave them on the other tabs, your layout is much more compact than
> > the old one, they do not take up much room, and you only want advanced
> > users to see these tabs anyway.
>
> The master switch say what will be optimized. So I don't need the long
> lists to see it again. Also the lists are read only and will confuse a
> new user.
> If the master switch is doubled on the optimizer tab, we can't hide
> the optimizer tabs any more.
>

But then a new user will be unable to see what selections each of the
optimizer settings makes to compare them, they are not self
explanatory.
Why can you not hide the optimizer tab if it also has the switch on
it?

> > When you removed the lenses tab you did not move all of its
> > functionality to the images tab as you said.
>
> >     Also the lens tab was removed. The functions moved to the images
> > tab.
>
> > There is no way there to set the lens parameters that were previously
> > found on the lens tab on the images tab.
>
> Again, use the context menu.
>
> Thomas

Hiding everything under the Edit right click entry is not user
friendly.
This is because you have Position, Lens, Photometrics, and Camera
Response all under the edit entry but nowhere do you tell the user
what "Edit" allows you to edit.
If an experienced user could not find these settings how confusing do
you think this will be for a new user who needs to change these
settings?
You have a Lens entry in the right click menu I would expect to find a
"edit lens parameters" entry there even if it just opens your edit
window to the Lens tab.

[Tduell]

Hullo Thomas,

On May 6, 6:11 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
[snip]

>
> > I see the same error on fedora f16, this is with gcc-4.6.3.
>
> Thats strange. I tested on f15, there it works. Now I installed f16,
> and also here it works.
>
> Nevertheless I modified the code and committed (works here on Windows
> and f16). I hope, it compiles now also for you.

Builds OK here on Fedora 16 x86_64. It does seem to take a lot longer
to build, but that may be a wrong impression, as I didn't time it.
I am still finding my way around it, so will need to work with it a
bit more before expressing a view on whether it is all OK.
I guess having become familiar with the default gui I don't have too
many problems with it.
It will be interesting to see what new users think of it.
Thanks for your efforts Thomas.

Cheers,
Terry

[Harry van der Wolf]

Hi Thomas,

2012/5/7 Tduell <tdu...@iinet.net.au>

It now builds fine on OSX as well.

I will do further tests slightly later this week.
And need to do some minor changes to do to the calibrate_lens_gui and ptbatchergui bundle w.r.t. lensfun changes before I can release a bundle.

Harry

[Cristian Marchi]

Same problem for me when changing user experience level:
hugin: /home/cristian/unstable/hugin/src/hugin/hugin.hg/src/hugin_base/panodata/Panorama.h:211: virtual const HuginBase::SrcPanoImage& HuginBase::Panorama::getImage(std::size_t) const: Assertion `nr < state.images.size()' failed.
Annullato

 I'm on ubuntu 11.10 64bit.

[Bruno Postle]

On Sun 06-May-2012 at 12:03 +0100, Bruno Postle wrote:
>
>Thanks, the build now works for f16 and f17. I'll try running it later if
>my children let me get anywhere near a computer.

Ok, fedora packages seem to be ok now, I'm putting them here if
anyone wants to try:

http://repos.fedorapeople.org/repos/bpostle/panorama/

(this is also the new location for my repository of fedora snapshots
of panorama related software)

I need to try some real projects with this new GUI, but I'm glad to
see that output stacks and layers are finally visible in Hugin
before stitching!

These are my first thoughts: the beginner/advanced/expert switch
shouldn't be hidden in the Settings menu, maybe this could go in the
button bar?

The 'Display' options in the Images tab for showing different
columns in the table are quite fundamental, how can these be made
more obvious? In the old GUI there was a second level of tabs in
the Camera and Lens tab, this could work for the new Images tab.

I think the Images tab can be renamed 'Photos'.

--
Bruno

[Yuv]

I took advantage of a "bug" in the Ubuntu PPA nightly builder (should build the latest trunk, instead it build the latest updated branch at the time of pulling, which ends up being quite random) to try the overhauled GUI.  I had a couple of images to defish, no fancy projects.

First impression: well done, good job, it is an improvement.

the beginner/advanced/expert switch shouldn't be hidden in the Settings menu

Agree.  Also: I have not understood the difference between advanced and expert.  At least it was not immediately apparent to me.  Are three level of usage necessary, or would two be enough?
 

, maybe this could go in the button bar?

It has to be very visible -- not just the switch, also the level of the current interface being used.  How about changing the background colour, e.g. using a light blue for the advanced and a light yellow for the expert, with the same luminance as the grey used for the beginner/default?

Yuv

[Harry van der Wolf]

Hi

2012/5/8 Yuv <goo...@levy.ch>

I took advantage of a "bug" in the Ubuntu PPA nightly builder (should build the latest trunk, instead it build the latest updated branch at the time of pulling, which ends up being quite random) to try the overhauled GUI.  I had a couple of images to defish, no fancy projects.

First impression: well done, good job, it is an improvement.

the beginner/advanced/expert switch shouldn't be hidden in the Settings menu

Agree.  Also: I have not understood the difference between advanced and expert.  At least it was not immediately apparent to me.  Are three level of usage necessary, or would two be enough?

I have the same question.

 

, maybe this could go in the button bar?

It has to be very visible -- not just the switch, also the level of the current interface being used.  How about changing the background colour, e.g. using a light blue for the advanced and a light yellow for the expert, with the same luminance as the grey used for the beginner/default?

Yuv

I would prefer more clarity to the used mode as well but I don't like fiddling with background colors. Some interfaces are really terrible color wise and I prefer the grey backgrounds of many programs: It's the easiest and most comfortable for the eye. (I'm not a big fan of "skinning" either for that matter). Next to that: It might influence color schemes/themes within all kind of OSes. That's not nice behavior.
My preference would be to have a bold text (label) in the top right (or top left) saying: "mode: Beginner" or whatever mode you are working in. This text could also appear in the button bar (so much for "button" bar) if you want to keep the screen as clean as possible.

Harry

[Yuv]

On Tuesday, May 8, 2012 6:57:23 AM UTC-4, Harry van der Wolf wrote:
>
>
> I would prefer more clarity to the used mode as well but
> I don't like fiddling with background colors. Some interfaces
> are really terrible color wise and I prefer the grey
> backgrounds of many programs: It's the easiest and
> most comfortable for the eye. (I'm not a big fan of
> "skinning" either for that matter). Next to that: It might
> influence color schemes/themes within all kind of OSes.
> That's not nice behavior.

Like you I am not a big fan of "skinning" and did not consider the influence on existing colour schemes. You are right, I take back the suggestion of changing colour background.

> My preference would be to have a bold text (label) in
> the top right (or top left) saying: "mode: Beginner" or
> whatever mode you are working in. This text could
> also appear in the button bar (so much for "button"
> bar) if you want to keep the screen as clean as possible.

I wanted to get back into the new GUI and try to imagine this, but too late: the nightly repo has been updated and this time the most recent change was in the default branch, so I am back to trunk (or stable release). I need to set up a development environment on this PC, but there are other things on my priorities list for the coming weeks. I also need to either change my subscription to email again, or get used to Google's new web based interface (my apology if it sends out HTML mail to subscribers, I just found that there is one button on the editor bar to remove formatting, but it is not good and mangles up quoting.

Yuv

[T. Modes]

> > First impression: well done, good job, it is an improvement.
>
> > the beginner/advanced/expert switch shouldn't be hidden in the Settings
> >> menu

I don't see a point on adding extra buttons for this to the toolbar.
IMHO only function which are needed every day should be appear in the
toolbar. But in the daily work I don't think that someone is change
this level. A casual user should set the level to his needs and then
leave it. (Only when special features are necessary for a particular
project, then the level needs to be updated; but not every day.) So
for me the menu item is sufficient.

>
> > Agree.  Also: I have not understood the difference between advanced and
> > expert.  At least it was not immediately apparent to me.  Are three level
> > of usage necessary, or would two be enough?
>
> I have the same question.

Then I will solve the riddle:
In beginner only the basic function are shown (also the stitcher tab
shows only a reduced option set).
In advanced support for stacks and HDR is possible.
And in expert finally the translation parameters are shown and can be
optimized. Also the output layer/stacks are only shown in expert mode.
Because when this groups are shown the GUI can become slow responding.

> I would prefer more clarity to the used mode as well but I don't like
> fiddling with background colors. Some interfaces are really terrible color
> wise and I prefer the grey backgrounds of many programs: It's the easiest
> and most comfortable for the eye. (I'm not a big fan of "skinning" either
> for that matter). Next to that: It might influence color schemes/themes
> within all kind of OSes. That's not nice behavior.
> My preference would be to have a bold text (label) in the top right (or top

> left) saying: *"mode: Beginner"* or whatever mode you are working in. This

> text could also appear in the button bar (so much for "button" bar) if you
> want to keep the screen as clean as possible.

I implemented this label in changeset 7f384d763667.

Thomas

[Harry van der Wolf]

Currently building.

2012/5/8 T. Modes <Thomas...@gmx.de>

> > First impression: well done, good job, it is an improvement.
>
> > the beginner/advanced/expert switch shouldn't be hidden in the Settings
> >> menu

I don't see a point on adding extra buttons for this to the toolbar.
IMHO only function which are needed every day should be appear in the
toolbar. But in the daily work I don't think that someone is change
this level. A casual user should set the level to his needs and then
leave it. (Only when special features are necessary for a particular
project, then the level needs to be updated; but not every day.) So
for me the menu item is sufficient.

I agree, but maybe the label should not be "Settings", but something like "user mode" or maybe better: "gui mode". The term settings is too general and seems more like a general settings option panel for the entire application, and that's Preferences already.

 

> I would prefer more clarity to the used mode as well but I don't like
> fiddling with background colors. Some interfaces are really terrible color
> wise and I prefer the grey backgrounds of many programs: It's the easiest
> and most comfortable for the eye. (I'm not a big fan of "skinning" either
> for that matter). Next to that: It might influence color schemes/themes
> within all kind of OSes. That's not nice behavior.
> My preference would be to have a bold text (label) in the top right (or top

> left) saying: *"mode: Beginner"* or whatever mode you are working in. This

> text could also appear in the button bar (so much for "button" bar) if you
> want to keep the screen as clean as possible.

I implemented this label in changeset 7f384d763667.

Thomas

At least one happy user. ;)

Harry

 

[Harry van der Wolf]

And now after building I think the best label in the screen and in the menu is "Gui mode".

In the screen it is immediately clear what is meant with it and it automatically explains the the menu label as well.

(And for the insiders we create an extra label: "Gui tmodes")

(Away for the rest of the evening).

Harry

[T. Modes]

Hi Harry,

thanks for the propose. I changed the label.

@Bruno
I changed the display wxChoice to wxRadioBox. So I hope it is more
obvious. Using tabs would take some more space and it would be not so
nice for smaller screens (at least on GTK, on Windows it is not so
critical, not sure for OS X)

Thomas

[Bruno Postle]

On Tue 08-May-2012 at 12:52 -0700, Thomas Modes wrote:
>On 8 Mai, 20:14, Harry van der Wolf <hvdw...@gmail.com> wrote:
>
>thanks for the propose. I changed the label.
>

>I changed the display wxChoice to wxRadioBox. So I hope it is more
>obvious.

This is clearer, do you have any plans for what comes next? Can the
Crop and Mask tabs be merged with the Photos tab? Can the Assistant
be moved to the preview so the 'normal' Gui disappears altogether in
'beginner' mode? There is a lot of rarely used stuff in the preview
that must be very confusing for 'beginners'.

--
Bruno

[Bruno Postle]

On Tue 08-May-2012 at 12:52 -0700, Thomas Modes wrote:
>> And now after building I think the best label in the screen and in the menu
>> is "Gui mode".

I think this is much better, but I'm concerned the acronym GUI can't
make much sense to most people - How does it translate into other
languages? Hugin has lots of photography jargon, but this is
inevitable, there has to be a better word than GUI.

--
Bruno

[Tduell]

Hello Thomas,
I have just built the gui_overhaul branch (5783:67b229d0cf3a).
I found a problem with the Fast Preview Window. When in layout mode,
selecting one of the links between images opens up the Stitcher tab
instead of the Control points tab.
This behaviour is in all Gui modes.

Cheers,
Terry

[Gnome Nomad]

Probably just me being weird, but I suspect a lot of beginners just
follow the buttons on the Assistant tab: Load Images. Align. Create
panorama.

Starting to sound like someone's applying the de facto Gnome environment
design philosophy: "What functionality can we take away from the user
next?" Or a relative of it: "What else can we hide from users now?"

I like the idea of the Beginner/Expert UI toggle. I use ZynAddSubFx and
Yoshimi for music work. Both have a Beginner and an Expert UI mode. I
think the present Hugin UI is great for an Expert UI. I think the
Assistant tab could be turned into the Beginners UI.

I do wonder all this effort to merge tabs together (I don't happen to
agree with that, since some of the merges that have already been
mentioned have apparently made it harder to use!) when the logical UI
element for working on a panorama already exists in Hugin: the Panorama
Preview.

By the way, when I see a UI design in which the designer has to *explain
in a text email* how to do something in the new UI, the design has some
fundamental issues it needs to address.

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[Gnome Nomad]

GUI is a piece of programmer/UXD computer jargon that makes ordinary
people go "Huh?" Plus using "GUI" would imply (to more knowledgable
computer folker) that the alternative is a "TUI" (TEXT user interface),
not just a simplified GUI.

I vote for "Beginner Mode" and "Expert Mode". Makes sense in ZynAddSubFx
and Yoshimi!

[Harry van der Wolf]

2012/5/9 Gnome Nomad <gnome...@gmail.com>

GUI is a piece of programmer/UXD computer jargon that makes ordinary people go "Huh?" Plus using "GUI" would imply (to more knowledgable computer folker) that the alternative is a "TUI" (TEXT user interface), not just a simplified GUI.

I vote for "Beginner Mode" and "Expert Mode". Makes sense in ZynAddSubFx and Yoshimi!

I agree, that's better. 

And by the way: not only the photos tab needs this label, also the Stitcher tab.

Harry

[Thomas Pryds]

Den 08/05/2012 23.48 skrev

> Hugin has lots of photography jargon, but this is inevitable, there has to be a better word than GUI.

If a label, e.g. next to a checkbox, is needed, what about cutting down the acronym and let it say "user interface mode" or maybe just "interface mode"? Or even "user mode"?

Is the word interface easily understandable in English by someone who doesn't have any technical knowledge about computer programs?

I don't know this since English is not my first language, but in the Danish translation, GUI would probably just remain GUI (which would be confusing) since we, to my knowledge, don't have an acronym for that. So I also vote to avoid the word GUI.

Thomas

[Luís Henrique Camargo Quiroz]

    I agree too: interface is better than GUI -- especially for beginners :)

    I hope I could compile and test the overhauled GUI Hugin this weekend.

    Luís Henrique

-- 
Luis Henrique Camargo Quiroz, M.Sc. - Internal Combustion Engines Group
IPT - Sao Paulo State Technological Researches Institute 
phone: 55-11-37674391  fax: 55-11-37674784  www.ipt.br  BRAZIL
http://luishcq.tripod.com - http://www.christusrex.org/www2/cantgreg

[T. Modes]

Hi Bruno,

> This is clearer, do you have any plans for what comes next?  Can the
> Crop and Mask tabs be merged with the Photos tab?  Can the Assistant
> be moved to the preview so the 'normal' Gui disappears altogether in
> 'beginner' mode?  There is a lot of rarely used stuff in the preview
> that must be very confusing for 'beginners'.

I'm working currently on the merging of mask and crop tab. But it will
not go into the photo tab, there is not enough space.

Concerning the fast preview: I thought also on this, but I'm not sure.
There is still the issue with the crashing preview. I fixed some time
ago a further issue, but until now no feedback if it is really fixed.
In the fast preview I started to hide controls in the beginner mode:
currently only the mosaic drag controls are hidden for beginner. Which
control do you think can be confusing for beginner? These can also be
hidden in beginner mode.

Maybe after the merging I will have a look on the assistant in the
preview.

@Terry
I will fix this point when the above mentioned merge is done. It's on
my to do list.

Thomas

[Frederic Da Vitoria]

2012/5/9 T. Modes <Thomas...@gmx.de>

Concerning the fast preview: I thought also on this, but I'm not sure.
There is still the issue with the crashing preview. I fixed some time
ago a further issue, but until now no feedback if it is really fixed.
In the fast preview I started to hide controls in the beginner mode:
currently only the mosaic drag controls are hidden for beginner. Which
control do you think can be confusing for beginner? These can also be
hidden in beginner mode.

In the Windows 2011.4.0 version, the fast preview crash still occurs, although much much less frequently. For me, the current frequency of crash is quite acceptable, but others may disagree. And it seems some others have it at much higher rates than me.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[Bruno Postle]

On Tue 08-May-2012 at 19:11 -1000, Gnome Nomad wrote:
>
>I do wonder all this effort to merge tabs together (I don't happen to
>agree with that, since some of the merges that have already been
>mentioned have apparently made it harder to use!)

In the existing GUI there is the Images tab and there is the Camera
and Lens tab, which is actually another two tabs. They each show a
different set of image parameters, but some image parameters are not
shown at all, the 'filename' appears in both tabs, but not in the
Crop or Mask tab - This is all pretty random and shows the
incremental way it was built.

These tabs are each in the form of a list/table, but if I select a
photo or photos in the Images tab, then switch to the Camera and
Lens tab, different photos are selected. This makes it hard to add
a feature like 'click on a photo in the preview and select it in the
Images tab', or 'select two photos in the Camera and Lens tab and
show the same two photos in the Control Points tab'.

>when the logical UI element for working on a panorama already
>exists in Hugin: the Panorama Preview.

Yes, this is something often discussed, there is the potential to
turn Hugin inside-out - Make the Preview window the main window, with
the existing main window something you can close if you don't need
it. To do this the Assistant needs to move to the Preview.

--
Bruno

[Bruno Postle]

On Wed 09-May-2012 at 09:12 -0700, Thomas Modes wrote:
>
>Concerning the fast preview: I thought also on this, but I'm not sure.
>There is still the issue with the crashing preview. I fixed some time
>ago a further issue, but until now no feedback if it is really fixed.

I don't think there is any hurry, I'd like to hear what other people
think.

>In the fast preview I started to hide controls in the beginner mode:
>currently only the mosaic drag controls are hidden for beginner. Which
>control do you think can be confusing for beginner? These can also be
>hidden in beginner mode.

I'm in two minds about the beginner/advanced toggle, but I agree
that the mosaic mode should be invisible to new users. Looking at
the preview, maybe everything else is actually useful to beginners.

The Overview, Layout tab, and old preview are all supplementary
alternative views of the entire project, but they exist at totally
different levels. This is very confusing.

Would the Overview be more stable if it lost the whole docking thing
and became a 'normal' modeless window? The Layout tab could get the
same treatment, then if the old preview lost the duplicated widgets,
there would be three optional floating windows with complementary
but secondary functionality - Leaving a much less cluttered preview
window.

I'm just sounding out ideas here, clearly there are things that
could be better, but the solutions are not always obvious.

--
Bruno

[Bruno Postle]

On Wed 09-May-2012 at 09:12 -0700, Thomas Modes wrote:
>

>I will fix this point when the above mentioned merge is done. It's on
>my to do list.

One more bug: Good to see the g & t shear parameters in the GUI, but
they are filled with the same values as the d & e parameters.

--
Bruno

[Gnome Nomad]

On 05/09/2012 06:26 AM, Frederic Da Vitoria wrote:
> 2012/5/9 T. Modes <Thomas...@gmx.de <mailto:Thomas...@gmx.de>>

>
> Concerning the fast preview: I thought also on this, but I'm not sure.
> There is still the issue with the crashing preview. I fixed some time
> ago a further issue, but until now no feedback if it is really fixed.
> In the fast preview I started to hide controls in the beginner mode:
> currently only the mosaic drag controls are hidden for beginner. Which
> control do you think can be confusing for beginner? These can also be
> hidden in beginner mode.
>
>
> In the Windows 2011.4.0 version, the fast preview crash still occurs,
> although much much less frequently. For me, the current frequency of
> crash is quite acceptable, but others may disagree. And it seems some
> others have it at much higher rates than me.

Linux Hugin 2011.4.0.cf9be9344356 32-bit here running on boring old
Intel 855GM video hardware under Debian Sid crashes any time I try fast
preview. Have tried the various "fixes", even renaming the hidden
".hugin" file, with no change.

Same Hugin version works fine on Sid (64-bit) on my desktop PC with
NVidia graphics.

[Harry van der Wolf]

2012/5/10 Gnome Nomad <gnome...@gmail.com>

In the Windows 2011.4.0 version, the fast preview crash still occurs,
although much much less frequently. For me, the current frequency of
crash is quite acceptable, but others may disagree. And it seems some
others have it at much higher rates than me.

Linux Hugin 2011.4.0.cf9be9344356 32-bit here running on boring old Intel 855GM video hardware under Debian Sid crashes any time I try fast preview. Have tried the various "fixes", even renaming the hidden ".hugin" file, with no change.

Same Hugin version works fine on Sid (64-bit) on my desktop PC with NVidia graphics.

 

 

Did anyone look into the OpenGL versions and requirements for this fast preview? Which OpenGL calls are used, and as of which versions are these function calls valid, and which versions of OpenGL are installed on the various OSes?

Especially in combination with wxwindows and opengl.

We did all kind of version checks when "we" as various testers/builders first worked on this fast preview window during GSOC 2009 when James Legg was working on this.
Am I seeing ghosts and is the fast peview now OpenGL version independent, or could it be related to versions? And if so: Do our developers have up-to-date verions when compiling as they try to be up-to-date (at least I try) and have the users outdated versions?
Even with the automatic software updates on the linuxes this could be an issue when running on older distributions which no longer update libraries but only do security/bug fixes.

 

just my 2cents.

 

Harry

 

[Frederic Da Vitoria]

2012/5/10 Harry van der Wolf <hvd...@gmail.com>

Sorry, this is getting off-topic. It seems my Windows Vista has an emulated OpenGL 1.4 API but I use the standard NVIDIA driver which contains OpenGL 2.1.

[kfj]

On 9 Mai, 21:25, Bruno Postle <br...@postle.net> wrote:
>
> In the existing GUI there is the Images tab and there is the Camera
> and Lens tab, which is actually another two tabs.  They each show a
> different set of image parameters, but some image parameters are not
> shown at all, the 'filename' appears in both tabs, but not in the
> Crop or Mask tab - This is all pretty random and shows the
> incremental way it was built.

I often wondered if all of this couldn't be placed in one window. How?
By displaying it in a fashion which is often used for tabular data
displays: You start out with a standard set of columns, and by right-
clicking on the row with the column headers you get a context window
allowing you to add/remove columns. Augment that with left-clicking on
column headers to sort by this column, and you have a standard
interface many computer-literate people would feel instantly at home
with. This would leave it to the user to choose what they want to see/
can accomodate on their screen. I wouldn't even be surprised if the
appropriate widget type existed already in wxwidgets.

Kay

[Jim Watters]

On 2012-05-09 5:05 PM, Bruno Postle wrote:
> On Wed 09-May-2012 at 09:12 -0700, Thomas Modes wrote:
>
>> In the fast preview I started to hide controls in the beginner mode:
>> currently only the mosaic drag controls are hidden for beginner. Which
>> control do you think can be confusing for beginner? These can also be
>> hidden in beginner mode.
>
> I'm in two minds about the beginner/advanced toggle, but I agree that the
> mosaic mode should be invisible to new users. Looking at the preview, maybe
> everything else is actually useful to beginners.

I believe "simple is a better term than beginner".

Beginner mode, is using wizards that do everything for you. The Assistant tab.
Simple mode, is using a cleaner interface that hides all the advanced features
that are hardly used.
Advanced mode, is having every possible control available.

We just need to define what a simple stitch is and what is not necessary to
accomplish it.

--
Jim Watters
http://photocreations.ca

[Carl von Einem]

Jim Watters schrieb am 10.05.12 17:29:

> On 2012-05-09 5:05 PM, Bruno Postle wrote:
>> On Wed 09-May-2012 at 09:12 -0700, Thomas Modes wrote:
>>
>>> In the fast preview I started to hide controls in the beginner mode:
>>> currently only the mosaic drag controls are hidden for beginner. Which
>>> control do you think can be confusing for beginner? These can also be
>>> hidden in beginner mode.
>>
>> I'm in two minds about the beginner/advanced toggle, but I agree that
>> the mosaic mode should be invisible to new users. Looking at the
>> preview, maybe everything else is actually useful to beginners.
>
> I believe "simple is a better term than beginner".

How about "standard" and "advanced" modes?

Looking forward to see and try out a build with this interface overhaul.

Carl

[Bart van Andel]

What about "easy", "medium", "hard"?

Now we still have to find a way to implement "fatality" ;-)

Without kidding: I think "guided", "standard" and "expert mode" are pretty nice. Guided being assistant only, basically (except maybe from some basic viewpoint selection using the preview window).

--

Bart

[Ian Tindale]

What about “Normal” and “Nerd”?

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
Ian Tindale

[Serge Droz]

Hello List,

I've tried out the latest (5786:fd5019496dd1) version of hugin with the
new GUI. Here some feedback:


- I have two Optimizer tabs, only the on can be clicked.
- There is no Stitch tab, and I haven't figured out how to stitch from
the GUI
- In the Old GUI, I liked the drop down in the Optimizer menu, that
gave the different stitching options.
This allows to play around without understanding in detail what's
happening.


I've used a self-compiled version on a Fedora 16 x86-64 system. And I'm
happy to try out further version. Thanks for the great work.

Serge

[Serge Droz]

There was a problem building, which I fixed. I did need the appended
patch.

> - I have two Optimizer tabs, only the on can be clicked.
> - There is no Stitch tab, and I haven't figured out how to stitch
> from the GUI

The remark below stands

> - In the Old GUI, I liked the drop down in the Optimizer menu, that
> gave the different stitching options.
> This allows to play around without understanding in detail what's
> happening.
>

Best regards
Serge

[Gnome Nomad]

I think user would get overwhelmed with columns and sideways scrolling
... prefer having separate tabs with focused functionality.

[Frederic Da Vitoria]

2012/5/14 Gnome Nomad <gnome...@gmail.com>

On 05/10/2012 02:01 AM, kfj wrote:

On 9 Mai, 21:25, Bruno Postle<br...@postle.net>  wrote:

In the existing GUI there is the Images tab and there is the Camera
and Lens tab, which is actually another two tabs.  They each show a
different set of image parameters, but some image parameters are not
shown at all, the 'filename' appears in both tabs, but not in the
Crop or Mask tab - This is all pretty random and shows the
incremental way it was built.

I often wondered if all of this couldn't be placed in one window. How?
By displaying it in a fashion which is often used for tabular data
displays: You start out with a standard set of columns, and by right-
clicking on the row with the column headers you get a context window
allowing you to add/remove columns. Augment that with left-clicking on
column headers to sort by this column, and you have a standard
interface many computer-literate people would feel instantly at home
with. This would leave it to the user to choose what they want to see/
can accomodate on their screen. I wouldn't even be surprised if the
appropriate widget type existed already in wxwidgets.

I think user would get overwhelmed with columns and sideways scrolling ... prefer having separate tabs with focused functionality.

What about something in between: a column for image names, and at it's right the tabs. Maybe the user could even create his own user tab where he would put whatever column combination suits his needs. I don't know if such a design is easily implementable with the design tools used for Hugin, though.

[Bruno Postle]

I'm using 5795:efecb20de05a gui_overhaul branch and get a segfault
in the Crop tab, either by clicking on the photo or trying to edit
the values manually.

This is both with existing projects that already have crop settings
and projects that don't. The Mask part seems to be ok.

--
Bruno

[Bruno Postle]

On Sun 13-May-2012 at 21:37 +0200, Serge Droz wrote:
>
> The remark below stands
>
> > - In the Old GUI, I liked the drop down in the Optimizer menu,
> > that gave the different stitching options.
> > This allows to play around without understanding in detail
> > what's happening.

These still exist, but they are now on the Photos tab. I agree that
this is non-optimal, but also agree that they shouldn't be
duplicated.

Maybe the Optimiser and Exposure tabs don't need to disappear in
'beginner' mode, or maybe these drop-down presets should be part of
the 'advanced' mode.

What do people see as necessary beginner/advanced/expert
functionality?

Personally I think of the Assistant as 'beginner', and anything to
do with bracketing or XYZ mosaics as 'expert', i.e. things that
should be well hidden unless you go looking for them. Everything
else in the GUI is relevant to tweaking stuff that happens behind
the scenes of the Assistant.

--
Bruno

[Tduell]

Here, using 5797:e50102732dad gui_overhaul branch, I can click on
photo OK, but if I select 'reset' Hugin disappears.

Cheers,
Terry

[Margaret Wong]

Good morning

As a relative beginner (and I haven't been able to compile older versions of hugin on my system (Suse 11.4) so wait for someone  more experienced), I do bracketing and XYZ mosaics and did those nearly from day one of using hugin so I don't think that they should disappear to be dragged from the depths when required.  It took me ages to realise that an XYZ mosaic wasn't a pano in  strict terms.

--
kind regards

Margaret

[Jim Watters]

On 2012-05-14 7:45 PM, Margaret Wong wrote:

Personally I think of the Assistant as 'beginner', and anything to do with bracketing or XYZ mosaics as 'expert', i.e. things that should be well hidden unless you go looking for them.  Everything else in the GUI is relevant to tweaking stuff that happens behind the scenes of the Assistant.

As a relative beginner (and I haven't been able to compile older versions of hugin on my system (Suse 11.4) so wait for someone  more experienced), I do bracketing and XYZ mosaics and did those nearly from day one of using hugin so I don't think that they should disappear to be dragged from the depths when required.  It took me ages to realise that an XYZ mosaic wasn't a pano in  strict terms.

The transition from Beginner to Advance of Hugin will be much faster for someone that is already an Advanced user of computers. Most Linux users especially anyone that is compiling or attempting to compile applications on their system is an Advanced computer user.

As an Expert in shooting and stitching panoramas I would prefer to see a simple GUI unless I want to use some of advanced technique.

This was why I suggested the name Simple instead of Beginner. The idea is to show as few controls that are necessary to do the most common simple stitching.

If a user wants to use an advanced shooting technique, like not keep the camera rotated around the NPP then they will need the Advanced mode to stitch those images together.

[Oskar Sander]

Great! 

Has anyone built a windows test version of this that could be shared for playing around with?

Cheers
/O

2012/5/15 Jim Watters <jwat...@photocreations.ca>

--
/O

[Tduell]

On May 15, 12:59 pm, Tduell <tdu...@iinet.net.au> wrote:
[snip]

> Here, using 5797:e50102732dad gui_overhaul branch, I can click on
> photo OK, but if I select 'reset' Hugin disappears.

This all seems to be working OK now with 5799:686e0c2aaa3e.

I can't find how to add local lens data or lensfun data in the new
gui.
Am I suffering from a form of 'domestic blindness' or is that function
not yet implemented?

Cheers,
Terry

[Tduell]

On May 16, 9:45 am, Tduell <tdu...@iinet.net.au> wrote:
[snip]

> I can't find how to add local lens data or lensfun data in the new
> gui.
> Am I suffering from a form of 'domestic blindness' or is that function
> not yet implemented?

Found it! Photos tab, right click, context menu, Lens > ...

Cheers,
Terry

[Gnome Nomad]

On 05/13/2012 09:04 PM, Frederic Da Vitoria wrote:
> 2012/5/14 Gnome Nomad <gnome...@gmail.com <mailto:gnome...@gmail.com>>

>
> On 05/10/2012 02:01 AM, kfj wrote:
>
> On 9 Mai, 21:25, Bruno Postle<br...@postle.net

Well, if it makes sense to have image names on a tab, putting them in a
column would be fine. I like the tabs across the top, personally, not
down the side. Of course, that could a user configurable option.

[Frederic Da Vitoria]

2012/5/16 Gnome Nomad <gnome...@gmail.com>

First, what I am thinking may be completely wrong, I am on Windows, so I did not see the new GUI.

Sorry, I was not clear, I did not mean tabs down the side (I think you meant something like vertical :-/ ) I meant tabs within tabs. In the images tab, on the left a single column list of image names, and in the right part of the images tab add a sub-tab which would allow to choose the set of colums. Either Camera and Lens sub-tabs or Camera, Lens and User (the user could decide his columns in this last tab) When the user selects one (or several) image name(s), the row(s) would be select in all the sub-tabs. This way, the user could select on scroll to any image and easily switch the different column sets.

I hope I am making myself clearer. If I don't, I'll try to draw a mock-up.

OTOH, a tab within a tab may be not quite user-friendly. For example, which tab set should the Ctrl+Tab shortcut control?

[Bruno Postle]

On Wed 16-May-2012 at 11:05 +0200, Frederic Da Vitoria wrote:
>
> Sorry, I was not clear, I did not mean tabs down the side (I think
> you meant something like vertical :-/ ) I meant tabs within tabs.
> In the images tab, on the left a single column list of image
> names, and in the right part of the images tab add a sub-tab which
> would allow to choose the set of colums.

This is more-or-less how the current version of the gui_overhaul
looks, though rather than a secondary set of tabs there are 'radio
button widgets' for the various 'views' of columns.

--
Bruno

[Yuv]

On Tuesday, May 15, 2012 6:58:02 AM UTC-4, Jim Watters wrote:

On 2012-05-14 7:45 PM, Margaret Wong wrote:

Personally I think of the Assistant as 'beginner', and anything to do with bracketing or XYZ mosaics as 'expert', i.e. things that should be well hidden unless you go looking for them.  Everything else in the GUI is relevant to tweaking stuff that happens behind the scenes of the Assistant.

As a relative beginner I do bracketing and mosaics and did those nearly from day one.  It took me ages to realise that an XYZ mosaic wasn't a pano in  strict terms.

As an Expert in shooting and stitching panoramas I would prefer to see a simple GUI unless I want to use some of advanced technique.

This was why I suggested the name Simple instead of Beginner. The idea is to show as few controls that are necessary to do the most common simple stitching.

If a user wants to use an advanced shooting technique, like not keep the camera rotated around the NPP then they will need the Advanced mode to stitch those images together.

I agree with both Margaret and Jim.  The current terminology reflects an inward view that has nothing to do with the level of proficiency of the user -- neither in terms of computing nor in terms of photography.  It draws an arbitrary line in the sand.  Why should XYZ be considered more advanced than bracketing?  only because it requires more parameters?  was added later?  Added technological complexity?

The current UI simplification is great from an expert perspective and I fully agree with Jim's view and support his terminology.  The beginner/advanced/expert terminology is misleading.  A real beginner is somebody who does not know the strict terms (to paraphrase Margaret) yet.  For a beginner it does not matter whether the stitch was achieved with ypr/XYZ/morph-to-fit (BTW, good stuff, Bruno!) and whether visual uniformity was achieved with bracketing/exposure correction/blending.  Without detracting from the current UI, which I find is a significant improvement, the terminology is not very helpful for beginners.

What would help beginners are assistants; e.g. code that detects bracketed shooting and asks the user if they want to switch those features of the UI on (and even offers some guidance, maybe even automation); or code that detects bad geometrical alignment which could be improved with XYZ and asks the user if they want to activate that feature of the UI.  The manual switch implemented now is good for experts.

I repeat: the new GUI is good progress, but don't raise expectations it can't meet by giving the impression that the simple UI is for beginners.  Even if the new GUI is an improvement for (almost) everybody, it adds more to experts than to beginners.

Yuv

[Naked Robot]

hi,

1) agree with jim. replace "beginner" with "simple". and probably "advanced" for the second mode, and don't have 3 modes.

2) the one most annoying thing about Hugin is still there: when I automatically align the images, it also does photometric correction, and then I don't know how to turn it off. With this new design i *really* don't know how to turn it off - beginner or advanced, whatever.

On Saturday, May 5, 2012 8:22:04 PM UTC+2, T. Modes wrote:

Hi group,

I overhauled the GUI of Hugin. I've taken some ideas from some
discussions on the list and also some own ideas. The main goal was to
reduce the complexity for beginners, but keep the full flexibility for
advanced users. For beginners only a reduce set of features is shown.
But the advanced user can activate it when needed.
Also the lens tab was removed. The functions moved to the images tab.
The images tab is now the main tab. The optimizer master switches has
also been moved to the images tab. When optimizer master switches are
selected, the optimizer and photometric optimizer tab are hidden. This
result in a cleaner interface (when using the master switches the
listboxes below had no function, there occupied only a lot of space).
And most of the work can done on the images tab. (Input + Optimisation
on images tab; output on stitcher tab).

When needing the advanced optimizer then set the optimizer to custom,
then the optimizer tab is shown. Also the optimizer tabs have been
extended. Beside customizing the optimize vector you can also change
image variables directly on these tabs (no need to switch to images/
lenses tab any more ;-) ).

I committed the code to an own branch gui_overhaul (not yet to the
default branch). I did some testing and hope that it works. But there
can be some bugs left. Please test and give feedback. Maybe we can
improve it further.
If there are no objection, then it could go into default branch.

Thomas

[Monkey]

Hi all,

There is one thing that always annoys me when I use Hugin, and it's this:

http://img716.imageshack.us/img716/9391/stitcher.png

On the stitcher tab, which panorama output option should I tick if I want a blended, not exposure corrected, low dynamic range panorama?

In fact I think many of these options are pretty confusing, especially to a beginner. I usually end up just using the "No exposure correction" for remapped images and blending them on the command line.

David

[Dale Beams]

XYZ is in a universal language, that of experts, of mathematicians.  It is the language of XYZ that allows us to situate ourselves in a spatial 3d world.

---

Date: Wed, 16 May 2012 18:47:18 -0700
From: goo...@levy.ch
To: hugi...@googlegroups.com
Subject: Re: [hugin-ptx] Re: GUI overhaul

[Bruno Postle]

On Wed 16-May-2012 at 18:47 -0700, Yuv wrote:
>
>I agree with both Margaret and Jim. The current terminology reflects an
>inward view that has nothing to do with the level of proficiency of the
>user -- neither in terms of computing nor in terms of photography. It
>draws an arbitrary line in the sand. Why should XYZ be considered more
>advanced than bracketing?

XYZ is still very unstable, most of the time it goes and does
something weird. If you are careful you can get very good results,
but this does make it 'expert' functionality.

--
Bruno

[Bruno Postle]

On Thu 17-May-2012 at 03:54 -0700, David Horman wrote:
>
>On the stitcher tab, which panorama output option should I tick if I want a

>blended, *not* exposure corrected, low dynamic range panorama?

At the moment you need to reset all photometric parameters in the
Images tab, then stitch as normal.

What is your objection to the exposure correction? You don't want
any exposure correction, even from the EXIF data? or you don't like
the values that the photometric optimisation comes up with?
Sometimes the photometric optimiser doesn't work so well, especially
if the geometric alignment hasn't found a good alignment first - but
this could be fixed with an extra rule in the assistant.

--
Bruno

[Monkey]

I shoot on manual and trust my blender to correct any other exposure difference (which should be very little), and I think having to reset all parameters to 0 to turn it "off" (when in fact it's still on, just at 0 strength, as it were) is pretty convoluted.

A "no exposure correction" option seems very sensible to me - is this really something no-one else ever wanted? :S

David

[Bruno Postle]

On Thu 17-May-2012 at 15:32 -0700, David Horman wrote:
>I shoot on manual and trust my blender to correct any other exposure
>difference (which should be very little), and I think having to reset all

>parameters to 0 to turn it "off" (when in fact it's still *on*, just at 0

>strength, as it were) is pretty convoluted.

You don't have to set the Eev to 0, you can set it to 1 or 1000, so
long as it is the same for all photos. Eev is a log scale so '0'
doesn't really mean 'off'.

What would be wrong with setting them to the EXIF exposure values
rather than calculating them through optimisation?

--
Bruno

[Thomas Pryds]

2012/5/18 Monkey <davidh...@gmail.com>

I shoot on manual and trust my blender to correct any other exposure difference (which should be very little), and I think having to reset all parameters to 0 to turn it "off" (when in fact it's still on, just at 0 strength, as it were) is pretty convoluted.

A "no exposure correction" option seems very sensible to me - is this really something no-one else ever wanted? :S

I would imagine a number of checkbox switches, one for exposure correction, one for stacks, one for HDR, etc., instead of the current checkboxes under "Panorama Outputs" and "Remapped Images" in the Stitcher tab (current layout; haven't seen the GUI overhaul) to be more intuitive. Just a thought.

Thomas

[kfj]

On 18 Mai, 00:08, Bruno Postle <br...@postle.net> wrote:
> On Thu 17-May-2012 at 03:54 -0700, David Horman wrote:

> >On the stitcher tab, which panorama output option should I tick if I want a
> >blended, *not* exposure corrected, low dynamic range panorama?
>
> At the moment you need to reset all photometric parameters in the
> Images tab, then stitch as normal.
>
> What is your objection to the exposure correction?  You don't want
> any exposure correction, even from the EXIF data? or you don't like
> the values that the photometric optimisation comes up with?

One situation where I find I have to work without exposure correction
(beyond merely reading the EXIF data) is when I do takes outdoors with
swiftly moving clouds. They can result in the photometric optimization
going wrong, because the assumption that the same spot in different
images is equally bright doesn't hold anymore. The blender will still
make a good panorama in the end, but with photometric optimization I
sometimes get overexposed bits with weird colours.

Kay

[Drozilla]

>> > - In the Old GUI, I liked the drop down in the Optimizer menu, >
>> that gave the different stitching options. > This allows to play
>> around without understanding in detail > what's happening.
>
> These still exist, but they are now on the Photos tab. I agree that
> this is non-optimal, but also agree that they shouldn't be duplicated.
>

Thanks for pointing this out. That's fine with me. But I would then
completely remove the Optimizer Tab. Right now it seems to pop on and
off in my installation.

Also, there should be a preselection in the GUI, so I can just click
"Calculate".

We can never come up with a GUI that suites everybody. For GUI's it's
important that they remain stable, so people can stay in their workflow.
So we should create a useful GUI and then stick to it.

I'm all in favour of simple/advanced: Normaly I i want to get things
done quickly, and they work. In some occasions a Pano is difficult to
assemble, and then I need all the extra tweaking.

Cheers
Serge

[Harry van der Wolf]

Hi,

I do get a compilation error in the latest 5804 version when compiling AssistantPanel.cpp
/Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/AssistantPanel.cpp:420: error: 'HUGIN_ASS_PREVIEW' was not declared in this scope

The 5799 version compiled correctly.

Harry

[T. Modes]

Hi Harry,

On 19 Mai, 12:07, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi,
>
> I do get a compilation error in the latest 5804 version when compiling
> AssistantPanel.cpp
> /Users/Shared/development/hugin_related/gui_overhaul/mac/../src/hugin1/hugin/AssistantPanel.cpp:420:
> error: 'HUGIN_ASS_PREVIEW' was not declared in this scope

I removed the now obsolete AssistantPanel.h/.cpp files from the CMake
build. I forgot to remove the files (fixed in changeset 49acc6d432c6).
You need probably to remove the files from your XCode project.

Thomas

[Harry van der Wolf]

2012/5/19 T. Modes <Thomas...@gmx.de>

Right. Compiles fine now.

Harry

[Yuv]

Thank you for giving me the rationale for the three levels.  Based on your feedback above, I now understand why there are three (and not two) levels and I suggest that the three GUI level be called *simple* (S), *full* (F), *experimental* (E).  The stability or not of XYZ has nothing to do with the user's proficiency (beginner/expert/advanced) but with the software complexity (S vs F) and maturity (F vs E).  Eventually E features will mature and migrate to F (in most cases).
 

--
Bruno

[Harry van der Wolf]

Just compiled the 5806:49acc6d432c6 version.

I do like the combined assistant/preview mode. However, after cpfind has finished and the images are laid out in the preview, the view is always too small. I always have to zoom out, using the slider, to make the entire pano fit in the preview.
Is this on purpose or a small glitch or an OSX glitch/feature?

Harry

[Harry van der Wolf]

And..

the menu doesn't function correctly anymore. In the menu I have from left to right: Hugin, File, Edit, etc.
Below hugin was always the "Stop Hugin" option/action. It's still there but it doesn't function anymore.
Suddenly below File there is also a "Stop" option/action. That one works.

The rest functions as it should.

Harry

2012/5/19 Harry van der Wolf <hvd...@gmail.com>

--
Hugin development bundles for Mac OS X
ImageFuser for Mac OS X
KImageFuser for Linux

[brian_ims]

Thomas,

Just compiled 2011.5.0.8bf549feffa8 on windows and note following:

- opens in 'beginner' mode and cannot see anyway of changing

- an assertion error
(src\hugin1\hugin\HFODialog.cpp:58)HFOVDialog"HFOVDialog():():m_cropText)
occurs when loading photos unless I first open preferences and hit apply

- images must be in correct order before cpfind generates points (could be
true of older versions not checked)

- the general panini projection slides extend off side of my 1024 laptop
screen - this is an old problem but the work around was to use the slow
preview screen

- with an earlier version of revised gui could not see how to unlink lenses
etc and presume same with this one

Keep up the good work
--
View this message in context: http://old.nabble.com/GUI-overhaul-tp33801263p33877084.html
Sent from the hugin ptx mailing list archive at Nabble.com.

[Harry van der Wolf]

Hi Brian,

2012/5/20 brian_ims <im...@netspace.net.au>

Thomas,

Just compiled 2011.5.0.8bf549feffa8 on windows and note following:

- opens in 'beginner' mode and cannot see anyway of changing

I can only answer this first point as I ran into it as well yesterday. In the "File" menu you have the "Edit Panorama"  option. This will switch to the " old" gui where you also have the menu option with the Simple, Advanced, Expert option.

Harry
 

[Gnome Nomad]

On 05/19/2012 07:47 PM, brian_ims wrote:
>
> Thomas,
>
> Just compiled 2011.5.0.8bf549feffa8 on windows and note following:
>
> - opens in 'beginner' mode and cannot see anyway of changing
>
> - an assertion error
> (src\hugin1\hugin\HFODialog.cpp:58)HFOVDialog"HFOVDialog():():m_cropText)
> occurs when loading photos unless I first open preferences and hit apply
>
> - images must be in correct order before cpfind generates points (could be
> true of older versions not checked)

I've never needed to put images in any "correct" order before cpfind
generates points. I just tried with some images: loaded them, then used
Move Up and Move Down to put them in arbitrary order. cpfind about
control points. But that's using the release version.

[Naked Robot]

On Friday, May 18, 2012 12:08:34 AM UTC+2, Bruno Postle wrote:

What is your objection to the exposure correction?  You don't want
any exposure correction, even from the EXIF data? or you don't like
the values that the photometric optimisation comes up with?  

it sometimes gives bad results. e.g. one of the images for the sky come out grey, and it would have been better without any optimization.

 

[Serge Droz]

Hello,

two issues here:

1) in version (5806:49acc6d432c6)

I get an crash if I want do delete more than one image from a project.

I do the following: Open project -> Go to Photos Tab
select two or more images at the *end* of the list. Right click "remove
selected image(s)'.
>
> hugin: /scratch/redhat/BUILD/hugin/src/hugin_base/panodata/Panorama.h:211: virtual const HuginBase::SrcPanoImage& HuginBase::Panorama::getImage(std::size_t) const: Assertion `nr < state.images.size()' failed.
> Aborted (core dumped)



2) The latest (5808:d3a70fb21358) version does not compile:

> In file included from /usr/include/wx-2.8/wx/dialog.h:154:0,
> from /usr/include/wx-2.8/wx/wx.h:61,
> from /scratch/redhat/BUILD/hugin/src/hugin1/panoinc_WX.h:40,
> from /scratch/redhat/BUILD/hugin/src/hugin1/hugin/MainFrame.cpp:33:
> /usr/include/wx-2.8/wx/dialog.h: In copy constructor �wxDialog::wxDialog(const wxDialog&)�:
> /usr/include/wx-2.8/wx/dialog.h:138:14: error: �wxDialogBase::wxDialogBase(const wxDialogBase&)� is private
> /usr/include/wx-2.8/wx/gtk/dialog.h:32:7: error: within this context
> In file included from /scratch/redhat/BUILD/hugin/src/hugin1/hugin/MainFrame.cpp:44:0:
> /scratch/redhat/BUILD/hugin/src/hugin1/hugin/PreferencesDialog.h: In copy constructor �PreferencesDialog::PreferencesDialog(const PreferencesDialog&)�:
> /scratch/redhat/BUILD/hugin/src/hugin1/hugin/PreferencesDialog.h:38:7: note: synthesized method �wxDialog::wxDialog(const wxDialog&)� first required here
> /scratch/redhat/BUILD/hugin/src/hugin1/hugin/MainFrame.cpp: In member function �void MainFrame::OnShowPrefs(wxCommandEvent&)�:
> /scratch/redhat/BUILD/hugin/src/hugin1/hugin/MainFrame.cpp:1269:108: note: synthesized method �PreferencesDialog::PreferencesDialog(const PreferencesDialog&)� first required here
> make[2]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/MainFrame.cpp.o] Error 1
> make[2]: Leaving directory `/scratch/redhat/BUILD/hugin'
> make[1]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/all] Error 2
> make[1]: Leaving directory `/scratch/redhat/BUILD/hugin'
> make: *** [all] Error 2


Cheers
Serge

[Harry van der Wolf]

Hi

2012/5/20 brian_ims <im...@netspace.net.au>

Thomas,

- images must be in correct order before cpfind generates points (could be
true of older versions not checked)

I can confirm this but it has nothing to do with cpfind. It has to do with the photometric optimization.
If you run everything manual from the edit panorama->photos tab like add images (in random order), run cpfind, do the optimization and then the photometric optimization you get an error that it can't find overlapping points.

In the automatic assistant mode you don't get any results at all which makes it look like as if cpfind didn't work.

Harry

[Jan Martin]

Thomas,

great work!

On the Optimizer Tab, the 'Image Orientation' and  'Lens Parameters' frames are fixed size ca. 2:1.
I often have lots of data in the small 'Lens Parameters' frame and would like to make it bigger for easy access.
Can we have a handle to resize?

Thanks,
Jan

--

[Bruno Postle]

So some solutions could be:

Using celeste to prevent the photometric optimiser from sampling
areas with clouds, presumably this would get better results.

Backing out and reverting to just EXIF Eev if the optimiser finds
unlikely photometric values. Similar to how the Assistant currently
operates with geometric parameters.

A switch in the preferences to never do photometric optimisation,
just always use EXIF Eev. You might want this in huge projects
anyway.

--
Bruno

[Tduell]

On May 20, 4:03 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:

> I can only answer this first point as I ran into it as well yesterday. In
> the "File" menu you have the "Edit Panorama"  option. This will switch to
> the " old" gui where you also have the menu option with the Simple,
> Advanced, Expert option.

The 'inverse' of this is if you have the 'Expert' option set , when
you start Hugin, you don't have access to the 'Assistant' until you
add images. Probably not a serious issue, but the "Assistant' is
always available in the default branch (old) gui.
I like to use the 'Assistant' mode, and then fall back to the more
advanced capabilities if necessary, and would probably prefer not to
have to be changing my mode selection back and forth to do this...ie.
always in 'Expert' mode but be able to use the 'Assistant' immediately
I start Hugin.
One other thing that caught me out, is that if you start in the
'Simple' mode, and then open the old gui via 'file > edit Panorama',
closing the Fast Preview Window kills everything. Using the 'old'
Hugin, I tend to open and close the FPW as needed. I guess this is a
familiarity thing, and really only applies if your startup mode is
'Simple'.

Cheers,
Terry

[John Eklund]

After sticking to an old Hugin version for years ("if it ain't broken, don't fix it"), I finally created a project which made the old cpfind crash (500 images gigapixel), so I reminded myself that new is not necessarily bad, took the plunge and upgraded to Hugin 2015.0.0.

Wow what a change! And not just for the better. I used to be a Hugin power user. Now I feel like an amateur again. There are some frustrating nags. Here are the most important ones:

1. Hiding the Optimizer and Exposure windows is confusing. I want everything! I am using the Expert interface and still Hugin hides things from me.

Why are automatic optimizations moved to the Photos tab while custom optimizations remain on the Optimizer tab? Confusing. I also miss the connection between exactly what parameters are marked when selecting a predefined optimization. I want to see what is what. I often select one of the predefined optimizations as a quick way of mass-ticking parameters as a basis and then elaborating on them manually before actually optimizing "custom parameters". Thankfully this still works but doing it in separate tabs is tedious and confusing.

2. Thanks to #1, it took me a while before I found how to change / delete a lens. Why are there no buttons? "Every" function should exist as a button, not just in the right-click menu.

3. Underlining & bolding the parameters selected for optimization makes them hard to distinguish. Please go back to checkboxes, which makes it possible using Tab and Space to mark the boxes. Ctrl-clicking is tedious.

4. Resetting ALL exposure correction (incl EV) should be more obvious. I mix images created in Enfuse with straight-from-camera images with images that have been manipulated with ancient tools and a tool I've developed myself (PicStack) that do not retain any EXIF data. I know what I'm doing and adjust every image by hand before touching Hugin. I never want Hugin to know anything about exposure. I had a hard time figuring out how to get rid of the EV values for EXIF-containing images. Why are these not reset by "Reset lens parameters" and I have to instead "Reset user defined..."?

Any hopes of getting these nags rectified?

Best regards
John Eklund, Sweden

Some of my work:
http://www.elmuseum.se/panorama/

[John Eklund]

Made a typo. Last sentence of #4 should obviously be:

Why are these not reset by "Reset photometric parameters" and I have to instead "Reset user defined..."?

/John

[Terry Duell]

Hello John,

On Fri, 18 Sep 2015 05:06:22 +1000, John Eklund <jcl...@gmail.com> wrote:

> After sticking to an old Hugin version for years ("if it ain't broken,
> don't fix it"), I finally created a project which made the old cpfind
> crash (500 images gigapixel), so I reminded myself that new is not
> necessarily
> bad, took the plunge and upgraded to Hugin 2015.0.0.
>
> Wow what a change! And not just for the better. I used to be a Hugin
> power user. Now I feel like an amateur again. There are some frustrating
> nags.

[snip]

> Any hopes of getting these nags rectified?
>

I initially wasn't going to respond as I didn't think I had very much that
was helpful to say on this, but finally reneged as I didn't want to see
the post go unanswered.
The new interface, introduced in Hugin-2013.0.0, is different, and as is
often the case with new things they seem 'wrong', simply because of lack
of familiarity.
I guess everyone has their preferences as to how things should look and
feel, but there haven't been a lot of grumbles (there have been some)
about the new interface since it's introduction. I don't see any of the
points you raise as being issues that cause me any concern.
I guess the hope of getting these nags rectified may increase if other
users express similar concerns/frustration.
I would suggest that building up more familiarity with the new interface
may be the best approach.

Cheers,
--
Regards,
Terry Duell

[John Muccigrosso]

On Sunday, September 20, 2015 at 1:48:48 AM UTC-4, Tduell wrote:

I guess everyone has their preferences as to how things should look and  
feel, but there haven't been a lot of grumbles (there have been some)  
about the new interface since it's introduction. I don't see any of the  
points you raise as being issues that cause me any concern.
I guess the hope of getting these nags rectified may increase if other  
users express similar concerns/frustration.

If I might, I'd suggest that, at least IMO, a lot of the responses to the grumbling were fairly final sounding and even a bit harsh. A look back at the responses when the new UI was being shown shows complaints about a number of things.

[Terry Duell]

Hello John,

On Mon, 21 Sep 2015 12:59:45 +1000, John Muccigrosso <jmuc...@gmail.com>
wrote:

Fair enough. I didn't look back on the record of proceedings, just relied
on my memory.

[Gnome Nomad]

Yes, I had a few complaints about the redesign. None of my complaints were given any response beyond the above, 'Your issue doesn't cause me any concern' and boiled down to 'you'll get used to it.'

While I've gotten 'used to it', that doesn't mean they're not issues. I also find the way of configuring/setting custom exposure adjustments hard to use. I sincerely hope the present UI is only something 'in progress' to the real UI.

[Terry Duell]

Hello Gnome,

[snip]

>
> Yes, I had a few complaints about the redesign. None of my complaints
> were given any response beyond the above, 'Your issue doesn't cause me
> any
> concern' and boiled down to 'you'll get used to it.'

That's a good point, but I think it is unlikely that the developer(s)
would have ended up implementing a design that caused themselves concerns.
I am not one of the developers and wasn't involved in the new interface
development so I can only guess about that. I have simply commented on how
it affects me.
If there is a reasonable number of users who are dissatisfied with the new
interface, hopefully they will express their views and prompt some more
discussion.

[Marius Loots]

Hallo Everyone,

Monday, September 21, 2015, 4:59:45 AM, you wrote:
> about the new interface since it's introduction. I don't see any of the  
> points you raise as being issues that cause me any concern.
> I guess the hope of getting these nags rectified may increase if other  
> users express similar concerns/frustration.

Agree that specific points of concern would be very helpful.
Especially coming from a long time user that is new to the new
interface.

I have got used to using the new approach, and are probably better of
for it. There are some tasks, however, that was easier in the old
interface.

John> responses to the grumbling were fairly final sounding and even a
John> bit harsh. A look back at the responses when the new UI was

This was my feeling as well. At the moment I use a hybrid model, where
I fall back to the older version to get some things done.

Groetnis
Marius
mailto:mlo...@medic.up.ac.za
--
add some chaos to your life and put the world in order
http://www.mapungubwe.co.za/
http://www.chaos.co.za/
skype: marius_loots

Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/
beskikbaar.

[Yuval Levy]

Hi Terry, and everybody else:

On 15-09-21 01:55 AM, Terry Duell wrote:
> [snip]
>
>>
>> Yes, I had a few complaints about the redesign. None of my complaints
>> were given any response beyond the above, 'Your issue doesn't cause me
>> any
>> concern' and boiled down to 'you'll get used to it.'
>
> That's a good point, but I think it is unlikely that the developer(s)
> would have ended up implementing a design that caused themselves concerns.

You mean it is unlikely that the developer would have ended up
implementing a design that caused him concerns, or more generally that
designs that caused concerns would not have been implemented by the
developer?

> I am not one of the developers and wasn't involved in the new interface
> development so I can only guess about that. I have simply commented on
> how it affects me.

I was one of the developers until about five years ago life happened and
I moved on. Now I am developing the tech team for a Toronto startup, I
am developing my practice of law, and in January I will be joining the
team that is developing an innovative stock exchange. Development runs
in my blood.

There are different software development models, and what I observe with
Hugin these days compared with Hugin five years ago is that it has
evolved from being the work of a team to become the work of an
individual developer.

I am not judging the developer, just stating a fact.

It is a fact that without this one developer, Hugin would have staled.
The effort is humongous and the reward minimal. The developer deserves
the credit for keeping Hugin alive and he has every right to make every
decision he has made. From what I observe he has attracted a sufficient
number of followers to ensure continued distribution and he has
sacrificed countless hours. Compare with RAWstudio, another piece of
software that has, over the same time, gone from a team effort to a lone
maintainer model.

> If there is a reasonable number of users who are dissatisfied with the
> new interface, hopefully they will express their views and prompt some
> more discussion.

There will always be some users expressing "dissatisfaction." So what?
Discussion is just noise. Who is to decide what is a "reasonable
number?" Who is to evaluate whether it is really a concern and not just
a case of "who moved my cheese?" There are millions of users out there
that are still stuck with Windows XP and still whining about who moved
their cheese, while other users have used the choices available to them
and either moved on to Windows Vista/7/8/8.1/10 or MacOSX or Linux or
Android.

Tying it back to the development model, Hugin was and reamins Open
Source. In an Open Source context, users always have more choices. Or
stating it bluntly: "fork me!" That choice is more real than ever,
because of the tech tools that have matured (GitHub!) and because a team
will inevitably be able to put in more time collectively, than a single
developer. Unless that time is wasted discussing, in which case the
single developer model is more efficient.

I am not judging the users in this thread. They have expressed their
views rationally and respectfully and have shared with the developers
and other users at large how they deal with the changes.

How persuasive their views are depends not only on whether they are a
concern to them and to other users, even to the majority of users. It
depends on the context and how much they can influence. The best advice
I can give to them is to pull the source code (instructions are on the
wiki), go look at the user interface design (which if my memory does not
betray me is in /src/hugin1/hugin/xrc), read it, with the help of the
wxWidgets documentation that can be found online) and start moving
things around. Their view will receive much more support if indeed they
make a small change (such as moving a button from one xrc file to
another or changing a widgets from a text to a checkbox) rather than
suggesting it. Theoretically they may even try to hire a developer to
do that, with a bounty or something.

Until it stays just a discussion, it won't be helpful, because the
individual developer has a limited amount of time and no incentive to
spend it reading discussions.

my 2 cents.

Yuv

[Bruno Postle]

On 21 September 2015 03:59:45 BST, John Muccigrosso wrote:
>
>If I might, I'd suggest that, at least IMO, a lot of the responses to
>the
>grumbling were fairly final sounding and even a bit harsh. A look back
>at
>the responses when the new UI was being shown shows complaints about a
>number of things.

The new UI was a response to Hugin's main usability problem - which was that hundreds of thousands of people would install it and completely fail to get anything to work - it required that users understood all sorts of obscure concepts before even starting.

This problem is mostly solved - someone who just wants to stitch together a few photos taken on holiday has a good chance that this will just work.

Now the situation is that you need to understand lots of obscure concepts to do advanced things, but this is a much better problem to have.

One thing we see regularly is people trying to do advanced stuff entirely using the wizard in the preview window, these people need to be gently directed to advanced features. The bits we find annoying, such as when optimisation controls are hidden until enabled, are like this so Hugin doesn't scare users who are on this learning gradient.

Obviously there are lots of things that could be improved: there is a control on the Photos tab that is incredibly useful for changing settings on the Optimiser tab, and I also find that switching backwards and forwards between the two tabs slows me down. Combining the two would mean that the Optimiser tab is always visible, do we want this?


--
Bruno
--
Bruno

[John Muccigrosso]

As a non-programmer (know enough to be dangerous, but only in very limited circumstances :-) ), I very much appreciate the comments of Yuv and Bruno.

My own sense is similar to Bruno's: simple stuff often works great, but when there's a problem, it can be really hard to figure out why.

I've learned a lot from the tutorials (even updated a couple) and think that a real manual would go a long way. Not just a manual that outlined the basics, but one that gets under the hood a bit. Often when I read a good answer to a problem posed in this group, it explains what's happening in a way that I could never have figured out by myself and that explanation of what's going on inside Hugin is revealing and useful beyond the immediate case. (Bruno's responses are often good examples of this.) Some of the tutorials are great in this way.

So that's a plug for a more in-depth user manual.

In terms of the GUI, I find myself with at least two major problems:

1. I have to bounce around the various tabs and screens a lot. This is especially true for the advanced mode with its own window. An interface that reflected the usual workflow better would be great. (The separate window for Advanced mode got a lot of criticism, IIRC.)

2. A lot of the interfaces seem not well laid out (and I think I've commented on a few of these things in various threads). For example, there are radio buttons where you might expect checkboxes, or a control under one heading is actual globally valid.

So without going into details, those are the big-picture items that occur to me.

I appreciate greatly the work that's been done to bring Hugin where it is now.

[Bruno Postle]

On 21 September 2015 03:59:45 BST, John Muccigrosso wrote:
>

>If I might, I'd suggest that, at least IMO, a lot of the responses to
>the
>grumbling were fairly final sounding and even a bit harsh. A look back
>at
>the responses when the new UI was being shown shows complaints about a
>number of things.

[J. Schneider]

Hello all, hello John,
you expressed a couple of problems that I experience, too. It took me
quite some time to get used to it.

1. "Hiding the Optimizer and Exposure windows is confusing." I guess you
meant the tabs. These are displayed as soon as you choose a setting like
"custom parameters" for geometric or photometric optimisation. So they
are not displayed as long as there are not settings to change. Quite
useful I find - but see issue 4.

2. Why is there no delete button? I wonder too! That's what GUIs are
for. They should present the possible commands and not make you search
for them. (Anyway, you can just hit the delete key!)

3. This new underlining & bolding UI is not only less ergonomic to read
and to use, I must admit I have never understood how to use it properly.
I can "select all" or "unselect all" images to be optimized for a
specific parameter.
Thank you John! You mentioned Ctrl-clicking and I tried and only now
found out how to optimise a parameter for only one image (or a
selection, but not all). I really think there should be a more obvious
way to do this.
Or have I been living under a rock and this is something a computer user
usually knows?
This is why I have not uninstalled the last hugin version with the old
UI and although I know now how to use it I would still be grateful if it
could be reverted to checkboxes.

4. Yes, the sub menu structure of these menus doesn't make it clear
where to find that. When you have the Exposure tab displayed (see
above!) it's easier or more obvious: When you hit the "Reset" button,
you get a similar dialogue to that "reset custom ..." one and here it's
in the first option. I think, too, this should be easier to find.
Although this is probably a very special use case.


Best regards
Joachim Schneider

> ...

[Terry Duell]

Hello Yuval,

On Mon, 21 Sep 2015 22:14:25 +1000, Yuval Levy <goo...@levy.ch> wrote:

> Hi Terry, and everybody else:
>
> On 15-09-21 01:55 AM, Terry Duell wrote:

[snip]

>>

>> That's a good point, but I think it is unlikely that the developer(s)
>> would have ended up implementing a design that caused themselves
>> concerns.
>
> You mean it is unlikely that the developer would have ended up
> implementing a design that caused him concerns, or more generally that
> designs that caused concerns would not have been implemented by the
> developer?

I meant your first case...that it was unlikely that the developer would
implement a design that caused him concerns.

[snip]

>> If there is a reasonable number of users who are dissatisfied with the
>> new interface, hopefully they will express their views and prompt some
>> more discussion.
>
> There will always be some users expressing "dissatisfaction." So what?
> Discussion is just noise.

I don't see any problem with discussion about issues that concern people.
It may just result in some getting involved and contributing patches.