jonm@syma.sussex.ac.uk (Jonathan Meyer) (08/29/90)
I'm sure that many people would agree with me if I said that one of the most unpleasant part of X is handling color images. I'd love someone to rationalise the situation for constructing new colors. Whoever named the following two procedures must have been a little tired: XAllocColor - allocate single READ ONLY color cell XAllocColorCells - allocate multiple READ WRITE color cells What happened to multiple read-only color cells, or a single read write color cell? It seems our memory is once again left to do the work, rather than an explicit naming system. I would love something like: XAllocReadWriteColor XAllocReadWriteColors and XAllocReadOnlyColor XAllocReadOnlyColors Which take a color or array of colors and allocate them corrospondingly, returning 1 on success. Another thing I miss is the ability to determine whether a pixel value is a valid allocated color, an unallocated color, and whether it is read-write or read-only for a specific display connection. It would also be very useful to see if an RGB value is named in the color database for a display, so that I can take a pixel value and determine what named color it corrosponds to. Maybe XQueryColor could be extended to do something like this. Next, I would love a hook on XImage structures for XGetImage/XPutImage so that I could perform normalization on the pixel values on the fly as they go up/down the socket. This way, I can write a conversion procedure that maps between image data and colormap pixel values (and visa-versa) which work invisibly. Specifying normalization procedures of NULL would result in optimized performance using no normalization. This system would be much more useful than writing coercion procedures that I call before an XPutImage and after an XGetImage. Since just about every image goes through this conversion procedure, I think that all of us would benifit from such a feature. Of course, a standard image format would help (and XPM is a start), but can people remember that some of us are performing image processing; 1/2 or 1 MB grayscale images are commonplace - an ASCII format such as XPM would be unsuitable for such images. Personally, I'm happy with sun rasterfiles, and support converting between pixmaps and rasterfiles would be wonderful! Now, I could go on to talk about the Xt (especially things like resource conversion dependancy trees), but then again... Jon
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (08/31/90)
Jonathan Meyer writes a plea for reworking the color library routines. For the most part I agree with him, but have a couple of comments. > Whoever named the following two procedures must have been a little > tired: > XAllocColor - allocate single READ ONLY color cell > XAllocColorCells - allocate multiple READ WRITE color cells The names actually do make sense. In XAllocColor, you are allocating a color; the fact that it happens to live in a colormap cell is more or less incidental. In XAllocColorCells, you are allocating the colormap cells per se, rather than asking for a color and getting a colormap cell as a necessary side-effect. Not that this means I think they couldn't be improved. > What happened to multiple read-only color cells, or a single read > write color cell? Briefly, the former isn't wanted much and the latter is trivial. In more detail.... Applications that want read-only colors typically want only a few of them (foreground, background, highlight, perhaps), so an interface allowing multiple XAllocColor()s to be done at once would not get much use. Allocating a lone read-write cell, of course, is done by allocating multiple read-write cells but passing a count of one instead of something higher. Again, this is not to say the situation can't be improved. > Another thing I miss is the ability to determine whether a pixel > value is a valid allocated color, an unallocated color, and whether > it is read-write or read-only for a specific display connection. I think the philosophy is that you shouldn't care about any colormap cells (aka pixel values) that you didn't allocate. Why do you want to find this out? You may be trying to solve the wrong problem. (As for the last part of your sentence, colormap cells are either read-only or read-write globally, not read-write to some connections and read-only to others. The Xlib manual notes that you *can* stomp on some other program's read-write cell, but that it's of course rather antisocial behavior.) > Personally, I'm happy with sun rasterfiles, and support converting > between pixmaps and rasterfiles would be wonderful! Until/unless Sun donates the rasterfile format, and routines to use the things, to the free software community, it seems unlikely (to me) that X will use them. In the meantime, there's xpmtoppm and ppmtoxpm[%], which you can use with ppmtorast and rasttoppm.... Of course, most of the usefulness of Sun rasterfiles is the Sun pixrect library, not the file format itself. I'm tempted to write free replacements for the pixrect library routines - which of course one wouldn't use on a Sun, because they'd be slower than the originals, but might be nice to have elsewhere. The format also needs to be extended to handle depths other than 1/8/24, and probably a few other things...perhaps someday when I'm feeling bored. [%] I assume xpmtoppm and ppmtoxpm exist; I haven't picked up the xpm software yet.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
marbru@auto-trol.UUCP (Martin Brunecky) (09/01/90)
In article <9008302203.AA20951@shamash.McRCIM.McGill.EDU> mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes: >Jonathan Meyer writes a plea for reworking the color library routines. >For the most part I agree with him, but have a couple of comments. > >> Another thing I miss is the ability to determine whether a pixel >> value is a valid allocated color, an unallocated color, and whether >> it is read-write or read-only for a specific display connection. > >I think the philosophy is that you shouldn't care about any colormap >cells (aka pixel values) that you didn't allocate. Why do you want to >find this out? You may be trying to solve the wrong problem. > Just for example, my scenario would be as follows: I want to display continuous-tone image, with dynamic tone changes possible. Thus I need as many writeable color cells as I can get. On the other hand, I want to be "good citizen" and MINIMZE the "techniclor effect" when my colormap gets installed. So, I would like to copy the "most frequently" used colors from the default (shared) colormap into my private one. This would minimize color flashing... The problem is which colors to pick. Obviously, black and white are given by the display connection. But I'd like to preserve couple more. Out 256 colors, I can "spare" say 16 for "good behavior". So, I would like not only to querry if this is an allocated color, but also how many times it has been allocated .... And, naturally, I won't try to copy writeable color cells... -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404