Thanks for the pointers, I was able to build enblend-enfuse on the
Amazon EC2 cloud. I just wanted to confirm the image corruption bug -
without the image cache, enblend created the output panorama without
an glitches, streaks or any other artifacts.
As a potential heads up, my original attempt to
Hey thanks. I'm really tired right now so this may be a slightly
brain-dead response, anyway:
>> The configure summary shows that my EXTRACXXFLAGS/EXTRACFLAGS are ignored
>
> As it should be. None of the EXTRA* flags interferes with
> Autoconf/Automake. This has been done on purpose. See
I can't get enblend to build statically. Here's what I have so far.
PKG_CONFIG_PATH=:/tmp/enblend.enfuse/openexr-install/lib/pkgconfig$PKG_CONFIG_PATH
\
LDFLAGS="-L/tmp/enblend.enfuse/lcms-1.19-install/lib
-L/tmp/enblend.enfuse/libxmi-1.2-install/lib
-L/tmp/enblend.enfuse/freeglut-2.6.0-in
> What would be most usefull would be the ability to enter rotational
> info from a gigapan or similar head and then have control points
> picked strictly from the overlap. It would create a much better
> starting point and be much more efficient than searching for matches
> across hundreds of ima
> What is a typical Hugin session process and time duration for a 38 image set?
Admittedly I have yet to shoot on a properly calibrated panoramic
head, and I've only stitched 3 panoramas thus far.
As a matter of passing interest, I find that 10-20 CPs + unlinked
optimization of v,a,b,c,d,e (esp.
I've found that enfuse results in low-contrast, low-saturation images,
as though seen through a fine layer of mist or a whitening filter.
Despite tweaking all the settings (--exposure-*, --gray-projector) I
always need to post-process in gimp. However, I've seen some beautiful
images using (I think
> Add several vertical line control points and optimize ypr of all images
> except the yaw of one center image.
> The horizon should end up going through the center of the pano.
> The pano can then be cropped to show just the image.
That is what I did ... I guess because the picture was literally
> Btw, this is an awesome image!
Yeah, isn't it! I pulled it off the hugin flickriver stream.
Ok, I have an HDR EXR image that was successfully and completely
written to by Hugin but which is still broken... it's 10MB if anyone
wants it. I also posted a smaller PNG version at
http://imagebin.org/1
Mm sorry FOV ranges from 142 degrees horizontal to 144 degrees
vertical according to the sticther tab... whereas I calculated FOV
from the images tab as (yaw group0 - yaw group1) * (# groups) +
[2-(mod2 #groups)/2](yaw group1 - yaw group1). What is the difference
?
--
You received this message be
Is it possible to create a rectilinear panorama from images (shot from
one location) ranging (tip-to-tip) 67 degrees horizontally and 50
degrees vertically such that the output image plane does not appear to
"lean" forwards or backwards, but flat as in
http://www.flickr.com/photos/acmace/5239601953
I ask because enblend has been running for 18 hours so far
--
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 grou
I mean to ask, is this known? Is there a workaround? I see no new
versions of enblend...
--
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/
I should probably start a new thread for this, but whatever...
Hugin HDR panorama output (2010.4.0) is broken. Whether outputting the
final output as EXR or TIFF, the intermediate stacks are in the EXR
format. For example, ProjectName_stack_hdr_[[:digit:]]{4}.exr. These
intermediate stacks are brok
> Ah - hah. So for a multi-point horizon I should make a straight line
> which happens to be horizontal?
I found vertical lines work better than straight lines which happen to
be vertical. The images between the horizontal/vertical lines should
be oriented by overlapping normal control points, imo
Thanks for all the points, I've aligned specific stacks and created
stack masks, now despite a mundane landscape the fused version
nonetheless looks impressive.
My panorama is outputting to "exposure fused from stacks as TIFF" and
"HDR as EXR", in both cases the blend process has taken about two
h
I ran a rough test (I don't have the tripod) and determined that my
NPP was displaced by approximately 10cm - which caused about a 4px
pixel error for mid-range objects. It's really neat that object
distance can be estimated from pixel error.
I've noticed that enblend is 99% of the stiching proces
I don't know if this is related, but the luxrender project recently
added film response curves intended to emulate various cameras during
tonemapping
Here are some details (read down the topic)
http://www.luxrender.net/forum/viewtopic.php?f=12&t=5456
And a link to the CRF files:
http://www.luxrende
Ah well! I have "Ø" symbol printed on the side of my Canon EOS 350, I
was told this was the NPP point... as you pointed out, likely not.
http://www.dpreview.com/reviews/CanonEOS350D/Images/allroundview.jpg
Top right view, above the strap slit. Anyone know what this point marks?
--
You received th
> Important: Horizontal, vertical, and straight lines are evaluated on their
> output projection.
Hm, so that's why my mercator projection + straight line @ ~25° was
throwing off the alignment...
so this means that:
equirectangular: vertical lines only, plus horizon line
Does this also apply to c
thanks for the suggestions:
Just to be clear, the problem is not in my control points. I have 24
stacks with 50% overlap, per overlap I've manually placed 20-40
high-correlation well-distributed accurate control points. After
optimizing my average error is 0.4, rms error 0.6, max error 1.7.
The pr
By the way, whats the difference between vertical control point lines
and horizontal control point lines? And is it useful to have these
lines across different images (ie horizontal lines would take care of
pitch while CPs would take care of roll)
Also the documentation says straight control point
On Thu, Apr 7, 2011 at 8:13 PM, Christopher Allen wrote:
> On Apr 7, 2011 6:15 PM, "Yclept Nemo" wrote:
>>
>> RAW images are in linear color space so hugin would
>> not have to reverse-calculate the response curve applied by
>> ufraw/dcraw.
>
> Is th
> On Wed, Apr 6, 2011 at 6:25 PM, Markku Kolkka wrote:
>> On Wed, Apr 6, 2011 at 5:08 PM, Yclept Nemo wrote:
>> I just started a panoramic project involving 275 8GP full-size tiff
>> images split across 25 stacks. The images amount to around 14GB. Since
>> this is the
I just started a panoramic project involving 275 8GP full-size tiff
images split across 25 stacks. The images amount to around 14GB. Since
this is the first time I've used Hugin, I thought I'd document what I
found confusing (correct my workflow) or broken (correct hugin):
Major Major Major Proble
24 matches
Mail list logo
