exiv2 icon indicating copy to clipboard operation
exiv2 copied to clipboard

DNG: exiv2 vs exiftool previewimage inconsistency

Open whatdoineed2do opened this issue 1 year ago • 3 comments

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 a Exif.Image.StripByteCounts (via exiv2 -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 a image/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

$ 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.

whatdoineed2do avatar Nov 10 '23 21:11 whatdoineed2do

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.

whatdoineed2do avatar Nov 11 '23 17:11 whatdoineed2do

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.

kmilos avatar Nov 13 '23 10:11 kmilos

## 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).

kmilos avatar Nov 13 '23 11:11 kmilos