Yes, exactly! There is an existing naming convention for storing thumbnails in 
the metadata, let's use it for OpenEXR as well.

It seems like a no-brainer to have oiiotool and/or maketx take an option that 
causes it to generate a thumbnail and add it to the output. (Hint: 
ImageBufAlgo::resize() can do the heavy lifting.)

It's a little trickier to imagine having the normal Exr ImageOutput do it.  
While we could use the "open with config" call (you know about this, right?) as 
a way to request that a thumbnail be automatically generated (say, if the 
config contains attribute "generate_thumbnail" with a nonzero integer value), I 
don't see how this could work easily unless we buffer the whole image as it's 
output, which in most cases would be undesirable.  An alternate approach would 
be to only buffer the thumbnail and resize and add each scanline or tile to the 
thumbnail tally as they fly by, without buffering the big image. But that's a 
lot more new code than just calling IBA::resize(), and I don't know off the top 
of my head if libIlmImf would even let you add the thumbnail after the rest of 
the image is written, or if you need to know it up front when you first specify 
the header.

        -- lg

On Jun 18, 2014, at 8:11 AM, Mark Boorer <[email protected]> wrote:

> I've just noticed the "thumbnail_*" set of metadata tags in the psd and targa 
> plugins, so it looks as though option 1 is currently used for those formats, 
> but I don't think it's such a terrible idea to help users automatically add 
> thumbnails, or at least generate them.
> 
> Cheers,
> Mark
> 
> 
> On Wed, Jun 18, 2014 at 4:07 PM, Mark Boorer <[email protected]> wrote:
> Hi all,
> 
> I've just had a request to add preview images in the EXR's I generate via 
> OIIO, and I don't think there's any facility to do so at the moment.
> 
> Before I head off down the path of implementing this feature, I just wanted 
> to sound off my current ideas and see what people think.
> 
> The way I see it, we can either implement this as:
> 
> 1. Expose the ImfPreviewImageAttribute as a simple char array containing the 
> jpg image in the reader, and support writing this back out in the writer, 
> with no additional help.
> 
> 2. Automatically generate the preview image in the EXR writer, perhaps 
> allowing the resolution to be specified somewhere in the ImageSpec.
> 
> 3. A combination approach, where we expose a function to generate the preview 
> image in the desired resolution, but the user still has to explicitly add it 
> to the extra_attribs object.
> 
> I'm leaning towards 3, but wouldn't know where we would like the 
> generatePreviewImage functionality to live.
> 
> Thoughts?
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]



_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to