Hi James,
I am a bit late on this thread and coding starts tomorrow. Nevertheless,
here are my thoughts, hoping they can help you.
At the core, Hugin makes sense of a series of photographs. In your
project you get the unique opportunity to review how this is done. There
are two parts to it: t
On Mon, 2009-05-18 at 21:35 +0100, Bruno Postle wrote:
> On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote:
> >
> >Random thought: how about a 'layout' mode in the fast preview window
> >that rearranges the photos to show the structure of the project.
>
> Following through with this idea,
0
> From: br...@postle.net
> To: hugin-ptx@googlegroups.com
> Subject: [hugin-ptx] Re: Layout panorama model (GSoC)
>
>
> On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote:
> >
> >Random thought: how about a 'layout' mode in the fast preview window
>
On Fri 24-Apr-2009 at 13:30 +0100, Bruno Postle wrote:
>
>Random thought: how about a 'layout' mode in the fast preview window
>that rearranges the photos to show the structure of the project.
Following through with this idea, here is a mockup showing the
'Preview' mode compared with the equi
On Sat 16-May-2009 at 19:13 -0700, Tom Sharpless wrote:
>
>I would like this facility to be able to generate regular layouts --
>both rectangular (for long lenses) and staggered (for fisheyes) --
>from simple specs such as "5 x 8" or "6 around: 3 up 15, 3 down 15".
I'm not entirely sure why this
Hi
I guess there will always be 2 schools of thought about pano layouts.
Being an engineer, I believe you shouldn't shoot a pano until you have
planned the layout, and probably written it down. Bruno belongs to
the "just shoot away and let Hugin sort it out" school, which is
presumably larger.
On Tue 12-May-2009 at 23:38 +0100, James Legg wrote:
>
>> Yes, or if you position two photos, the software can assume that the
>> intermediate photos have intermediate positions.
>
>I would think it would be difficult to choose when to make this
>assumption. You don't want photos to move by thems
Hi James,
Just a quick note below:
James Legg wrote:
> It probably wouldn't take too long to combine this with the OpenGL
> preview, and might even be less work than putting it in its own tab.
Sounds good!
> I don't know about animating the transition between preview and layout
> mode though.
On Tue, 2009-05-12 at 22:16 +0100, Bruno Postle wrote:
> I think that in the case where the photographer has to fiddle with
> settings on their camera between shots, then they probably need to
> fiddle with their stitching software too - i.e you can't auto-detect
> this stuff.
Fair enough.
>
On Tue 12-May-2009 at 20:38 +0100, James Legg wrote:
>
>This should cater for most camera's auto exposure bracketing, but won't
>help if you bracket differently for each direction, depending on its
>dynamic range.
I think that in the case where the photographer has to fiddle with
settings on the
On Tue, 2009-05-12 at 19:20 +0100, Bruno Postle wrote:
> Hi James, some thoughts on using EXIF data to structure panorama
> projects based on touching this stuff with panostart/match-n-shift:
>
> Identifying panoramas from timestamps. This isn't relevant to your
> project, but it is actually q
On Thu 23-Apr-2009 at 15:48 +0100, James Legg wrote:
>
>Some feature ideas:
> * If the layout was entered manually:
> * The layout will provide an initial guess for the image
>positions.
> * You can do automatic control point generation on just
>
Bravo, James!
This is something obviously useful that for some reason none of the
stitchers I use provides. I think the most important target is
focusing control point finding on areas of actual overlap -- that
should not only eliminate the stupid impossible CPs we sometimes get,
but more import
On Sun, 2009-04-26 at 15:43 -0500, Gerry Patterson wrote:
>
>
> On Thu, Apr 23, 2009 at 9:02 PM, Gerry Patterson
> wrote:
>
>
> On Thu, Apr 23, 2009 at 6:05 PM, James Legg
> wrote:
>
>
> Ideas are what I need at the mo
On Sun 26-Apr-2009 at 15:28 -0500, Gerry Patterson wrote:
>
> As of rev 3805, Hugin will now compute the errors for the control
> points on project load. I placed this in a separate function that
> can be called in other places as well (say when ever an image is
> moved or a CP is modified).
On Thu, Apr 23, 2009 at 9:02 PM, Gerry Patterson wrote:
>
>
> On Thu, Apr 23, 2009 at 6:05 PM, James Legg wrote:
>
>>
>> Ideas are what I need at the moment. Perhaps when this thread has more
>> responses you could summarise the ideas on the wiki? That would be
>> helpful. :-)
>>
>>
> I can try.
On Thu, Apr 23, 2009 at 6:21 PM, Bruno Postle wrote:
>
> Note that hugin shows an 'error distance' for each control point,
> this is actually supplied by the optimiser at the end of each
> optimiser run (which is why all these fields are zeroed when you
> reload a project).
>
> This is overdue fo
> * There can be brackets without stacks. For example, if shooting
> by hand, you could take a row of pictures at one exposure,
> change the exposure time and go back in the opposite direction.
> It is unlikely that you can make stacks of the two different
> e
Oskar Sander wrote:
>
> If lines are used to visualize connections of control points, width and
> colour could be used to show what connects that have many or few
> control points (width), and where there are control points that have a
> bad fit (e.g. red or green)
>
> With the correct posit
2009/4/24 Bruno Postle
>
>
> Photos would be iconised with inter-connections shown as lines,
> similar to the undirected graph tests but with the correct relative
> positions as in Roger Wolff's ptomap test. Stacks can be shown as a
> 'cascade' of images on top of each other. Unconnected photos
On Fri 24-Apr-2009 at 00:05 +0100, James Legg wrote:
>
>It is likely that each type of model has a most ideal stitch / fuse
>order, so perhaps it doesn't make sense to present the choices on the
>stitcher tab.
>
>I was planning a layout tab, for describing the set of pictures taken;
Random though
On Thu, Apr 23, 2009 at 6:05 PM, James Legg wrote:
>
> On Thu, 2009-04-23 at 11:33 -0500, Gerry Patterson wrote:
>
> > Would it make sense to be allow control of the blending and fusing
> > order for the output. When I was looking at this earlier, there were
> > two areas that needed to know abo
On Thu 23-Apr-2009 at 15:48 +0100, James Legg wrote:
>The layout model can be either entered manually, or automatically
>guessed after an initial alignment. The model describes the number of
>images per stack, the number of stacks in each row, the total field of
>view covered by each row, the dir
On Thu, 2009-04-23 at 11:33 -0500, Gerry Patterson wrote:
> Would it make sense to be allow control of the blending and fusing
> order for the output. When I was looking at this earlier, there were
> two areas that needed to know about the model you are discussing:
> optimization, and then later
2009/4/23 James Legg
The layout model can be either entered manually, or automatically
> guessed after an initial alignment. The model describes the number of
> images per stack, the number of stacks in each row, the total field of
> view covered by each row, the direction you rotated between the
Hello James,
On Thu, Apr 23, 2009 at 9:48 AM, James Legg wrote:
>
> Hello,
>
>
> * In a panorama composed from multiple brackets, you can filter
>the images used in the previews, so that only one bracket shows.
This is a good idea!
>
> * The model will be used to suggest d
26 matches
Mail list logo
