| Re: 24-bit/8-bit color (Re: read_tiff - simple question) [message #14543 is a reply to message #14495] |
Tue, 09 March 1999 00:00  |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
Stein Vidar Hagfors Haugan wrote:
>
> David Fanning wrote:
>
>> P.S. I've just received the latest batch of IDL books from
>> the printer. This version has been updated rather extensively
>> for IDL 5.2. I have also increased the amount of discussion
>> on 8-bit verses 24-bit image display, as this continues to
>> be a source of confusion for many IDL users as we make the
>> transition from 8-bit to 24-bit computers.
>
> So what's the "upgrade fee" :-)
>
> Seriously, I'd like to take this opportunity to add something to
> the discussion we had a while ago, concerning pseudo-8-bit
> behaviour etc:
>
> I (and some others) expressed concern that RSI should be doing
> something about the inability (on 24-bit PC displays) to do e.g.
>
> TVSCL,IMAGE & XLOADCT
>
> from the command line in order to "explore" an image by tweaking
> the color map. I believe I (we) speak for a substantial user
> group in this matter - having to redisplay an image to see color
> table changes is just *not* acceptable for command line work.
>
> Why should users of "new and improved" hardware + "new and
> improved" IDL versions have to go through a lot of programming
> hassle (or use canned programs) in order to do something that
> could be done in an intuitive way in the "good old days"...
>
> So, along the same lines that IDL does offer graphics window
> backing store, I think RSI should offer the possibility of
> "value" backing store, i.e. storing the 8-bit color table index
> and automatically updating the display colors whenever a new
> color table is loaded.
>
> Having thought about this for a while, I think it would be best
> if this was done on a "per-window" basis. I.e., when creating a
> new window, one could specify whether or not it was intended for
> interactive (command line) color table manipulation. That way, the
> full 24-bit color scale would be available to [widget] programs,
> while at the same time allowing the user to do explorative color
> table changes in non-program windows (this is all the more
> important now that we have the active command line alongside
> widget programs).
>
> It would also be nice to make the DECOMPOSED=0/1 status be a
> property of whatever window is currently set, to avoid having to
> set this status in programs every time graphics output is about
> to occur.
>
> I realize that there will be some penalty wrt. efficiency, but
> this penalty will be a lot smaller if the functionality is
> offered by IDL internally, rather than by *always* requiring the
> use of programmed "TV wrappers" with callback functions to
> deal with both decomposition and color table updates.
>
> As an extra bonus, it would be *very* nice if one could specify
> more than one such "interactive colormap" - i.e. along the lines
> of:
>
> window,0 ;; Default window creation, means "use the
> ;; current colormap (let's call it "map1"),
> ;; in interactive mode ("value" backing store)
>
> tvscl,image1 ;; Display image1 with this color map
>
> window,1 ;; Create new window, still using map1
>
> tvscl,image2
>
> xloadct ;; Manipulate current map, with instant
> ;; update of window 0 and 1 (since they're
> ;; both using the map that's manipulated).
>
> newmap = obj_new('pseudomap') ;; Create a new (interactive)
> ;; colormap
> window,2,pseudo=newmap ;; Both windows share this new map
> window,3,pseudo=newmap ;;
> :
> xloadct ;; Manipulates current (i.e. "newmap") color table,
> ;; updating window 2 & 3, no effect on 0 and 1.
>
> wset,0 ;; Now we're switching to a window using map1
> xloadct ;; Manipulate map1 again.. no effect on window
> ;; 2 and 3, but instant update of 0 and 1.
>
> In the case of an 8-bit display, all the color tables would
> probably be identical, with changes to one reflected in all
> windows. Or maybe one could still have different color tables
> internally, and the effective one (the one that's actually
> communicated to the screen hardware) would depend on which window
> was selected/active (wset)?
>
> Any comments/improvements?
>
> Regards,
>
> Stein Vidar
One word...ditto!
In our research we constantly require very interactive changes of
gray-scale color-tables, and 24-bit color simply does not do what
we need. All of our major widget programs require 8-bit color (so
this is important for more than just command-line work).
I sincerely hope that Research Systems does not underestimate the
number of users that will be very upset if they drop support for
8-bit color in any way, shape or form.
I like the suggestions for supporting interactive 24-bit color,
and especially the suggestion for window-specific color-tables.
I haven't thought enough about this to hazard a guess as to the
feasability of these suggestions, or the performance hit resulting
from their implementation, but if they would work, I would consider
them to be a VERY valuable feature.
Just my .03 (inflation).
Dave Foster
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2240
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
