adapting the GUI for different workflows
J. Schneider
I believe I remember when 0.7 was being worked on it was supposed to be
a features release and 0.8 was supposed to be a UI release. Therefore
some ideas were postponed that were UI improvements.
During the discussion someone came up with an idea (that was derived
from some other application) on how to adapt hugin's GUI to different
workflows - unfortunately I can't find the email any more, so I don't
know to whom the credit goes.
Every once a while someone asks for changes to the UI to fit special
needs such as linear panoramas. Or optimizing the UI for certain kind of
input (fisheye, stacks, ...) or output (stacks, hdr, blended, ...).
Now I have come up with a sketch of how I understood the aforementioned
idea. It is only a rough pencil sketch, but I think it conveys the
basic idea:
- The workflow is represented as a flow diagram
- Any action, any command, any option is represented by a box
- Actions are assembled via drag and drop
- Bifurcations allow to produce different types of output from
one set of input images. They would probably have to be exe-
cuted successively, particularly if they contain user inter-
action.
- even incomplete workflows can be saved and used as modules in other
workflows. (button "insert saved here")
The sketch can be found here:
http://www.joachimschneider.info/hugin_workflow_assembly.gif
or
http://www.joachimschneider.info/hugin_workflow_assembly.pdf
(hope my handwriting is no obstacle.)
Where to incorporate this into hugin? I believe it could be a dialogue
that is opened from a button on top of the assistant tab. There would be
a dropdown menu to choose among existing workflows and a new/modify
button that opens the dialogue.
After selecting/changing the desired workflow, the assistant tab would
reflect this workflow, offering interaction at the stages where
specified in the workflow. The current content of the assistant tab
would be the default workflow.
This makes me think of an alternative usage:
If there is no user interaction specified, the workflow would run
completely automatic. So it could be made a droplet on which you just
drop the source images. Or a project file, depending on it's first action.
My suggestions seems to "intersect" with James Legg's from his post on
24.04.09, the second one in his thread "Layout panorama model(GSoC)"
(which contains a lot of great enhancements!)
(By the way: James uses the term "processing chain" - is workflow
actually a correct English word?)
Does all this make sense to you? Do you think this could cater for the
needs of special uses of hugin - even without touching the other tabs?
Do you think this is technically possible? I am not a programmer. I can
only guess that the whole thing might be driven my makefiles.
regards
Joachim
James Legg
> Hi all,
>
> I believe I remember when 0.7 was being worked on it was supposed to be
> a features release and 0.8 was supposed to be a UI release. Therefore
> some ideas were postponed that were UI improvements.
> During the discussion someone came up with an idea (that was derived
> from some other application) on how to adapt hugin's GUI to different
> workflows - unfortunately I can't find the email any more, so I don't
> know to whom the credit goes.
>
> Every once a while someone asks for changes to the UI to fit special
> needs such as linear panoramas. Or optimizing the UI for certain kind of
> input (fisheye, stacks, ...) or output (stacks, hdr, blended, ...).
The idea of my Summer of Code project is to allow the user to specify
their needs, and then get the optimal UI and settings; so this is fairly
interesting to me at the moment.
For my project, I was thinking of adding a layout tab which asked
several questions:
1. Linear panorama or spherical panorama?
2. Is there bracketing? If so what type and how is it done?
3. How many different angles / positions in each row?
The first part overlaps with your ideas, the workflow will change
depending on the answers given. I was hoping to get the majority of the
different use cases covered.
> This makes me think of an alternative usage:
> If there is no user interaction specified, the workflow would run
> completely automatic. So it could be made a droplet on which you just
> drop the source images. Or a project file, depending on it's first action.
The user can already do many customisable parts of their workflow
outside of Hugin, as most of Hugin's actions are external commands. A
batch file will do much of what you ask. Your idea is more
user-friendly, and could potentially be more powerful, however.
> My suggestions seems to "intersect" with James Legg's from his post on
> 24.04.09, the second one in his thread "Layout panorama model(GSoC)"
> (which contains a lot of great enhancements!)
Yes, I was suggesting something like this, although my suggestion was
limited to editing the Makefiles generated for stitching.
> (By the way: James uses the term "processing chain" - is workflow
> actually a correct English word?)
It is. My idea was more makefile oriented. Workflow is a better word to
describe a flowchart based system.
> Does all this make sense to you? Do you think this could cater for the
> needs of special uses of hugin - even without touching the other tabs?
> Do you think this is technically possible? I am not a programmer. I can
> only guess that the whole thing might be driven my makefiles.
>
>
> regards
> Joachim
I was hoping that the user would simply answer a few questions to get
the images correctly aligned in the way suitable for their project. The
stitching process should also be generally limited to specific options
given the selections in the layout tab.
I could keep this in mind during my project. Parts of the workflow could
be represented internally in a way the would be easily displayed as you
suggest, but I might not actually create an editor like your diagram
this summer. It would be fairly easy to do afterwards. If there is
enough interest this I will attempt it though.
James
Bruno Postle
>On Fri, 2009-05-01 at 15:26 +0200, J. Schneider wrote:
>
>> This makes me think of an alternative usage:
>> If there is no user interaction specified, the workflow would run
>> completely automatic. So it could be made a droplet on which you just
>> drop the source images. Or a project file, depending on it's first action.
>
>The user can already do many customisable parts of their workflow
>outside of Hugin, as most of Hugin's actions are external commands.
I'm wary of you getting involved in a redesign of hugin as there is
a lot of stuff already in your project:
1. Linking images into stacks without using control points, and a GUI
for controlling this.
2. Linking images/stacks into rows and/or columns, and a GUI
(Microsoft Office has a very nice chooser for sizing tables which is
worth looking at for ideas)
3. A GUI for viewing the project as a layout.
4. With an understanding of which images overlap and which don't,
there is considerable potential for speeding stitching itself and
splitting it into parallel jobs. The enblend -a option does some of
this, but nona is actually capable of rendering all the odd numbered
images in a row to one file and all the even-numbered images to
another, these could then be blended in a single enblend pass. i.e.
a 10x20 gigapixel panorama could be rendered with 20 calls to nona
and 19 blends with enblend.
But the general hugin workflow is interesting to consider. The
current hugin design has a history:
The tabbed layout was derived from ptgui, originally the tabs were
numbered and you worked from left to right, loading images, setting
lens parameters, control-points, optimising and stitching. This was
an odd idea to use tabs sequentially, but was very effective when
control points had to be set by hand.
With automatic control point generation all this changes. Currently
I don't use hugin as a workflow tool, I create a bunch of projects
unseen and use the hugin GUI as a viewer/editor. So now the two
important part of hugin are the Assistant and the Fast Preview,
everything else is less relevant and will become even less relevant
as control point generators and cleaners improve (and they will).
--
Bruno