Compressing TIF destroys Alpha Channel?

[jho]

Hi,
I have a problem with compressing tifs.

I use the following code to compress my tif:

convert.exe input.tif -type TrueColorMatte -compress zip output.tif

the type flag destroys my alpha channel but if I use TrueColor i have no alpha channel. I simply want the input file compressed. I used the type flag because I dont want to have a grayscaled image when i had one.

Maybe someone can help.

[fmw42]

try putting -type TrueColorMatte as the last operator

and perhaps

-channel rgba -alpha on

right after the input image

[snibgo]

What version IM? What platform? Post the URL to a file that shows the problem.

[jho]

Thanks for your help.

My version is: ImageMagick-6.5.4-8 16bit HDR

I have a 16bit TIF. With 8bit everything works. I hope I can upload a file after work.

[fmw42]

Do you need to be in IM HDRI compile mode? Perhaps there is some issue in that mode? Have you tried the same with normal Q16 (not HDRI)?

[jho]

Here is the link to the tif file: deleted

Look into the alpha channel. One sphere is alpha black. After compressing the "black alpha" sphere disappears.

I have not tried the non HDRI yet.

[Drarakel]

On my system (regular IM v6.6.3-0 Q16), I have no problem with the file. So, it seems to be limited to the HDRI version.
Can you upload your 'output.tif', too?

[jho]

Here are the links. I had to redo the input file:

deleted

[Drarakel]

Well, the alpha channel itself is not touched in your older IM version - but the regular color channels get changed (so that the blue circle is lost completely). The handling of TIF files like yours is different now (in current IM packages) - but the older 'behaviour' is ok, too.
The two TIF files here have associated alpha - which means that the regular color channels are stored as if they were flattened over a black background (a bit like "-alpha Background"). The older IM versions keep it 'associated' in subsequent convert commands - and get rid of the fully transparent colors (which is the normal state of 'associated' alpha). The newer IM versions convert such images to 'unassociated' alpha - and the fully transparent colors can be kept. (But I wonder why these colors still exist in your 'associated' TIF files in the first place.)

Solution for you:
You have to either use "convert -define tiff:alpha=unassociated input.tif output.tif" once with your files (in your old IM).
Or update to a current ImageMagick.

[jho]

Thanks for your help Drarakel.

I compiled the newest version 6.6.3. The problem is indeed the HRDI option. Without it worked.

[fmw42]

Please post a short note about this in the Bugs forum stating the command that does not work in HDRI but works in non-HDRI and point back here to this topic. It would appear that you have uncovered a bug with HDRI.

[Drarakel]

It's not a bug - and despite the first guesses, it's not related to HDRI. (Or did you test your file in IM v6.6.3-0 HDRI and IM v6.6.3-0 non-HDRI and got different results? @jho)
I had tested jho's file in my old IM v6.5.8-5 (Q16 without HDRI) and got the same result as in 'untitled_zip.tif'. The handling of 'associated alpha' TIFFs is different in older versions - compared to the current version. But as I tried to explain, both approaches seem valid to me.

[fmw42]

Drarakel has a good point. I assumed you tested in HDRI and non-HDRI in the same version of IM. Sorry for the false alarm.

[jho]

Sorry guys. I dont know why, but the image was only in 8bit. Here is a picture in 32bit with values over 1.

http://ul.to/3xt2av

I compiled the newest version as Q32, x64 and HDRI enabled. When I simply convert the picture without flags the sphere with black alpha disappears. Identify now shows me that the image has unaccociated alpha.

[fmw42]

I tried to download, but it tells me it is not an image but an application (and tries to append .html). When downloaded and I try to open it, I get an html page that says file not found.

Perhaps I am doing something wrong.