On Mon, Nov 26, 2012 at 9:23 PM, Bruno Postle <[email protected]> wrote:
> On Mon 26-Nov-2012 at 09:12 +0000, Michael Witten wrote: >> >>> When "PNG" is set as the output format in the Stitcher tab, the output >>> inexplicably includes the "Image Offset" (the "oFFs") chunk: >>> >>> http://www.libpng.org/pub/png/book/chapter11.html#png.ch11.div.10 >>> >>> It appears to be completely nonsensical. At least GIMP asks whether >>> the values should be applied, but I fear that other software won't >>> even afford that courtesy. >> >> >> Interestingly, the PNG produced by running Hugin's TIFF output through >> ImageMagick's `convert' tool also suffers from this problem. Is the >> underlying conversion buggy? > > > The TIFF output has offsets, this is useful since much of the output from > nona is huge amounts of empty space and it makes little sense rendering it > all. This 'cropped TIFF' format with offsets can be turned off if you don't > want it. > > I haven't looked at the PNG output for ages, but I suspect that any offsets > you see have the same purpose. This problem is in no way related and is in no way useful in the same way; a perfectly good, correctly cropped image is being offset *nonsensically*---such that it is partially off the canvas. It is *Nonsensical*. Indeed, as I said, the TIFF output doesn't have this *nonsensical* offset. Please produce a PNG output and open it in GIMP and report your results to me; if you can't reproduce the problem, I'll send you an example. Thanks. -- 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
