"I think "a new Hugin" should provide only two direct stitching
targets: cube faces and equirectangular, and let you convert either of
those to other projections later."
I agree with this completely. The only other point I was trying to make is
that "converting to other projections" should not involve one project file
per projection IMHO.

Thanks,

nick

On Thu, Oct 15, 2009 at 12:43 PM, Tom Sharpless <tksharpl...@gmail.com>wrote:

>
> As seems to be usual, I agree with Bruno.
>
> The job of a stitcher is to prepare, match up, line up, and combine
> images on the panosphere.  Generating some flat projection of the
> panosphere is a necessary part of that job, but generating all
> possible projections is not.  Creating printable views involves so
> many possibilities, and so many aesthetic considerations, that it is a
> speciality all its own.  And repeating the entire process from source
> images to get each view is a big waste of time: things like lens
> correction, photometric correction and, especially, blending really
> need to be done only once.
>
> I think "a new Hugin" should provide only two direct stitching
> targets: cube faces and equirectangular, and let you convert either of
> those to other projections later.
>
> I include equirectangular only for the sake of tradition.  Cube faces
> have several advantages.  You can display them almost immediately with
> QuickTime or Flash technology.  Because they are rectilinear images,
> they are easy to judge, and to retouch.   And they  even let you
> stitch faster, because to map from a radially symmetric projection
> (e.g. almost any photo) to a radially symmetric projection, you only
> have to implement a nonlinear function in one dimension, along the
> radius.  That one dimensional mapping can be a lookup table; whereas
> to stitch to equirectangular requires a full 2-D nonlinear mapping (I
> use this trick in autopano-sift-c to generate stereographic images
> faster than is possible with libpano).
>
> For composing "just the right view" you need an interactive program,
> that can custom fit the projection to the subject to some extent
> (think of a view camera on steroids).  Both my Panini, and Max Lyons'
> PTAssembler preview window, come close (from different directions) to
> what I would ideally want.  Maybe the new Hugin suite should
> incorporate such a program; but it ought not to be configured as a set
> of sub-options on stitching.
>
> Regards, Tom
>
> On Oct 14, 4:44 pm, Bruno Postle <br...@postle.net> wrote:
> > On Wed 14-Oct-2009 at 16:09 -0400, Nicolas Pelletier wrote:
> >
> > >I'm not convinced it is a post processing step. I think it depends on
> where
> > >we draw the what should hugin do boundary.
> >
> > I guess that where I'm coming from is that Hugin and the Stitcher
> > tab are complex enough as it is.
> >
> > >I'm currently working with the exact workflow you mentioned, create a
> 360
> > >180 equi and then use this as the first element in the chain. But if the
> > >other steps were only post processing, then why should we have other
> > >projections and other import method?
> >
> > Mainly because we can, but also because partial panoramas are
> > legitimate targets, and because people have a use for stitching
> > partial equirectangular and cylindrical input.
> >
> > >Also, from this equirectangular, if we had many output, we could have a
> nice
> > >workflow that generate all 6 faces of the cubes for some VR interface
> > >without needing another tool, or swapping around with the same project
> or 6
> > >projects.
> >
> > We do actually have much of this (cubic, little-planet, thumbnails,
> > QTVR, PanoSalado etc...) as targets in the Makefile.equirect.mk
> > plugin - It would be trivially easy to enable this stuff in the
> > Stitcher tab or the Batch Processor, but it adds a bunch of
> > dependencies (ImageMagick, perl(Panotools::Script)).
> >
> > >> You can do this in Hugin, just import the equirectangular into a new
> > >> project and use the various output projections, or use Tom's Panini
> > >> tool which is specifically designed for extracting different views.
> >
> > >> What I'm trying to say is that the 'many' part is necessarily a
> > >> post-processing step, and doesn't really benefit from being
> > >> integrated into Hugin.
> >
> > --
> > Bruno
> >
>

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

Reply via email to