CLIM mail archive
[Prev][Next][Index][Thread]

Image Processing in CLIM

    Date: Tue, 3 Mar 1992 14:16 EST
    From: Jonathan Bachrach <bachrach@icsi.berkeley.edu>

	Date: Mon, 02 Mar 92 18:17:03 EST
	From: "David A. Moon" <moon@cambridge.apple.com>
	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
    platform-independent graphics.  

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.

								In fact,
    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
    images?  
	     
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
    luck?

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.
References:
Main Index | Thread Index