dave@hanauma (Dave Nichols) (07/01/89)
I too have a problem understanding colors. I have an image processing application where I need to create my own colormap. I am using the InterViews toolkit which when it alocates its internal color objects uses XAllocColor. We had to modify InterViews slightly to allow use to use a non-default colormap. When I create my colormap I create it "AllocNone" so that color allocation will be allowed. ( At least thats what I think it means ). The documentation for XAllocColor says, (O'Reilly vol-2) " If a read-only color cell exists that matches the requested RGB value that cell is returned. If no matching cell exists and there are no unallocated cells the closest available colorcell that has already been allocated is returned" So here is what I do, I allocate my colormap, then I fill up all 256 entries with RGB values of my own choice using XAllocColor. As I understand it when InterViews calls XAllocColor the colormap will be full and it should get back the closest color to the one requested. What actually happens is that it gets a non-zero return code from XAllocColor and fails later on when it tries to use the color. I am running on a DECstation-3100 under DECWindows.
rws@EXPO.LCS.MIT.EDU (07/03/89)
The documentation for XAllocColor says, (O'Reilly vol-2)
" If a read-only color cell exists that matches the requested RGB value
that cell is returned. If no matching cell exists and there are no
unallocated cells the closest available colorcell that has already been
allocated is returned"
The O'Reilly documentation is incorrect on this point. For a dynamic
visual (such as PseudoColor), the server transforms your requested RGB values
into the closest values representable by the hardware. There must be an
exact match of these RGB values with values stored in a colormap entry.
For image processing applications, a Standard Colormap (as described in Xlib)
is often better to use than individual color allocations.