An idea to expand HDR capabilities in Hugin
john doe
Lukáš Jirkovský
I dare to say this doesn't fit into "product vision" at all. You could
ask to make Hugin second Adobe Photoshop as well.
Bruno Postle
Going through this process has been very helpful for some other free software graphics projects lately
--
Bruno
Yuval Levy
> I think that now Hugin is 'feature complete', it is finally time to decide
> what the 'product vision' and 'target audience' really are.
yes, there are some conflicting/incompatible visions in the room; and also an
increasing number of available resources.
I can very well imagine Hugin going the way of many mature products that spin
off sub-products into different directions; and if managed well the process
could keep the conflicting visions under the same roof and harness resources
better.
We already have two implicit groups - the bleeding edge (and those using and
developing it) and the stable releases.
If there are enough people with a vision of a simple automated no question ask
stitcher, we should support them to spin off a version of Hugin that is
centered on (and shows only the) assistant. Call it 'EasyHugin'. And at the
other end of the spectrum that part of Hugin that I personally like most, a
playground for the development of new features (not to be confused with:
adding bloat through integration of features already available in other tools)
- Call it 'BleedingEdgeHugin'. And somewhere in the middle is there a target
audience of pro photographers who want to control the stitching process in
full detail without dealing with UI-unpolish. This could be 'ProHugin'. If
we can keep a common base, the three projects would cross pollinate.
Everybody likes an easy thing; everybody likes a clean UI; and everybody
likes useful new features - it is just a matter of prioritizing progress and
subordinating it to the specific user category needs.
To me, Hugin is not 'feature complete' and is unlikely to ever be. The next
things I would like to see happen (besides the integration of the features
that are waiting in the integration queue) are:
- Python scripting interface
- completition of the fast preview features (e.g. display of HDR images; zoom)
- better scalability (there is some VIPS code still out there?)
- more integration with enblend (and better prediction / control of seam
lines)
- performance improvements to leverage modern computing platforms
- easy useful functions such as cube output mentioned by Tom earlier this week
> Going through this process has been very helpful for some other free
> software graphics projects lately
can you cite examples? is there any documentation of the process and the
results?
Yuv
kfj
> I can very well imagine Hugin going the way of many mature products that spin
> off sub-products into different directions; and if managed well the process
> could keep the conflicting visions under the same roof and harness resources
> better.
> stitcher, we should support them to spin off a version of Hugin that is
> centered on (and shows only the) assistant. Call it 'EasyHugin'. And at the
> other end of the spectrum that part of Hugin that I personally like most, a
My feeling is that splitting up in such a way would complicate
matters. If I understand the GUI right, it is possible to show/hide
tabs, and if an assistant-centered mode were offered, it could just
not show the more involved tabs - no need to make a separate program.
I see another more logical split between mosaic mode and panorama
mode, and the needs and peculiarites of each process might make it
easier to maintain them as two separate programs.
> To me, Hugin is not 'feature complete' and is unlikely to ever be.
> things I would like to see happen (besides the integration of the features
> that are waiting in the integration queue) are:
> - Python scripting interface
> - completition of the fast preview features (e.g. display of HDR images; zoom)
> - better scalability (there is some VIPS code still out there?)
> - more integration with enblend (and better prediction / control of seam
> lines)
> - performance improvements to leverage modern computing platforms
> - easy useful functions such as cube output mentioned by Tom earlier this week
attention:
The documentation of the code is still rather sketchy. The last time I
struggled vainly through the skeletal doxygen documentation in search
for an answer to why something happens and not something else has left
me reluctant to ever try again.
The second point is more nebulous, and I cannot really provide a good
example for the problem, but I have a gut feeling it's there, I'd be
curious if anyone else had a similar notion: I think that hugin maybe
uses too many different libraries. Of course there are always
libraries to do one thing particularly well, but sometimes it's
overall wiser to use something that's already inside the project
rather than introducing more dependencies and yet another API. This
is, of course, the domain of those of you who have a good overview of
what is done how by what library, and, yet again, I find there is not
enough documentation on the overall design of the project, probably
because it's grown historically, but hopefully not because there isn't
anyone anymore who could come up with a good explanation. I've been
moaning about this before; please point me to anything along these
lines if it exists.
Kay
Tom Sharpless
On Dec 25, 10:55 am, "Bruno Postle" <brunopos...@googlemail.com>
wrote:
'shooting template', and including an easy way to specify straight
line constraints (see current discussions). I'd also mention proper
camera and lens calibrations, backed by a usable personal database.
Regards, Tom
john doe
--
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
Rogier Wolff
On Sat, Dec 25, 2010 at 11:13:45AM -0500, Yuval Levy wrote:
> On December 25, 2010 10:55:28 am Bruno Postle wrote:
> > I think that now Hugin is 'feature complete', it is finally time to decide
> > what the 'product vision' and 'target audience' really are.
>
> yes, there are some conflicting/incompatible visions in the room; and also an
> increasing number of available resources.
>
> I can very well imagine Hugin going the way of many mature products that spin
> off sub-products into different directions; and if managed well the process
> could keep the conflicting visions under the same roof and harness resources
> better.
IMHO, Just to be sure... We should try to avoid forking off such
developments. These should be subprojects as a compilation option or
just different binaries built from the same source tree.
A fork would create the situation that more manpower would be required
to fix bugs in both forks....
As we're talking "visions", let me try to contribute mine. As I don't
have enough time on my hands to code (m)any of my suggestions myself,
I understand that I'm just providing suggestions and I'm not
able to write the code....
Anyway, First you should read:
http://queue.acm.org/detail.cfm?id=1921361
Why is this relevant?
The main thing is about the/a gui.
What "mentor" chip design software (costs about $100000 and up) and a
few others (I think cadsoft's eagle goes a long way, altera Quartus
II) IMHO do right is that EVERYTHING you do is actually commandline.
There is just a graphical shell that makes you think you're doing
things through a GUI.
So when I go into the assistant and add a few files and automatically
align and then stitc, the "command shell" window shows:
add_image file1.jpg
add_image file2.jpg
add_image file3.jpg
add_image file4.jpg
cpfind
optimize_layout
showpreview
set stitch.hwidth 3000
set stitch.output file1-file5.tiff
stitch
As buttons get clicked, each adds a command, which ends up doing the
expected thing. When I want to redo this session, either to reproduce
a bug, or to see if something has changed, I can just tell it to
execute the comand-log-file.
Things can end up being split across different easier-to-maintain
executable binaries. There will be clear interfaces between programs
of the suite.
As an example, the preview window(s) would just be a separate program.
It serves to show the "current state". As it also interacts with the
user it also provides commands towards the command interpreter. So for
example the "straighten" button causes the "straighten" command to be
issued to the central command unit. The operation should then be
executed, resulting in a new "current-state-of-the-pano" and the
preview window should be signalled to redraw. Nothing much changes in
what the user experiences, but how things work behind the scenes
becomes much more modularised. (I've done a "big" project that
according to the software engineering rules should've cost MUCH more
than the available time (measured by the LOC that needed to be (and
was) delivered). By splitting the whole project into many small sub
projects, most of which were "trivial" by software engineering
standards, the amount of work became manageable, resulting in an
on-time-functioning delivery of software.)
Another example is the control points finders. Some are automatic and
just send a bunch of: "add_cp img1 img2 img1x img1y img2x img2y" to
the main command processor. The interactive one works very
similar. It's just that it requires user interaction to for every
"add_cp" line issued towards the command processor.
As we have several steps that might take a long time, we should work
towards standardizing the "progress output" from all our subprograms.
Thus the "stitch now" button for example knows it will have to execute
two steps: nona and enblend. It will call nona, and show a progress
bar based on the progress provided by the separate binary
"nona". Similarly for the "enblend" step. (nona needs to be called
numimages times, each providing progress. Next enblend needs to blend
numimages-1 seams. Again each step providing progress.)
For a smooth transition to this setup, the existing programs can be
left the same. A small outputfilter will translate nona's and
enblend's output to the common progress report output. Then we'll have
a choice of integrating these into the programs themselves, or if we
want to keep them the same, just leave it like this.
Things to find out are how to save the many-more parameters inside
PTO or other files to allow communication between all the modules.
The current "integration" of cpfind boasted the marketing talk about
how good it was to integrate such a program because now it had access
to all internal variables of hugin. I think this is a step backwards
for hugin. (On the other hand, having cpfind is a huge(larger) step
forwards, so I'm still happy about it. But I think cpfind should
become a separate subproject, which communicates via a clearly defined
interface with the GUI...).
Anyway, excuse my ramblings....
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Bruno Postle
>
> The current "integration" of cpfind boasted the marketing talk about
> how good it was to integrate such a program because now it had access
> to all internal variables of hugin. I think this is a step backwards
> for hugin.
This isn't how it is at all, rather it has gone the other way. cpfind
is run as an external process, and this control point generation step
is now managed by the same Makefile system as has been used for
stitching previously.
The interface for communication with cpfind is a temporary .pto file,
both for input and output, there is no shared memory going on.
The design of Hugin shifts nearly all of the work to the collection of
small command-line tools, the Hugin GUI itself is basically an editor
for .pto files and not much else.
--
Bruno
kfj
On 26 Dez., 23:51, Rogier Wolff <rew-googlegro...@BitWizard.nl> wrote:
> As buttons get clicked, each adds a command, which ends up doing the
> expected thing. When I want to redo this session, either to reproduce
> a bug, or to see if something has changed, I can just tell it to
> execute the comand-log-file.
>
> Things can end up being split across different easier-to-maintain
> executable binaries. There will be clear interfaces between programs
> of the suite.
It'd all be glued together with Python code and the small defined
tasks are C/C++ modules that share memory via the Python mother
process so the data can be passed around without writing to disk. I
think the show should be run by an interpreted language, guess which
one I favour. It'd be liberating. A Python process can write and
execute Python code, making the implementation of a re-executable
command log much simpler.
Kay
Rogier Wolff
> On 26 December 2010 22:51, Rogier Wolff <rew-goog...@bitwizard.nl> wrote:
> >
> > The current "integration" of cpfind boasted the marketing talk about
> > how good it was to integrate such a program because now it had access
> > to all internal variables of hugin. I think this is a step backwards
> > for hugin.
>
> This isn't how it is at all, rather it has gone the other way. cpfind
> is run as an external process, and this control point generation step
> is now managed by the same Makefile system as has been used for
> stitching previously.
>
> The interface for communication with cpfind is a temporary .pto file,
> both for input and output, there is no shared memory going on.
Good, good!
I value the "correctness" of hugin over my personal blunder of
thinking it was not correct (*).
I missed this EMail a few days back. Email overload. Sorry.
Roger.
(*) Or whatever you'd call that in a software-engineering sort of way.