feature req: flag to determine image contains embedded preview images about exiv2

[clanmills]

I don't understand your request. We don't know if there are previews in an image without reading the metadata.

Just because an image type may contain previews does not guarantee that the image does contain any previews.

[whatdoineed2do]

after readMetaData() has completed, is there a way currently to determine, via an method on the Exiv2::Imageobject, if the image file contains embedded preview images WITHOUT having to use the PreviewManager.

In other words, after readMetaData() is called, does the Image object have enough info to know if the file it represents has embedded preview images? If it does, can a simple bool hasEmbeddedPreviews() be added to provide this information.

[clanmills]

What is your use case here? Why are you asking for this? I don't want to change the Exiv2 API when you already a way in which to determine this information.

[whatdoineed2do]

i have C++ tool producing a catalog of a large input set of images to produce an index.html that links to all images; the index.html has tables entries for each image of the input set, with each element containing exif and thumbnail. I am using Exiv2 to get the exif and also pull the embedded images from RAW files to generate thumbnails. Basic image formats (jpegs /pngs) are just processed directly to thumbnail using ImageMagick.

The index would typically catalog and represent a year's worth of images: typically Nikon or Fuji RAW files and various phone cameras jpegs. For my 2016 catalog, we're talking about ~14.500 RAW files and 8.200 jpegs.

Creating a Exiv2::PreviewManager object and then calling Exiv2::PreviewManager::getPreviewProperties() for EACH image in my input set seems redundant (and at cost of the empty list object being returned) if the image is NEVER going to have an embedded preview image (ie its not a RAW file).

To avoid the redundant Exiv2::PreviewManager object overhead, I'd like to query the Exiv2::Image object (after I've called readMetaData()) to determine does this image object contain an embedded preview image.

If yes, do the necessary work with Exiv2::PreviewManager to get hold of the embedded preview jpeg if not, just use the image (jpeg or png etc) file itself - this will be used to generate the thumbnail.

Right now, to save the possibly redundant Exiv2::PreviewManager object I can determine if an image may contain an embedded preview image, I can (in 0.26.0) check Exiv2::ImageType against a finite subset of values or (in 0.25.0 and lower) dynamic cast the Exiv2::Image to a compile time set of preview-image-available subclasses (TiffImage, Cr2Image, RafImage etc). Both approaches aren't good as I need to explicitly have logic to compare against a white list and if further image formats (ie Sony RAW) are with embedded preview jpegs are supported by Exiv2 then the code needs another check on the logic.

If the Exiv2::Image or other exif object data, after call to readMetaData() already can indicate has embedded preview image or not, then this cleans up.

The code for this tool is at:
https://github.com/whatdoineed2do/imgcat

[clanmills]

Thank you for a very articulate explanation of your request. I didn't write the Preview code in Exiv2, so I don't know exactly how it works. I'll read the code this evening and think about your request. I don't know if readMetadata() knows for certain that the image has previews as they may hidden in a MakerNote which the preview manager decodes.

Exiv2 is very fast. On my 2013 MacBookPro, it can read more than 1000 images/second. And while the preview manager adds overhead, the code is fast. I have 1441 images in Pictures/2017 (about 30 folders of 50 images each):

649 rmills@rmillsmbp:~/Pictures/2017 $      (for i in ~/Pictures/2017/* ; do ls -1 -pa $i/*.jpg 2>/dev/null ; done) | wc
   1441    1441   73148
650 rmills@rmillsmbp:~/Pictures/2017 $ time (for i in ~/Pictures/2017/* ; do ls -1 -pa $i/*.jpg 2>/dev/null ; done) | xargs exiv2 -pa --grep original/i | head -3
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4633.jpg  Exif.Photo.DateTimeOriginal                  Ascii      20  2017:07:09 14:35:13
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4633.jpg  Exif.Photo.SubSecTimeOriginal                Ascii       3  80
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4634.jpg  Exif.Photo.DateTimeOriginal                  Ascii      20  2017:07:09 14:35:22

real	0m0.346s
user	0m0.143s
sys	0m0.128s
651 rmills@rmillsmbp:~/Pictures/2017 $ time (for i in ~/Pictures/2017/* ; do ls -1 -pa $i/*.jpg 2>/dev/null ; done) | xargs exiv2 -pp | head -3
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4633.jpg  Preview 1: image/jpeg, 160x120 pixels, 9882 bytes
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4634.jpg  Preview 1: image/jpeg, 160x120 pixels, 8747 bytes
/Users/rmills/Pictures/2017/AlisonBirthday/DSC_4635.jpg  Preview 1: image/jpeg, 160x120 pixels, 9928 bytes

real	0m0.956s
user	0m0.708s
sys	0m0.163s
652 rmills@rmillsmbp:~/Pictures/2017 $ 

[clanmills]

I've looked at the code in the preview manager. readMetadata() doesn't know anything about previews. He reads the tags and saves the data. He doesn't know what any of the metadata means!

The job of the preview manager is to scan the metadata for embedded thumbnails and save them.

Your proposed API image:: hasEmbeddedPreviews() can be implemented when the preview is easy to detect in readMetadata() for obvious thumbnail tags. However, manufacturers have various ways to "hide" their previews in the metadata. So, we would have to search all those places to be sure that hasEmbeddedPreviews() never returns a false negative. So we would impose the overhead of the preview search in readMetadata() even if the user wasn't interested in previews. The existing design that allows readMetata() to know nothing about previews is good. The cost of determining if there are previews is imposed by using the preview manager.

I don't believe the overhead of preview manager is severe. In our test suite, we have the same image in two formats: test/data/Reagan.jpg (with preview) and test/data/Reagan.jp2 (no preview). The option -pp uses the preview manager to extract the previews. The performance is about 10% slower than -pa (which only uses readMetadata()).

$ time for i in {1..1000}; do echo test/data/Reagan.jp2 ; done | xargs exiv2 -pa --grep original/i | wc
   3000   16000  307000

real	0m1.636s
user	0m1.645s
sys	0m0.135s
718 rmills@rmillsmbp:~/gnu/github/clanmills/exiv2 $ time for i in {1..1000}; do echo test/data/Reagan.jp2 ; done | xargs exiv2 -pp 

real	0m1.779s
user	0m1.660s
sys	0m0.115s
$ 

When I use the file Reagan.jpg (which has a preview), the difference is again about 10%.

$ time for i in {1..1000}; do echo test/data/Reagan.jpg ; done | xargs exiv2 -pa --grep original/i | wc
   3000   16000  307000

real	0m1.610s
user	0m1.660s
sys	0m0.101s
$ time for i in {1..1000}; do echo test/data/Reagan.jpg ; done | xargs exiv2 -pp | wc
   1000    8000   72000

real	0m1.732s
user	0m1.698s
sys	0m0.077s
$ 

I don't believe any action should be taken to implement image::hasEmbeddedPreviews() for the following reasons:

1. This could only be reliable if readMetadata() performed similar metadata analysis as the PreviewManager. This would impose a performance penalty on every user of readMetadata() even if they had no interest in previews.

2. Preview manager performance is about 10% of readMetata(). As you wish to extract the thumbnails, you are using something that is useful for your purposes.

Is there any reason why we cannot agree that this matter is closed?

[whatdoineed2do]

Appreciate the investigation

As it is impl I agree the overhead for looking everywhere for embedded images as part of normal readmetadata() is not appropriate.