[FEATURE REQUEST] oiiotool thumbnail extraction

[lgritz]

Not sure how this oversight happened, but there currently not an oiiotool command that extracts a thumbnail from an image. That would be handy.

For that matter, oiiotool also doesn't make it easy to create or add a thumbnail and save the resulting image. That is trickier, though, requires a bit more design maybe.

[lgritz]

Some possible design ideas (not necessarily mutually exclusive):

1. A separate command to extract thumbnail from the top image that already has been loaded:
   oiiotool input.exr --thumbnail_get -o thumb.exr
   Questions: Should it push the thumbnail to the top of stack as a separate image? Or should it replace the top image with its thumbnail? What happens if there is no thumbnail -- should that be an error, or return the full-res image, or auto-generate a reduced-resolution copy, or return an essentially blank tiny image? Maybe optional modifiers to --thumbnail_get can select among these options.

2. Augment the -i read command with a command to get the thumbnail rather than the main image:
   oiiotool -i:get_thumbnail=1 input.exr -o thumb.exr

3. Generate a thumbnail of an arbitrary image (presumably prior to a write):
   oiiotool input.exr ...commands... --thumbnail_generate -o out_with_thumb.exr

[grdanny]

What is a thumbnail in this context?
some exrs have a smaller version of the image embedded as sub image?
can't you just do the same thing with --resize?

[lgritz]

Lots of image formats allow storing a low rez image in the header that can be used for quick preview without reading the full-res image and resizing it. The OIIO APIs actually allow you to retrieve that preview image (if it exists), but curiously, we never exposed that via oiiotool in a way that would let you extract it and treat it as a real image.

[jinhgkim]

This seems super useful. Would you mind if I took a look?

[lgritz]

This seems super useful. Would you mind if I took a look?

Please feel free!

[jinhgkim]

Some possible design ideas (not necessarily mutually exclusive):

1. A separate command to extract thumbnail from the top image that already has been loaded:
   oiiotool input.exr --thumbnail_get -o thumb.exr
   Questions: Should it push the thumbnail to the top of stack as a separate image? Or should it replace the top image with its thumbnail? What happens if there is no thumbnail -- should that be an error, or return the full-res image, or auto-generate a reduced-resolution copy, or return an essentially blank tiny image? Maybe optional modifiers to --thumbnail_get can select among these options.
2. Augment the -i read command with a command to get the thumbnail rather than the main image:
   oiiotool -i:get_thumbnail=1 input.exr -o thumb.exr
3. Generate a thumbnail of an arbitrary image (presumably prior to a write):
   oiiotool input.exr ...commands... --thumbnail_generate -o out_with_thumb.exr

Here are some of my thoughts before diving into the implementation:

1. I think we should replace the top image with its thumbnail, mimicking --subimage. If there is no thumbnail, we should throw an error and fail loudly. For batch processing, users can opt into continuing with :fail=0. Returning the full-res image could be a bit misleading for the use of this tool. Auto-generating a thumbnail could be useful, but users may have specific preferences about resize dimensions, filters, color handling, etc. I think it is better to leave thumbnail generation under user control, while keeping the door open through something like option 3 below.
2. I like supporting this as well. Return the thumbnail if one exists, fail loudly otherwise.
3. I would suggest renaming it to --thumbnail_set to stay consistent with --thumbnail_get. The user can generate the thumbnail however they want using existing operations, then attach it.
   e.g., oiiotool input.exr --dup --resize:filter=box 128x128 --thumbnail_set -o out.exr

[lgritz]

Sorry for the delay in responding, @jinhgkim.

1. I agree. Replace, like --subimage. If you want it to merely add the thumbnail, you can always do --dup --thumbnail_get. The :fail=0 is a good idea as an option.

2. Yes, symmetric names are better.

A wrinkle we maybe haven't considered: some formats might allow more than one thumbnail (e.g. at different resolutions). So we may want to at least account for that in the design somehow.

[jinhgkim]

No worries! Sounds good. I’m thinking of exposing an optional :index modifier alongside :fail, defaulting to 0. Until #4888 is implemented, any nonzero index would produce an error explaining that only the primary thumbnail is supported. I’d also be happy to look into #4888 separately if that would be helpful.

[lgritz]

That sounds great.