Project

General

Profile

Bug #980

Support HDR DNG images from HDRMerge

Added by Schnitzel Foo almost 5 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
image format
Target version:
Start date:
14 Aug 2014
Due date:
% Done:

100%

Estimated time:

Description

HDRMerge is an awesome FOSS program from Javier Celaya for generating a high dynamic range raw image in the DNG format from a bracketed raw set.
https://github.com/jcelaya/hdrmerge

Please add support for correctly displaying the thumbnails from these raw images. They follow standards and should therefore be supported.
You can download a sample image from:
http://rawtherapee.com/shared/test_images/hdrmerge_045.dng

exiv2 0.24 seems to correctly extract the preview images (it identifies two of them in that DNG). If that DNG contains a thumbnail image, exiv2 does not extract it.

Reference bug report that lead me here: https://bugs.kde.org/show_bug.cgi?id=338081

Kind regards

History

#1

Updated by Robin Mills almost 5 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.25

Thanks very much for bringing this to our attention. I've taken a look at the image you provided and I'd like you to help me to understand the substance of this issue.

592 rmills@rmillsmbp:~/Downloads $ exiv2 -pa hdrmerge_045.dng | grep -i -e prev -e thum -e res -e width -e height -e length
Exif.Image.NewSubfileType                    Long        1  Thumbnail/Preview image
Exif.Image.ImageWidth                        Long        1  256
Exif.Image.ImageLength                       Long        1  172
Exif.Image.Compression                       Short       1  Uncompressed
Exif.Image.XResolution                       Rational    1  100
Exif.Image.YResolution                       Rational    1  100
Exif.SubImage1.ImageWidth                    Long        1  3936
Exif.SubImage1.ImageLength                   Long        1  2624
Exif.SubImage1.Compression                   Short       1  Adobe Deflate
Exif.SubImage1.TileWidth                     Long        1  496
Exif.SubImage1.TileLength                    Long        1  528
Exif.SubImage2.NewSubfileType                Long        1  Thumbnail/Preview image
Exif.SubImage2.ImageWidth                    Long        1  1948
Exif.SubImage2.ImageLength                   Long        1  1308
Exif.SubImage2.Compression                   Short       1  JPEG
Exif.Photo.FocalLength                       Rational    1  8.0 mm
Exif.Photo.MakerNote                         Undefined 31792  (Binary value suppressed)
Exif.Pentax.PreviewResolution                Short       2  640x480
Exif.Pentax.FocalLength                      Long        1  0.0 mm
Exif.Pentax.PreviewImageBorders              Byte        4  26 26 0 0
Exif.Pentax.WB_RGGBLevelsFluorescentD        Short       4  17376 8192 8192 8847
Exif.Pentax.WB_RGGBLevelsFluorescentN        Short       4  14528 8192 8192 10076
Exif.Pentax.WB_RGGBLevelsFluorescentW        Short       4  13088 8192 8192 12206
Exif.Photo.FocalLengthIn35mmFilm             Short       1  12.0 mm
593 rmills@rmillsmbp:~/Downloads $ exiv2 -ep hdrmerge_045.dng 
594 rmills@rmillsmbp:~/Downloads $ ls -alt *.tif
-rw-r--r--+ 1 rmills  staff  132276 14 Aug 22:37 hdrmerge_045-preview1.tif
-rw-r--r--+ 1 rmills  staff  234282 14 Aug 22:37 hdrmerge_045-preview2.tif
595 rmills@rmillsmbp:~/Downloads $ tiffinfo *.tif
hdrmerge_045-preview1.tif:
TIFF Directory at offset 0x8 (8)
  Image Width: 256 Image Length: 172
  Resolution: 100, 100
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 172
  Planar Configuration: single image plane
hdrmerge_045-preview2.tif:
TIFF Directory at offset 0x8 (8)
  Image Width: 1948 Image Length: 1308
  Bits/Sample: 8
  Compression Scheme: JPEG
  Photometric Interpretation: YCbCr
  YCbCr Subsampling: 2, 2
  YCbCr Positioning: cosited
  Samples/Pixel: 3
  Rows/Strip: 1308
  Planar Configuration: single image plane
  Reference Black/White:
     0:     0   255
     1:   128   255
     2:   128   255
  YCbCrCoefficients: 0.299000,0.587000,0.114000
596 rmills@rmillsmbp:~/Downloads $ exiv2 -v -V
exiv2 0.24 001800 (64 bit build)
Copyright (C) 2004-2013 Andreas Huggel.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 USA
exiv2=0.24.0
platform=apple
compiler=Clang
bits=64
dll=1
debug=0
version=4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)
date=Aug  9 2014
time=09:31:53
svn=3288
executable=/usr/local/bin/exiv2
library=/usr/local/lib/libexiv2.13.dylib
... deleted lots of library=foo stuff ...
library=/usr/lib/libz.1.dylib
597 rmills@rmillsmbp:~/Downloads $ 

It appears to me that there are two preview images 256x172 and 1948x1308 and those have been successfully extracted. It (correctly) does not extract the primary image 3936x2624

I'm puzzled by your statement:

exiv2 0.24 seems to correctly extract the preview images (it identifies two of them in that DNG). If that DNG contains a thumbnail image, exiv2 does not extract it.

Is there a missing word here? Are you saying, if that DNG doesn't contain a thumbnail image, exiv2 does not extract it? exiv2 never extracts the primary image.

Or are you saying that if there is only preview in the DNG, it will not be extracted? I used the Adobe DNGConvertor to create a DNG from a .NEF created with my Nikon D5300. That DNG also contains 2 preview images (low and medium size), so I don't have a DNG with only one preview.

Or are you expecting exiv2 to extract thumbnails of the original images used to by HDRMerge?

So, I'm a little lost. Can you provide a test image and exiv2 command lines to reproduce the issue?

#2

Updated by Schnitzel Foo almost 5 years ago

How funny, I couldn't find a "reply" button... turns out it's called "update" here. :]

The wording is full and correct. See, this started with a request I filed for digiKam to support showing the thumbnails of these DNG files: https://bugs.kde.org/show_bug.cgi?id=338081
"Note Exiv2 has also a method to extract preview from DNG. Please report this problem too in Exiv2 bugzilla."

As far as I can tell, exiv2 does read that DNG correctly. However, I was lead to believe that digiKam's lack of showing a thumbnail image for these DNG files is due to incomplete support, and that perhaps the DNG contains a thumbnail image which exiv2 fails to extract, even though it succeeds at extracting the embedded preview images. The exiv2 man page treats "preview" and "thumbnail" differently (I am not aware whether the DNG specification makes this distinction).
exiv2 -et img1.jpg img2.jpg
Extracts the Exif thumbnails from the two files into img1-thumb.jpg and img2-thumb.jpg.
exiv2 -ep1,2 image.jpg
Extracts previews 1 and 2 from the image to the files image-preview1.jpg and image-preview2.jpg.

So if digiKam via exiv2 can use the small preview as the thumbnail, then there is nothing to do here. I would just like you, the experts, to confirm :]

#3

Updated by Robin Mills almost 5 years ago

  • Status changed from Assigned to Resolved

Ah, right. I've understood. Thanks for clarifying this. It's the difference between "Thumbnail" and "Preview" that's causing concern.

It seems to me that exiv2 is behaving correctly. When I try to extract the thumbnail, here's the transcript:

637 rmills@rmillsmbp:~/Downloads $ exiv2 -et hdrmerge_045.dng 
hdrmerge_045.dng: Image does not contain an Exif thumbnail
638 rmills@rmillsmbp:~/Downloads $ 

As for the difference between a Thumbnail and a Preview, I've run the following command on a JPG (taken with a Canon PowerShot)

640 rmills@rmillsmbp:~/Downloads $ exiv2 -pa ~/R.jpg | grep -i -e prev -e thum -e width -e height -e length
Exif.Photo.FocalLength                       Rational    1  6.0 mm
Exif.CanonCs.ZoomSourceWidth                 Short       1  3264
Exif.CanonCs.ZoomTargetWidth                 Short       1  3264
Exif.Canon.FocalLength                       Short       4  6.0 mm
Exif.Canon.ThumbnailImageValidArea           Short       4  0 0 0 0
Exif.Iop.RelatedImageWidth                   Short       1  3264
Exif.Iop.RelatedImageLength                  Short       1  2448
Exif.Thumbnail.Compression                   Short       1  JPEG (old-style)
Exif.Thumbnail.XResolution                   Rational    1  180
Exif.Thumbnail.YResolution                   Rational    1  180
Exif.Thumbnail.ResolutionUnit                Short       1  inch
Exif.Thumbnail.JPEGInterchangeFormat         Long        1  3788
Exif.Thumbnail.JPEGInterchangeFormatLength   Long        1  2468
641 rmills@rmillsmbp:~/Downloads $ 

As you can see, there are a collection of tags "Exif.Thumbnail" which are processed by the -et options.

By comparison -ep operates on the tag:

Exif.SubImageN.NewSubfileType                Long        1  Thumbnail/Preview image

So the library has registered it's unhappiness and did not extract the non-existant Exif.Thumbnail image from the DNG.

It seems to me that DigiKam (or any application), will have to know the difference between thumbnail and preview. Your suggestion seems reasonable to me. If the application does not find a Thumbnail, it should request Preview and use the smallest preview.

I am going to mark this issue as "Resolved" as I believe the library is behaving correctly. You are of course welcome to disagree and we can continue the discussion. If necessary, we can involve other Exiv2 team members. The issue will not be "Closed" until review prior to the 0.25 release which is currently expected November 2014.

#4

Updated by Schnitzel Foo almost 5 years ago

Thank you for the explanation, it sounds like everything's working correctly here. I will update the digiKam report with this information.

#5

Updated by Robin Mills about 4 years ago

  • % Done changed from 0 to 100
#6

Updated by Andreas Huggel about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF