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
