| Re: 16-bit tiffs [message #11092] |
Sat, 14 March 1998 00:00 |
bowman
Messages: 121
Registered: September 1991
|
Senior Member |
|
|
Is this a color or black-and-white image?
I've been writing 24-bit color images as raw binary and then converting
them on my Mac to other formats using GraphicConverter (shareware). There
must be similar programs for PC's and Unix. GraphicConverter will batch
convert large numbers of files.
I write the files like this:
window -> DRAW, view ;Draw view in window
window -> GETPROPERTY, IMAGE_DATA = image ;Read image from window
;image will be (3,nx,ny) if your device is set to 24-bits
;This is for object graphics, for direct graphics, use TVRD().
FOR iplane = 0L, 2L DO $ ;Flip image right side up
image(iplane,*,*) = ROTATE(REFORM(image(iplane,*,*)),7)
OPENW, ounit, outfile, /GET_LUN ;Open new file for writing
WRITEU, ounit, image ;Write image to file
FREE_LUN, ounit ;Release out unit and file
You need to know the size of the image to read the raw file.
If you are only using 4-bits of the dynamic range (0-15), multiply each
8-bit image plane by 2^4=16 to scale to 0-255 before writing.
Regards, Ken Bowman
--
Kenneth P. Bowman, Assoc. Prof. 409-862-4060
Department of Meteorology 409-862-4132 fax
Texas A&M University bowmanATcsrp.tamu.edu
College Station, TX 77843-3150
|
|
|
|
| Re: 16-bit tiffs [message #11094 is a reply to message #11092] |
Sat, 14 March 1998 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Deb Summa (summa@lanl.gov) writes:
> How does one write a 16-bit TIFF image in IDL? (Can this be done at all
> in IDL?)
Using IDL? Yes. Using built-in IDL routines? I don't think so.
> READ_TIFF will import a 16-bit TIFF image into an INT array just fine,
> but WRITE_TIFF reduces the aforementioned INT array to a BYTE array and
> writes out an 8-bit TIFF. I'd like to be able to maintain the dynamic
> range present in the original image. Do i have to turn the whole thing
> into a 24-bit image first? (and how does one do that if that's what has
> to be done?)
The more I've thought about this question (and I woke up at
4:30 this morning thinking about it, if you can believe that!)
the more I think it is entirely the wrong question.
For example, I don't know what "maintain the dynamic range
present in the original image" means. What "dynamic range"?
Of the *displayed* image? Then the dynamic range is dictated
by your display hardware, not the image data.
Your display is capable of only so many colors, say 256.
No matter what the range of the actual image data, you
will see the data in that many colors. Certainly the dynamic
range is not preserved in this abstraction. Believing that
what you see on the display is really your data is similar to
believing that the word "love" is the same as the feeling.
I may be entirely wrong about this, but I don't normally think
of the TIFF data format as a format that is particularly
useful for storing the "dynamic range" of data. I think of
it as a useful format for storing the "color abstraction" of
data. Typically, for display on some colleague's machine.
If I really wanted to preserve the dynamic data range, I think
I would be using something like HDF, where I could store the
actually data AND its color abstraction (in a palette, for
example).
Anyway, my two cents worth.
Cheers,
David
-----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
E-Mail: davidf@dfanning.com
Phone: 970-221-0438
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
