| Re: tvrd and device,decomposed=0 [message #19776] |
Wed, 26 April 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
David Fanning <davidf@dfanning.com> wrote in message
> All this monkeying around with Device Decomposed is a hassle,
> of course, but that is why I wrote TVIMAGE and Liam wrote IMDISP,
> so you don't have to worry about it. I frankly don't know why
> RSI doesn't offer to buy this code from either one of us.
> (Well, I can guess why they don't buy it from me, but what
> has Liam ever done to make them upset?) :-)
It's too late for me to make any money from IMDISP, what with the GNU GPL
and all. Still it's nice to have intelligent people tell me they learned
something from reading the code:
http://cimss.ssec.wisc.edu/~gumley/imdisp.html
R. Bauer wrote
>> Why are the results of tvrd and tvlct not itself changed automaticly
>> to pseudo_color?
TVRD is a very low level function, and it needs a fair bit of intelligence
wrapped around it to get sensible results, such as the SAVEIMAGE screen
grabber:
http://cimss.ssec.wisc.edu/~gumley/imagetools.html
If you display a PseudoColor image when IDL is running in 24-bit mode, and
you read the screen using TVRD into a TrueColor image array, there is no
guarantee that you can convert the array to a PseudoColor image (using
COLOR_QUAN or anything else) that would *exactly* match a PseudoColor image
which was displayed and read from the screen in 8-bit mode.
I run in 24-bit all the time, and I've given up saving 8-bit images from the
screen for this reason. I save TIFF images if I want lossless compression,
or JPEG images if I don't mind lossy compression.
Another reason to avoid a certain well-known 8-bit image format is the
licensing issues which are involved:
http://burnallgifs.org/
Cheers,
Liam.
|
|
|
|
| Re: tvrd and device,decomposed=0 [message #19777 is a reply to message #19776] |
Wed, 26 April 2000 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
R.Bauer (R.Bauer@fz-juelich.de) writes:
> If I have a true color table and I have set device,decomposed=0
> the online help says:
>
> Online Help:
> "Set this keyword to 0 to cause the least-significant 8 bits of the
> color index value to be interpreted as a PseudoColor index.
> This setting allows users with DirectColor and TrueColor displays
> to use IDL programs written for standard, PseudoColor displays
> without modification."
>
> WITHOUT MODIFICATION: :-(
Oh, well, Reimer, you're German so perhaps you can't be
faulted for believing everything you read. I'm sure this
was written by the marketing staff and not the programming
staff, since (as you are learning) this stretches the truth
just a *tad*. In fact, your programs have to be modified
quite a lot if you intend to *use* them the way you did
on an 8-bit display. :-)
> I have to use tvrd() by the true=1 keyword.
Indeed.
> The TVLCT,red,green,blue,/get returns colors which I have to translate
> by
> color_quan to pseudocolor.
Humm. I think this is where you are becoming confused a bit.
These color vectors are the correct color vectors, alright,
*IF* you have an 8-bit image. But if you are talking about
the image you got with TVRD, you *don't* have an 8-bit image,
you have a 24-bit image _with the colors built in_.
Now, it is entirely possible that you *wish* you had an 8-bit
image. And if that is the case, you do need to use Color_Quan
to obtain it. And while you are doing that Color_Quan will also
create some appropriate color table vectors for you:
image24bit = TVRD(True=1)
image8bit = Color_Quan(image24bit, 1, r, g, b)
To display this image properly, you will have to first load
the color table vectors:
Device, Decomposed=0
TVLCT, r, g, b
TV, image8bit
But these color table vectors will have *nothing* whatsoever
to do with the original color table vectors you loaded when
you first started this whole exercise. :-)
But all is not lost, really. Because if all you want to do
is display the 24-bit image you copied off the display, all you
really have to do is this:
Device, Decomposed=1
TV, image24bit, True=1
It will look exactly the same as your original display window.
All this monkeying around with Device Decomposed is a hassle,
of course, but that is why I wrote TVIMAGE and Liam wrote IMDISP,
so you don't have to worry about it. I frankly don't know why
RSI doesn't offer to buy this code from either one of us.
(Well, I can guess why they don't buy it from me, but what
has Liam ever done to make them upset?) :-)
> If the device graphics mode is changed from 3 to 6 and back the colors
> are mixed. This did not happen if I have used 8-Bit colors.
Oh, my God. Please don't muck about with graphics functions or
you will get us ALL confused. :-(
> Why are the results of tvrd and tvlct not itself changed automaticly
> to pseudo_color?
Well, for one thing, once you understand 24-bit color you
immediately see all the limitations inherent in pseudocolor
applications and you NEVER want to go back to them. So, in
this sense at least (and I know you don't fully appreciate it
yet) RSI is doing you an immense favor. :-)
Cheers,
David
P.S. Let's just say you are probably further along on the learning
curve than you think you are. Just a few short steps to go...
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
