Yes, this and what Gnome summarized are close to what I was thinking. So, if
you have two adjacent stacks of three exposures, presumably they would all
overlap by at least 10% and all six images would share a particular control
point - thus creating a single line down through both stacks. Pres
Like a "control dowel" would be a line (defined as "straight") that
connects single points between multiple separate frames? An "any angle"
generalization of a horizontal line spanning multiple frames?
My understanding of horizontal lines is probably flawed ...
On 02/27/2013 05:48 PM, Robert C
Hello Bob,
It seems to me that you really only need two "dowels", probably best not
too close to one another. The first dowel would align all of the first
control points, and the second align all the second control points thus
ensuring all images are rotated around the first dowel correctly. Pro
I'm not following this idea. Can you elaborate a bit? How would a control
dowel work and what would it do?
On Wednesday, February 27, 2013 9:48:52 PM UTC-6, Bob Campbell wrote:
>
>
> On Feb 21, 2013, at 7:09 PM, Jim Watters wrote:
>
> > Hugin and Panotools community,
> > What new ideas do you h
On Feb 21, 2013, at 7:09 PM, Jim Watters wrote:
> Hugin and Panotools community,
> What new ideas do you have that a student could implement?
I'm the type to make panos while holding my p-n-s Canon S95. I've tried doing
some bracketed shots and create HDR from that, but I've had limited succe
On Sat 23-Feb-2013 at 22:35 -0800, Christoph Spiel wrote:
Am Freitag, 22. Februar 2013 13:32:38 UTC+1 schrieb Bruno Postle:
Merging nona with enblend/multiblend. Currently we remap each photo
with nona, then enblend/enfuse splits these remapped images into
multilevel pyramids, joins them into a
Am Freitag, 22. Februar 2013 13:32:38 UTC+1 schrieb Bruno Postle:
> Merging nona with enblend/multiblend. Currently we remap each photo
> with nona, then enblend/enfuse splits these remapped images into
> multilevel pyramids, joins them into a single pyramid which is then
> reassembled into a final
On Sat 23-Feb-2013 at 09:25 -0800, David Horman wrote:
> and I suspect doing it like this would avoid the nasty 'whorl'
> artefacts we get at the zenith/nadir (this assumption needs
> testing).
Do you have an example of the whorls?
You see the 'whorls' when you stitch to equirectangular, t
> Merging nona with enblend/multiblend... Another way of doing this would be
> to split the input photos into pyramids, then remap each directly into the
> final pyramid..
I have a feeling - just a feeling at the moment, I haven't done any tests -
that the operations can't really be swapped.
I'm definitely not going to have time for mentoring the summer of code
this year.
This is a short list of features that are in Panotools::Script that I
think ought to be moved into Hugin, maybe one of them could be the
basis of a project:
Adding GPano XMP tags to all equirectangular output. Googl
First idea.
Find bad optimized images.
Mostly for gigapixel projects that have many images and are evenly spaced.
After applying a grid function or template to evenly space out the images,
searching for control points, and then optimizing. Some of the images might get
horribly positioned. This
Hugin and Panotools community,
The Google Summer of Code 2013 is on. Where Google funds a student to work on
Free Software like Hugin for the summer.
http://google-opensource.blogspot.ca/2013/02/flip-bits-not-burgers-google-summer-of.html
http://www.google-melange.com/gsoc/homepage/google/gsoc2
12 matches
Mail list logo