Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/image/tiff: sony .arw files decode as a 0x0 image.Gray #33708
What version of Go are you using (
It turns out that .ARW files are TIFF files, in the sense that they use a TIFF container. This is what libtiff says about your file:
Decoding as a zero-pixel grayscale image is probably a mistake. The file contains two images, for some reason both are JPEG. I thought this was a RAW format? These are probably previews (350dpi and 72dpi) or something, the 0xc634 tag (DNGPrivateData) is perhaps a pointer to the actual raw data.
AIUI, the images have no width and height, since they are supposed to contain a JPEG header, for which they give offset and size. Unfortunately, they use the JPEG tags in a deprecated way.
I suppose we could try decoding the inner JPEG with the image/jpeg decoder and returning the first image. Would that make sense?
I think there are a lot of ways this could go, but thinking about it the best and simplest option here would be to have it simply error out instead of decoding it into an empty image.
The only reason I encountered this problem is because I have a Go service which takes images from an input and tries to make a thumbnail out of them. It first sends the image into image.Decode and if it fails it figures it might be a RAW file and tries converting it with dcraw -e filename (for .ARW files image.Decode doesn't respond with and error, so my program didn't get a chance to try with dcraw, and that's how this problem started).
It would be cool if Go supported extracting thumbnails for those TIFF based raw formats, but trying to decode my file in other TIFF decoders resulted in the following error:
TIFF directory is missing required "ImageLength" field.
I'm not an expert in image formats, but this error together with the fact that as you said JPEG tags are used in a deprecated way, would make me think it would not be worth it to support those edge cases only to be able to decode some raw formats but still having to send the rest of them to a raw decoder.
I would argue that, ideally, either the image should decode into the actual raw-encoded pixels, or attempting to open it should fail with some sort of explicit error.
Unpacking the inner JPEG seems dangerous: it would appear to work, but would (arguably unexpectedly) produce a lossy image when the user is expecting a lossless one.