Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNG: exiv2 vs exiftool previewimage inconsistency #2825

Open
whatdoineed2do opened this issue Nov 10, 2023 · 3 comments
Open

DNG: exiv2 vs exiftool previewimage inconsistency #2825

whatdoineed2do opened this issue Nov 10, 2023 · 3 comments

Comments

@whatdoineed2do
Copy link

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
Copy link
Author

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.

@kmilos
Copy link
Collaborator

kmilos commented Nov 13, 2023

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
Copy link
Collaborator

kmilos commented Nov 13, 2023

## 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 kmilos removed the bug label Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants