On Apr 29, 10:30 pm, Lukáš Jirkovský wrote:
> Certainly, I use it for several years without problems.
>
> BTW: I would collaborate more on this topic but I'm a bit tied up at the
> moment.
i tried running hugin_hdrmerge from the command line. it is
apparently using the avg method by default and
On 30 April 2010 03:47, slaterson wrote:
> On Apr 29, 6:39 pm, slaterson wrote:
>> On Apr 29, 3:24 pm, Bruno Postle wrote:
>> > This is with OpenEXR-1.4.0a
>
> i just checked my version of openexr. it's 1.6.1. do you know if the
> newer version is compatible?
>
Certainly, I use it for several
On Apr 29, 6:39 pm, slaterson wrote:
> On Apr 29, 3:24 pm, Bruno Postle wrote:
> > This is with OpenEXR-1.4.0a
i just checked my version of openexr. it's 1.6.1. do you know if the
newer version is compatible?
--
You received this message because you are subscribed to the Google Groups
"hugi
On Apr 29, 3:24 pm, Bruno Postle wrote:
> Yes it seems that Hugin uses EXR for the intermediate stitching
> files.
ok. so only the final panorama is output as tiff? the merged stacks
are exr, also?
> I tried one of my bracketed panoramas and it is ok (HDR merged and
> blended with Hugin trun
On Mon 26-Apr-2010 at 21:04 -0700, slaterson wrote:
On Apr 26, 4:05 pm, Bruno Postle wrote:
> Can you try a TIFF workflow instead of EXR? (TIFF supports
> floating-point HDR data too).
i tried changing the output option for hdr to tiff. i still got
exr files! i'm not sure if that is expec
On Apr 26, 4:05 pm, Bruno Postle wrote:
> What version of Hugin do you have? hugin_hdr_merge had some changes
> in 2010.0.0.
i have 2010.1.0.5118 installed right now. downloaded from svn and
compiled/installed within the last week.
> Can you try a TIFF workflow instead of EXR? (TIFF supports
>
On Sun 25-Apr-2010 at 19:44 -0700, slaterson wrote:
On Apr 25, 3:25 pm, Bruno Postle wrote:
Just to clarify: the individual remapped images are ok, but the
merged stack is where you see the streaks?
yes, the individual remapped images are ok. three exr images are
output for remapping (along
On Apr 25, 3:25 pm, Bruno Postle wrote:
> Just to clarify: the individual remapped images are ok, but the
> merged stack is where you see the streaks?
yes, the individual remapped images are ok. three exr images are
output for remapping (along with a pgm 'gray' image) for each stack.
all of thes
On Sun 25-Apr-2010 at 08:34 -0700, slaterson wrote:
the merged stacks were generated however they all exhibit
streaking/ smearing. essentially, at the edge of the image where
the transparency starts, the pixel color is smeared or streaked
horizontally for the remainder of the image space. i h
On Apr 24, 4:39 pm, slaterson wrote:
> i will give this another try and be sure to save the remapped images,
> might be a day or two before i can test that, though.
i went ahead and did a test this morning. interesting results. i
selected 'remapped merged stacks' and 'remapped images' from the
On Apr 24, 3:07 pm, Bruno Postle wrote:
> HDR combined with GPU acceleration hasn't had as much testing.
>
> The messed-up image looks to me like it happened at the nona stage
> rather than enblend.
i will give this another try and be sure to save the remapped images,
might be a day or two befo
On Sat 24-Apr-2010 at 09:42 -0700, slaterson wrote:
On Apr 23, 5:18 pm, Bruno Postle wrote:
The HDR version is a big mess, are you stitching using the GPU
acceleration?
i use the gpu with nona but not enblend. i have tried using it with
enblend but it crashes a lot. :( the remapped images a
> > In general we recommend stitching a spherical panorama to the
> > 'standard' equirectangular projection first - Stitching directly to
> > a very wide stereographic image means that some photos are remapped
> > to extreme shapes and scales, this takes longer and the geometry can
> > cause proble
On Apr 23, 5:18 pm, Bruno Postle wrote:
> The HDR version is a big mess, are you stitching using the GPU
> acceleration?
i use the gpu with nona but not enblend. i have tried using it with
enblend but it crashes a lot. :( the remapped images all look good,
so this is likely a problem with enble
On Fri 23-Apr-2010 at 07:33 -0700, slaterson wrote:
i have uploaded two images illustrate the problem i am encountering.
the first image is a blended and fused pano, the second is the exr
output shown in luminancehdr (i have also opened the image in
photomatix pro in windows - the same problem ex
On Apr 23, 8:30 am, Zac wrote:
> With regard to your workflow - How are you generating your 16bit TIFs?
> and how come your working that way, ie not importing HDR images into
> hugin just out of interest?
i am generating 16 bit tifs from ufraw. they are twice as big as 8
bit and therefore much s
I cant comment too much on your worflow because I havent experimented
much. however, I have had some great results by working as follows:
- generating HDR images first for the bracketed sets. ( I've been
using Photomatix to batch combine all images if there is no movement
or manually with Dynami
i have uploaded two images illustrate the problem i am encountering.
the first image is a blended and fused pano, the second is the exr
output shown in luminancehdr (i have also opened the image in
photomatix pro in windows - the same problem exists).
while there is still noise, there is not as mu
Would be nice to see some pictures e.g. screenshots.
I assume such pixel errors are rather common in hdr output, the
biggest point is they have to overlap perfectly, any movements of
clouds, people etc. result in artifacts.
--
You received this message because you are subscribed to the Google Gro
19 matches
Mail list logo
