get their alpha thresholded. To do any real work on an indexed image I
already have to go by RGB.
Duplicating this behavior in GEGL would not be appropriate in my
opinion, if an indexed image is loaded, the lookup table of the
palette is interpreted and it is treated as a color image. Thus GEGL
will have the same stance towards GIF/PCX as JPG, RAW and SVG, they
I assume you meant GIF/PCX/PNG
might be included as source material verbatim, but expecting palette
preserved, DCT level compositing, non-demosaiced bayer-data or vectors
in the output,. after compositing and image processing, is quite
simply outside the reasonable scope for a image processing/compositing
library.
I want it DURING compositing.
I was assuming that, until an indexed image had to be composited with a non-indexed image, its data could remain indexed. However, if the palette could be separately recovered from the original file (as another input to the compositing Op), so it could be used to govern blending behaviour, that would be equally practical.
Here's a little python docstring sketch of one of the the functions I was considering:
"""Shade -- Grafx2 style shading facility.
Colors are considered as indices by SHADE, even on a RGB source.
lut[NCOLORS] A Numpy array, the result of applying one step of shading
to COLOR.
Should be precalculated to have the appropriate
output format (RGB or RGBA or GRAY)
shadeable Dictionary color:index
Basic process:
pixel = srcpixels[x,y]
color = hash(pixel[:3]) # ignore alpha
try:
index = shadeable[color]
destpixels[x,y] = lut[index]
except:
destpixels[x,y] = pixel
"""
I'm sure you can see how it would be simplified and significantly sped up if I could just read indices, look their 'next color' up, and write the resultant indice.
Simply being able to get image data into an indexed form with some chosen palette(doesn't have to be the exact original) just before passing it through an Op like SHADE above, would work well for that. Is that kind of thing possible or likely to be supported?
Here's a little python docstring sketch of one of the the functions I was considering:
"""Shade -- Grafx2 style shading facility.
Colors are considered as indices by SHADE, even on a RGB source.
lut[NCOLORS] A Numpy array, the result of applying one step of shading
to COLOR.
Should be precalculated to have the appropriate
output format (RGB or RGBA or GRAY)
shadeable Dictionary color:index
Basic process:
pixel = srcpixels[x,y]
color = hash(pixel[:3]) # ignore alpha
try:
index = shadeable[color]
destpixels[x,y] = lut[index]
except:
destpixels[x,y] = pixel
"""
I'm sure you can see how it would be simplified and significantly sped up if I could just read indices, look their 'next color' up, and write the resultant indice.
Simply being able to get image data into an indexed form with some chosen palette(doesn't have to be the exact original) just before passing it through an Op like SHADE above, would work well for that. Is that kind of thing possible or likely to be supported?
Adding capabilities outside GEGL that special cases editing of indexed
drawables is of course an option, (in the same manner that the path
tool or inkscape would be possible to invoke for operation on SVG
based vector data.
That would address using SHADE above as a paint mode, maybe. With the Op-based paint application model that has been discussed here and on Bugzilla,
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
