IM7 seems to delegate RAW file processing to ufraw-batch. If that program fails, IM refuses to process any .raw file, even if it is an incorrectly named TIFF or JPEG. IM6 identified such files correctly as TIFF/JPEG.
The behaviour is the same regardless whether ufraw-batch fails to process the file or is not installed at all.
To reproduce:
- Rename a valid .jpg to .raw
- Run identify
IM6 (6.7.7):
$ identify test.raw
test.raw JPEG 800x533 800x533+0+0 8-bit DirectClass 249KB 0.000u 0:00.000
IM7 (7.0.3):
$ identify test.raw
identify: delegate failed `'ufraw-batch' --silent --create-id=also --out-type=png --out-depth=16 '--output=%u.png' '%i'' @ error/delegate.c/InvokeDelegate/1845.
identify: unable to open image '/tmp/magick-8414rwL-Yd8wupbN.ppm': file not found @ error/blob.c/OpenBlob/2695.
IM7 gets confused by .raw file names
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: IM7 gets confused by .raw file names
Most filetypes (.JPG, .GIF, .PNG etc) have a unique signature, so IM can identify them and process correctly. .RAW is not well defined. Some raw camera filetype (eg .NEF) actually have the same signature as .TIFF. So IM identifies raw files by extension, rather than signature.
If a file has the wrong extension, so it has the extension of a raw format, but the file isn't, then the delegate will fail, and IM will report the failure.
This behaviour seems reasonable to me. Would you prefer something different?
If a file has the wrong extension, so it has the extension of a raw format, but the file isn't, then the delegate will fail, and IM will report the failure.
This behaviour seems reasonable to me. Would you prefer something different?
snibgo's IM pages: im.snibgo.com
Re: IM7 gets confused by .raw file names
Well, IM6 managed to identify the file correctly. I don't know IM internals but if it also tried the raw (DNG) module first, then it was able to fall back and try other modules in case that module was not able to handle the file.
Specifically, if a delegate program doesn't even exist - shouldn't the format be considered "not available" instead of stopping the format detection?
Specifically, if a delegate program doesn't even exist - shouldn't the format be considered "not available" instead of stopping the format detection?