Hi Tom, 2009/10/18 Tom Sharpless <tksharpl...@gmail.com>: > > Hi Lukas, > > On Oct 16, 9:19 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote: >> Hi >> >> 2009/10/16 Nicolas Pelletier <nicolas.pellet...@gmail.com>: >> >> > "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 >> >> I don't like this. It adds unnecessary step to panorama creation. >> Usually I select the projection in fast preview by trying all of them >> and comparing them how nice they are immediately. Now it would mean >> that I've to stitch complete panorama (sometimes I crop it quite a >> lot) and then reprojecting it somewhere. What would be better that >> when someone specifies more projections (this would need also some >> work on GUI) it would _internally_ use cube faces/equirect otherwise >> it would work the same. > > What I had in mind is indeed like the fast preview window, with many > projections and cropping, except it is a fast "postview" window, that > shows you an already stitched pano at high resolution, and lets you > format a view interactively, with instant switching between > projections. As I have learned from writing Panini, that kind of > display is quite feasible with OpenGL technology. It works especially > well if the pano is in cubic format.
I've probably misunderstood you. This really doesn't sound that bad, but I'm not sure if waiting for this "postview" window wouldn't be a bit confusing. I'd prefer to keep the possibility to decide (or better look at the possibilities) before stitching. Current Fast preview is really good for it because it uses "good enough" resolution. Here's my idea. There would be something like current fast preview which would use OpenGL for projection. You could select more different projections there (and see them immediately even before stitch). These would be done by remapping. If you later open this window, you could add more projections. These would be made from the intermediate (cube faces) from the previous step if they exist. > > I believe (but have not yet seen) that would be possible to render > final high resolution reprojections quite fast using the video > hardware via OpenGL. But even if the final rendering had to be done > in software, I would prefer this way of composing my images, as it is > pretty hard to get "just the right view" while looking at a low > resolution preview. > And if I want to keep several views it will probably save time, > because reprojecting a large image is a lot faster than stitching it > from small ones (no blending needed). That's surely a big advantage over current system. > > Regards, Tom >> >> Lukas >> >> >> >> > 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 > > > best regards, Lukas --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
