On Mon, 2008-04-21 at 11:18 +0100, Øyvind Kolås wrote: > The floyd steinberg type of error diffusion is going a bit contrary to> the way GEGL is designed, since effectivly to bottomright most pixel> depends on the contents of the entire image. Thus if the upper left> pixel in the image changes the entire image needs to change as well.> Thus to correctly implement floyd steinberg you would actually have to> request the processing of the entire image and not piece by piece thus> losing the ability to handle larger than RAM images. The stretch> contrast operation is another operation where single pixels depends on> the entire image. The way I did this in a GIMP 2.4 plugin is I load a row at a time fromthe backing store, and keep two rows's worth of quantization error datain memory at all times -- one for the current row and another for thenext. When a row is complete, I swap the error buffers and load the nextrow of image data. Would an approach like this be possible with GEGL, or is it outside itsscope? > There are other digital halftoning methods that probably are a much> better match for GEGLs processing design. Where the value for any> given pixel only depends on it's neighbourhood and not the entire> image. Could you recommend one? I've already tried random dithering, whichlooks terrible, especially at low resolutions, and Bayer, which is verypoor in details (but good on gradients). Most of the halfway decent algorithms I'm familiar with are based on theFloyd-Steinberg method of error diffusion. > (Do also note that GEGL currently does not support <8bit> component, so the memory use if you are going all the way down to> 1bit/component is going to be massive as you would have to use> 8bit/component to simulate it.) That's fine -- I'm doing color reduction with dithering on images to beused in an OS installer, which will run at low resolutions and 16-bit(565) color. How they're stored is an implementation detail, but howthey look is important. -- Hans Petter Jansson <hpj@xxxxxxxxxxx> _______________________________________________Gegl-developer mailing listGegl-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
