exiv2
exiv2 copied to clipboard
DNG: exiv2 vs exiftool previewimage inconsistency
I have a DNG generated from Halide IOS camera appl.
I use exiftool
to update the previewimage following advice from Phil Harvey replacing the previewimage with a foo.jpg
. I can subsequently pull the image using exiftool
and its identical to the preview image.
However, exiftool
and exiv2
(0.28.1) have inconsistencies:
-
exiv2 -pt
reports aExif.Image.StripByteCounts
(viaexiv2 -t ...
) that is incorrect - I am expect this to be the exact size matching foo.jpg, the inserted preview image -
exiv2 -pp
reports the preview image is aimage/tiff
(expect jpeg) -
exiv2 -ep1
extracts a corrupt image
Running with exiv2 0.28.1
built from source on linux/x64 and exiftool 12.69
To Reproduce
- Original Input DNG on OneDrive, IMG_6430.DNF
- Confirm
exiv2
andexiftool
disagree on preview image size
$ exiv2 -pp IMG_6430.DNG
Preview 1: image/tiff, 512x384 pixels, 72598 bytes
$ exiv2 -pt IMG_6430.DNG
...
Exif.Image.StripByteCounts Long 1 72470
...
$ exiftool -v2 IMG_6430.DNG
..
| 12) PreviewImageLength = 72470
| - Tag 0x0117 (4 bytes, int32u[1])
...
- Get a preview image for testing
# via ImageMagik:
$ convert -quality 40 -size 3000x2000 plasma:fractal foo.jpg
$ ls -l foo.jpg
rw-r--r-- 1 ray ray 188855 Nov 10 20:04 random.jpg
- Update preivew image in DNG
$ exiftool \
"-previewImage<=foo.jpg" \
-tagsfromfile foo.jpg "\
-ifd0:imagewidth<imagewidth" \
"-ifd0:imageheight<imageheight" \
"-ifd0:rowsperstrip<imageheight" \
IMG_6430.DNG
- Verify preview image
$ exiv2 -pp IMG_6430.DNG
Preview 1: image/tiff, 3000x2000 pixels, 188984 bytes
## NOTICE image size reported as 188984 vs actual 188855 (+118bytes diff)
## BUT looking at -pt it CORRECTLY reports size
$ exiv2 -pt IMG_6430.DNG
...
Exif.Image.StripByteCounts Long 1 188855
...
## NOTICE discrepancy with the
$ exiftool -v2 IMG_6430.DNG
..
| 12) PreviewImageLength = 188855
| - Tag 0x0117 (4 bytes, int32u[1])
...
Expected behavior
exiv2 -pp to reflect preview image size consistently.
There appears to be another issue; when examinging the DNG file for previews, the LoaderTiff
is used but it makes an assumption that all previews will have a "image/tiff" mime-type (as set in LoaderExifDataJpeg::getProperties()
).
In the use case above, we are able to use exiftool
to udpate the preview image using a jpeg - I do not know if this is to spec but at least Phil Harvey's commet notes such a DNG with JPEG preview image can be read correctly by MacOS.
I wouldn't get hung up on the size per se, as they don't really disagree:
Exif.Image.StripByteCounts Long 1 72470
| 12) PreviewImageLength = 72470
However, the preview not being detected as a JPEG might need looking into.
## NOTICE image size reported as 188984 vs actual 188855 (+118bytes diff)
## BUT looking at -pt it CORRECTLY reports size
So the -pt
reports the actual size of the JPEG byte stream, and that is in agreement and what matters. The +118 bytes is the size of the TIFF preview image one would extract - the extra bytes are for the TIFF container that wraps that JPEG payload.
Not sure if there's an actual bug here, just difference in behaviour: exiv2 decides to treat DNG/TIFF subimages as still valid TIFF images when possible, and doesn't necessary "unwrap" them unless they're specifically designated as preview/thumbnail images (using e.g. the JPEGInterchangeFormatLength tag instead of StripByteCounts, which in contrast seems to make LoaderTiff
the priority loader).