write I16 tiff file

[madatgod]

The solution to writing the 12-bit tiff is not complete (so far as I can tell).

The actual tiff file that gets written with the “IMAQ Write File 2 (tiff)”

routine, is always a U16 file and I16 data immediately gets written as

2^15 larger pixel values than desired.

 

Is there a fix for this?

Thank you,

Jeremy.

[Andy_C.]

Do you have to work with TIFF file or could you use BMP or JPG? With IMAQ Write File 2 (TIFF) it'll convert to 12-bit automatically

[madatgod]

Well, I really do need to work with tiff files to stay company standard, also, I do not want

a 12 bit file, I want a signed-16bit file (though the values will never drop below zero).  Is

this impossible?

[Coq_Rouge]

You do know that you can not write 12 bits of information only to a file. All date will be written as two bytes

[madatgod]

Is this what my 1200/yr for labview +600/yr for imaging support gets me?

Seriously, is this the only support left for these kinds of questions?  Or is

there some way to ask someone that might have a reasonable answer?

[Andy_C.]

I'm trying to understand what you are trying to achieve.

Are you working with a 12-bit array and wants to save it as I16? Is it possible for you to post an example code that you are working with?

I'm showing an example of saving a I16 bit array as TIFF then read it and the image is still I16

[madatgod]

Thank you, Andy.

I am simply working with I16 data (but all positive), and I wanted to write it to a tif file.

While it is true that you can write the tif, and when read back in labview will keep the

data as expected.  If you are concerned about the actual pixel values of the tif file (as

read by, say, a third party tif reader) then you will find that the pixels have all had

32768 added to them.  That is, the most signficant bit is "one" for all pixels and when

written to file you end up with articially inflated values on (at least) some 3rd party tiff

readers.  This appears to be because "signed 16 bit" tif files are non-standard or not

supported everywhere.

The solution was to cast the pixels to an I32 and then subract 32768 from each pixel

before casting back to I16.  This worked (I am not sure if that is the same effect as

what you have shown).

Nevertheless, this solution was, in fact, in an NI knowledge base article somewhere that

an NI engineer helped me to find.

Thank you for your help,

Jeremy.