On Fri, May 22, 2009 at 15:56, Bruno Postle <[email protected]> wrote:
>
> On Fri 22-May-2009 at 12:50 -0700, Michael Witten wrote:
> >
> ># * I wanted 11.tif to provide the white area with which {05,09,10}.tif
> ># could be blended nicely. However, enblend gives up when the pixels
> ># are white, saying that 11.tif is grayscale while the other input
> ># images are color.
>
> Unfortunately there is no way to stop ImageMagick optimising
> bit-depth, so it really doesn't play nicely with enblend.
ImageMagick seriously has no option? I'm surprised the 'optimised' grayscale
image isn't 'promoted'. It seems like this should be a non-issue.
>
> ># * As an experiment, I converted the white area into a yellowy area
> ># in the hope that it would bypass the first problem. Fortunately, it
> ># works, but emblend itself misbehaves: The golden area is shifted up
> ># in the image and blended with the wrong parts.
>
> The problem is that hugin produces 'cropped' TIFF files, i.e. hugin
> doesn't render empty areas, it adds a pixel offset to the files
> instead.
>
> i.e. to any tool that understands about these offsets the image is
> 1801 pixels high, but to ImageMagick and the Gimp they are 1519.
>
> If you are going to be editing layers in the Gimp, you need to
> uncheck 'cropped TIFF' in hugin before rendering, or use a tool like
> PTuncrop to turn them into 'normal' TIFF files.
>
> (or fix the Gimp, it handles offsets fine with multilayer TIFF)
Ah!
However, I *thought* I had taken care of this problem, as I did indeed
uncheck 'cropped TIFF' as suggested (otherwise tif2svg gives you an SVG
with a bunch of images piled on top of each other; however, you can see
that the remapped (warped) images ({05,09,10}.tif) are not as severely
cropped as you would expect---there are large areas of transparency.
It turns out that the remapped images are still turned into cropped TIFFs
when one has specified the Crop rectangle in the Stitcher tab of Hugin 0.7.0
(using nona 0.7.0).
I would classify this as a bug. Given that the pixel data can actually be
cropped away by setting the Crop rectangle Hugin, it seems to me that the
Crop rectangle should become the canvas of the output TIFF.
Explicitly, Hugin was set up as follows:
Panorama Canvas Size (width,height) = (3284,1826)
Crop (left,top,right,bottom) = (51,282,3272,1801)
so that even though 'cropped TIFF' is unchecked, Hugin produced the remapped
images as cropped TIFFs:
canvas (width,height) = (3284, 1826)
image (width,height) = (3221, 1519)
To me, these looked uncropped, so I proceeded to run tif2svg on those remapped
images to create an Inkscape SVG. Indeed, the resulting SVG used the image size
(not the canvas size) for the size of the embedded images and the size of the
SVG canvas:
(width,height) = (3221,1519)
It was at this point when I introduced a new layer into the SVG to handle
the solid-color region for the Sun. Naturally, I made that image with size:
(width,height) = (3221,1519)
Then, I ran enblend-svg and terminated it after enblend-mask, so that I could
grab the intermediate files to figure out why the Sun-region was offset upwards.
The reason for the problem is---as you stated---that the Sun-region image is not
a cropped TIFF while the other images are cropped TIFFs. Indeed, I used PTuncrop
to find out that:
For 11.tif (the Sun-region image):
canvas (width,height) = image (width,height) = (3221,1519)
For {05,09,10}.tif:
canvas (width,height) = (3272,1801)
image (width,height) = (3221,1519)
You'll notice that the canvas size
is simply the (right,bottom) tuple
of the Crop fields in the Stitcher
tab. This doesn't make sense...
I would classify this as a bug. I would have expected the dimensions given in
the
SVG to be used exactly for the images. However, I'm sure the explanation is that
Inkscape doesn't handle cropped TIFFs correctly either, so that led me to work
with the 'wrong' dimensions. Yet, the clipping paths made in Inkscape still
aligned
properly, so doesn't that mean that ImageMagick doesn't understand cropped
TIFFs?
After all, the cropped TIFFs made by ImageMagick have the wrong canvas anyway.
Does nothing besides Hugin and its ilk deal with cropped TIFFs properly?
> ># The `--fine-mask' handles the thinly overlapping seams that I have created;
> ># without it, I've experienced some horrendous artifacts such as completely
> ># blackened regions.
>
> enblend will do a much better job with wider seams, I think it is a
> mistake to make them so narrow. However you can still blend the
> images together nicely by increasing the number of blending levels
> with the -l option:
>
> enblend -l 29 -o junk.tif *_uncropped.tif
>
> The result:
>
> http://www.flickr.com/photos/36383...@n00/3554309269/
Besides noticing that you called the output 'junk' ;-P (that is, :-D), I noticed
that your output has a lot more of the pond than it *should* have. I was utterly
confused until I realized that the image pixel data is completely available--it
is only made transparent by the alpha data (how does unassociated alpha fit in
to this?)
The only thing that makes sense to me is that you played around with the alpha
'mask' by hand to get more of the pond. Is this so?
Also, I took a look at the page on how enblend works (at least how it worked):
http://enblend.sourceforge.net/details.htm
I'm not sure why forcing more levels in the pyramids is able to deal better
with my narrowly overlapping regions. Why is this? Does it force a larger region
of pixel data to be used automatically?
Sincerely,
Michael Witten
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
