comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: 16-bit tiffs

Re: 16-bit tiffs
type: item
description: 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
creator: bowman
date: 1998-03-14T08:00:00-00:00

Re: 16-bit tiffs
type: item
description: 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-2…
creator: davidf
date: 1998-03-14T08:00:00-00:00