CLIM mail archive
Image Processing in CLIM
Date: Tue, 3 Mar 1992 14:16 EST
From: Jonathan Bachrach <email@example.com>
Date: Mon, 02 Mar 92 18:17:03 EST
From: "David A. Moon" <firstname.lastname@example.org>
Re: hacking the color map
Not all platforms with color displays have color maps. I believe the design
was intended to be that the standard CLIM entry points provide
platform-independent graphics with the functionality that all platforms can
support, and if you need to do something like control the color map or
display 24-bit-color images, that's platform-dependent code that must use
platform-specific interfaces, and will work on the subset of platforms that
support those interfaces. I guess the problem with this is that these
platform-specific interfaces didn't get documented by the vendors of the
individual platform-specific versions of CLIM, and perhaps don't even exist
in some cases where they could.
It seems reasonable that ``usual'' CLIM entry points should provide
That is presently the case.
I think, though, that CLIM should
specify a platform-dependent interface for dealing with color image
processing. It seems unreasonable to preclude the use of these
powerful mechanisms because not all machines support them.
I hardly think it is unreasonable for a product whose main goal is
portability to leave unspecified those things that are inherently
non-portable. The only suggestion I have heard has been for color
"palettes" that are sort of like color maps, but are probably less
flexible than you want.
these mechanisms are universal and are implemented by all
manufacturers. Therefore, it seems critical to provide a standard
CLIM interface to these mechanisms.
In what sense do you mean universal? A good analogy might be comparing
bicycle wheels, car wheels, wagon wheels, and trains wheels. They're
all wheels, but their "UI" is pretty different. What I mean by this
analogy is that, sure, there are such mechanisms implemented by a bunch
of vendors, but that they are really not very similar.
I would like to know from the implementors, what support they have
provided for this platform-dependent case -- specifically, what
support have they provided for 8-bit color tables and 24-bit color
None. Which of the several common formats for color maps and the dozen
or so formats for 24-bit images should be done first? What sort of
algorithm(s) should be used to convert from 24-bit images to 8-bit
displays? Is there even the smallest chance that your requirements are
not quite different from the requirements of other users?
For example, if I want to run CLIM on a 24-bit color machine
and use 24-bit color images in a reasonable fashion, am I out of
The area of stored color images is an appropriate one for user-written
submissions to a public CLIM library.
I firmly believe that having CLIM natively support toolkit-style
programming is the most important goal for the near term, and that is
certainly what we are spending our time on. The paths for accessing a
display device directly is made more clear in CLIM 2.0, so it will be
somewhat easier to "roll your own" in CLIM 2.0 than it is in CLIM 1.0.
Main Index |