If it looks generally useful as a function to reduce a continuous-tone image to a fixed number of colors, that may be something that we want to turn into a general utility. Let's do it inside the GIF plugin at first, but perhaps with just a little bit of design awareness that someday we may wish to elevate that function to ImageBufAlgo.
One thing we don't want to do, is make palette/indexed images a first-class concept on the app side of the OIIO API. No app should need to directly manipulate palette images or consider whether the file happens to store the image as a palette image (or even access the original palette), any more than that the app should need to know the particular compression method or access the compressed version of the bitstream. On Oct 13, 2013, at 12:34 PM, Mariusz Szczepańczyk wrote: > Ok so I'll keep the color map generation code within ImageOutput > implementation then. > > > On 13/10/13 18:10, Larry Gritz wrote: >> In that thread, I meant the tiny amount of dither that is sometimes added >> when converting floating point to integer data, usually the magnitude of the >> dither is just +/- 1/2 quantization unit, right before the conversion to >> integer. We never tackled that, and as far as I know, nobody has really >> brought it up since then (despite pretty widespread use of the tools), so >> I'm assuming it's not a pressing issue. >> >> For a format like GIF where the only supported output format is an indexed >> color map, I would certainly expect the plugin to handle the selection of >> color map and dithering to try to make a continuous image look as good as >> possible under those constraints. >> >> >> On Oct 13, 2013, at 7:42 AM, Mariusz Szczepańczyk wrote: >> >>> Hi, >>> >>> I am the author of a read support for GIF images and at last found some >>> time to get down to writing an output plugin. >>> >>> As far as I know the GIF specification enforces the usage of an indexed >>> color map limited to 256 colors. So to do any sensible conversion from high >>> resolution source image, some kind of color quantization and dithering is >>> needed. I did a little lookup and found this thread from 2010: >>> http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2010-December/003687.html >>> >>> Larry, you raised the issue that dithering shouldn't be implemented by an >>> individual plugin and how should it be exactly done is a matter to think >>> over. What is the current status of the subject? Have you had any thoughts >>> how should it be resolved? >>> >>> Regards, >>> Mariusz >>> >> >> -- >> Larry Gritz >> [email protected] > > _______________________________________________ > 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
