Ideas
Yuval Levy
http://www.ptgui.com/whatsnew.html
I like the detail viewer very much. That's a neat way of implementing the
zoom functionality that is missing from the fast preview and the way I
understand it it is a panoviewer that does not affect the project settings
(e.g. FOV, projection). A future GSoC project?
Yuv
john doe
Harry van der Wolf
kfj
On 3 Dez., 15:42, john doe <guerrerodelu...@gmail.com> wrote:
> I like the show seam mode...particularly it would help photographers to
> image edit the seams to get a better panorama..
stitching is done by enblend. Having direct influence on the placement
of the seams seems desirable. Currently, if I need to change the
position of a seam, all I can do is use masking on the images, and
it's a bit awkward at times, though the possibility to use 'use area'
masks (sorry, I'm not sure if this is the correct english term) makes
things easier. But it seems to me the only way apart from masks to
influence or even just visualize seam placement would be to put
additional capabilities in enblend and some way of interfacing with
them into hugin. Am I right? I suppose this is the price to be paid
when using separate tools for separate parts of the panorama process.
with regards
Kay
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
john doe
Yuval Levy
> On 3 Dez., 15:42, john doe <guerrerodelu...@gmail.com> wrote:
> > I like the show seam mode...particularly it would help photographers to
> > image edit the seams to get a better panorama..
>
> I wonder how hugin could know where the seams are
with better integration with Enblend...
Enblend can already now load and save masks.
> I suppose this is the price to be paid
> when using separate tools for separate parts of the panorama process.
not really. Thomas has shown that with good design you can have the best of
both world, e.g. cpfind and celeste. They started life as separate tools and
you can use them both as separate tools and within the GUI process.
Yuv
kfj
On 5 Dez., 21:40, Yuval Levy <goo...@levy.ch> wrote:
[kfj]> > I suppose this is the price to be paid
[kfj]> > when using separate tools for separate parts of the panorama
>
> not really. Thomas has shown that with good design you can have the best of
> both world, e.g. cpfind and celeste. They started life as separate tools and
> you can use them both as separate tools and within the GUI process.
>
closer integrated than just being separate processes executed by hugin
to do their bit and then deliver back a result? My current conception
of the hugin setup is that all the various tools can share data only
via files and command line arguments, but they don't share memory or
code (apart from, on some platforms, using the same shared libraries).
Please correct me if I'm wrong!
It seems to me that enblend could only produce seam data by opening
all the (nona-warped) files, calculating where it would put the seams,
and then maybe produce some output it could pass back to hugin so
hugin could show where the seams are, which data then would somehow
have to be translated into masks (on the unwarped original images) if
enblend were to be made to change anything about where it should put
the seems. As an interaction, this sounds very cumbersome to me (in
fact, it sounds pretty much like a one-way road).
with regards
Kay
Bruno Postle
>On 5 Dez., 21:40, Yuval Levy <goo...@levy.ch> wrote:
>
>> not really. Thomas has shown that with good design you can have the best of
>> both world, e.g. cpfind and celeste. They started life as separate tools and
>> you can use them both as separate tools and within the GUI process.
>
>This makes me curious. Are you saying that cpfind and celeste are
>closer integrated than just being separate processes executed by hugin
>to do their bit and then deliver back a result?
cpfind now links directly to libceleste and uses it to mask out
areas of photos containing clouds before control-point generation.
Previously with autopano-sift-c we had to wait for control-points to
be generated, and then remove points from clouds with celeste - The
result could theoretically be zero control-points.
>It seems to me that enblend could only produce seam data by opening
>all the (nona-warped) files, calculating where it would put the seams,
>and then maybe produce some output it could pass back to hugin so
>hugin could show where the seams are
An alternative would be to turn off enblend mask optimisation
altogether, in which case Hugin could predict the location of seams.
Now that we have masking in the Hugin GUI this is a viable workflow,
though I'm not sure I would want it to be the default.
Note that ptgui doesn't have mask optimisation at all, since it
decomposes the image pyramid before remapping and has no opportunity
to compare overlapping photos.
--
Bruno