Converting a transparent TIFF to PNG loses pixels

[sacha]

I'm using ImageMagick 6.8.9-2 (which exhibits the same behaviour as 6.7.7-7, the oldest version I tested), built from source on Linux. The problem was reported in a system that uses 6.7.1 on Windows (installed using the official installer, i.e., it's probably nothing to do with how I'm building from source).

I have a problematic TIFF; I'm not sure what's different about it, but I include the output of identify -verbose below (sans IPTC etc). It's a copyrighted image, so if the clues aren't in the output below I'll see if I can get a release for testing.

The image is of a statue on a plain background. I'm using the display command from IM 6.2.8 to view it (the version installed with the OS; my builds of IM don't have X11 support).

If I convert the image to JPEG, the JPEG output looks fine:

Code: Select all

convert test.tif test.jpg

If I convert the image to PNG, the statue is missing, and I see a checkerboard pattern where it should be (i.e. those pixels are transparent). (Strangely, the miniature guide image that the display command pops up looks correct, but the full size image does not.)

However it doesn't seem to be about PNG; if I scale the image before converting to JPEG, the statue is also lost:

Code: Select all

convert test.tif -geometry 300x300 test.jpg  # statue is now a black silhouette

I can work around it for the time being by saving to JPEG and then scaling; if anyone has a better workaround, I'm all ears - even if we can get a fix into a future ImageMagick for this, it'd be convenient to have a solution for our older deployed versions.

Code: Select all

Image: test.tif
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 5455x7800
  Type: TrueColorMatte
  Endianess: MSB
  Colorspace: RGB
  Channel depth:
    Red: 8-bits
    Green: 8-bits
    Blue: 8-bits
    Alpha: 8-bits
  Channel statistics:
    Red:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 107.753 (0.422563)
      Standard deviation: 48.7701 (0.191255)
    Green:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 107.246 (0.420573)
      Standard deviation: 49.1459 (0.192729)
    Blue:
      Min: 0 (0)
      Max: 255 (1)
      Mean: 110.313 (0.4326)
      Standard deviation: 48.5394 (0.190351)
    Alpha:
      Min: 255 (1)
      Max: 0 (0)
      Mean: 146.287 (0.573673)
      Standard deviation: 125.801 (0.493338)
  Alpha: (205,208,213,255)        #CDD0D5FF
  Colors: 173943
  Rendering intent: Undefined
  Resolution: 300x300
  Units: PixelsPerInch
  Filesize: 1.6e+02mb
  Interlace: None
  Background color: white
  Border color: #DFDFDF00
  Matte color: grey74
  Page geometry: 5455x7800+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: None
  Orientation: TopLeft
  ...
  Software: Adobe Photoshop CS4 Windows
  ...

[fmw42]

Nothing stands out to me. Check your version of libtiff and libpng and see if there are newer versions and update those if need be.

If that fails, I think you will need to provide the tiff image for the developers to investigate further. You can send it via PM or external email to one of the developers, if that kind of privacy is needed.

I will let one of the developers reply provide the exact PM or email address.

[snibgo]

It isn't clear what you want. To make the image opaque? To make the background transparent?

I notice:

Code: Select all

    Alpha:
      Min: 255 (1)
      Max: 0 (0)

These are the wrong way round. Was this from an old version of IM?

Perhaps the problem is confusion between transparency and opacity. I believe that old versions of IM had this confusion. It might be curable with "-channel A -negate +channel" to reverse the meaning, or "-alpha off" to make the image opaque.

Can you post the complete contents of "identify -verbose"? Replace any confidential data with "XXXXXXXXX".

(I'm not a developer, and sending the image to the developers may be needed.)

[sacha]

The previous identify output was indeed from an old ImageMagick as you suspected (6.2.8 from CentOS 5.10). Below is the output from 6.8.9-2, which reverses the Alpha min/max.

Although the post subject references PNG, that's mainly because converting to PNG was the easiest way to reproduce the fault. What I'm ultimately trying to work out is why:

Code: Select all

convert test.tif -geometry 300x300 thumb.jpg

(which currently yields an opaque background with a statue-shaped hole in the middle) doesn't yield an image that is visually the same as

Code: Select all

convert test.tif test.jpg
convert test.jpg -geometry 300x300 thumb.jpg

(which currently yields an opaque background with an opaque statue on it, the desired output).

Using the -channel A -negate +channel flags suggested inverts the problem, as you might expect; I get an opaque statue on a missing (transparent in PNG, blank in JPEG) background.

Using -alpha off gives the desired result:

Code: Select all

convert test.tif -alpha off -geometry 300x300 thumb.jpg

looks as expected. I'm not sure I can apply it generally; I'd imagine other TIFFs may start rendering incorrectly if I do.

I've been given permission to release the image for analysis; I'd prefer not to post it publicly though. Also it's fairly huge, but if I scale the TIFF down, the scaled TIFF exhibits the same behaviour, so I should be able to email it.

Identify output:

Code: Select all

Image: test.tif
  Format: TIFF (Tagged Image File Format)
  Mime type: image/tiff
  Class: DirectClass
  Geometry: 5455x7800+0+0
  Resolution: 300x300
  Print size: 18.1833x26
  Units: PixelsPerInch
  Type: TrueColorAlpha
  Base type: TrueColor
  Endianess: MSB
  Colorspace: sRGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
    alpha: 8-bit
  Channel statistics:
    Red:
      min: 0 (0)
      max: 255 (1)
      mean: 107.753 (0.422563)
      standard deviation: 48.7701 (0.191255)
      kurtosis: -0.870765
      skewness: 0.643677
    Green:
      min: 0 (0)
      max: 255 (1)
      mean: 107.246 (0.420573)
      standard deviation: 49.1459 (0.192729)
      kurtosis: -0.844846
      skewness: 0.65519
    Blue:
      min: 0 (0)
      max: 255 (1)
      mean: 110.313 (0.4326)
      standard deviation: 48.5394 (0.190351)
      kurtosis: -0.770726
      skewness: 0.670742
    Alpha:
      min: 0 (0)
      max: 255 (1)
      mean: 146.287 (0.573673)
      standard deviation: 125.801 (0.493338)
      kurtosis: -1.90738
      skewness: 0.299661
  Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 108.506 (0.425516)
      standard deviation: 75.7889 (0.297211)
      kurtosis: -0.642203
      skewness: 0.478855
  Alpha: srgba(205,208,213,0)   #CDD0D500
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Background color: white
  Border color: srgba(223,223,223,1)
  Matte color: grey74
  Transparent color: none
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 5455x7800+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: None
  Orientation: TopLeft
  Properties:
    date:create: 2014-06-04T16:59:03+01:00
    date:modify: 2014-06-04T16:37:54+01:00
    dc:format: image/tiff
    exif:ColorSpace: 65535
    exif:ExifVersion: 0220
    exif:NativeDigest: 36864,40960,40961,37121,37122,40962,40963,37510,40964,36867,36868,33434,33437,34850,34852,34855,34856,37377,37378,37379,37380,37381,37382,37383,37384,37385,37386,37396,41483,41484,41486,41487,41488,41492,41493,41495,41728,41729,41730,41985,41986,41987,41988,41989,41990,41991,41992,41993,41994,41995,41996,42016,0,2,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,22,23,24,25,26,27,28,30;45EFCA6B5348E33FA8C494A0A4B50974
    exif:PixelXDimension: 5455
    exif:PixelYDimension: 7800
    Iptc4xmpCore:CiAdrCity: XXX
    Iptc4xmpCore:CiAdrCtry: XXX
    Iptc4xmpCore:CiAdrExtadr: XXX
    Iptc4xmpCore:CiAdrPcode: XXX
    Iptc4xmpCore:CiAdrRegion: XXX
    Iptc4xmpCore:CiEmailWork: XXX
XXX
    Iptc4xmpCore:CiTelWork: XXX
XXX
    Iptc4xmpCore:CiUrlWork: XXX
    photoshop:AuthorsPosition: XXX
    photoshop:CaptionWriter: XXX
    photoshop:City: XXX
    photoshop:ColorMode: 3
    photoshop:Country: XXX
    photoshop:Credit: XXX
    photoshop:DateCreated: 2014-05-19
    photoshop:EmbeddedXMPDigest: 00000000000000000000000000000000
    photoshop:ICCProfile: Adobe RGB (1998)
    photoshop:Instructions: IMAGE IS COPYRIGHTED. NO REPRODUCTION RIGHTS GRANTED. 
    photoshop:LegacyIPTCDigest: 265171117A8F70DEAB19B4FD1302AE5E
    signature: ebca6a6bc92f16d9084e8f44d1fdb5eecbb83f6d7bff6229241cc0ce41b0bda2
    tiff:alpha: unassociated
    tiff:artist: XXX
    tiff:Compression: 1
    tiff:copyright: XXX
    tiff:endian: lsb
    tiff:ImageLength: 7800
    tiff:ImageWidth: 5455
    tiff:NativeDigest: 256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;B5A81E74396D39090C9CB26F2D4581D4
    tiff:Orientation: 1
    tiff:photometric: RGB
    tiff:PhotometricInterpretation: 2
    tiff:PlanarConfiguration: 1
    tiff:ResolutionUnit: 2
    tiff:rows-per-strip: 1
    tiff:SamplesPerPixel: 4
    tiff:software: Adobe Photoshop CS4 Windows
    tiff:timestamp: 2014:06:03 13:15:08
    tiff:XResolution: 3000000/10000
    tiff:YResolution: 3000000/10000
    xmp:CreateDate: 2014-05-19T12:53:01+01:00
    xmp:CreatorTool: Adobe Photoshop CC (Macintosh)
    xmp:MetadataDate: 2014-06-03T13:15:08+01:00
    xmp:ModifyDate: 2014-06-03T13:15:08+01:00
    xmpMM:DocumentID: 402D3D8D0181D7EEFFEF8BA00F52EE0E
    xmpMM:InstanceID: xmp.iid:A2D7E5B908EBE311823ACFD353854549
    xmpMM:OriginalDocumentID: 402D3D8D0181D7EEFFEF8BA00F52EE0E
    xmpRights:Marked: True
  Profiles:
    Profile-8bim: 6396 bytes
    Profile-icc: 560 bytes
    Profile-iptc: 568 bytes
      unknown[1,0]: 
      City[1,90]: 0x00000000: 254700                                        -%
      City[1,90]: 0x00000000: 254700                                        -%
      unknown[2,0]: 
      Caption Writer[2,122]: XXX
      Special Instructions[2,40]: IMAGE IS COPYRIGHTED. NO REPRODUCTION RIGHTS GRANTED. 
      Byline[2,80]: XXX
      Byline Title[2,85]: Photographer
      Credit[2,110]: XXX
      Created Date[2,55]: 20140519
      City[2,90]: XXX
      Country[2,101]: XXX
      Copyright String[2,116]: XXX
      Created Time[2,60]: 125301+0100
      Custom Field 9[2,208]: XXX
      Custom Field 10[2,209]: XXX
      Custom Field 11[2,210]: XXX
      Custom Field 12[2,211]: XXX
      Custom Field 13[2,212]: XXX
      Custom Field 14[2,213]: XXX
      Custom Field 15[2,214]: XXX
      Custom Field 16[2,215]: XXX
    Profile-xmp: 20288 bytes
  Artifacts:
    filename: test.tif
    verbose: true
  Tainted: False
  Filesize: 170.2MB
  Number pixels: 42.55M
  Pixels per second: 16.82MB
  User time: 2.500u
  Elapsed time: 0:03.529
  Version: ImageMagick 6.8.9-2 Q16 x86_64 2014-06-04 http://www.imagemagick.org
 

[fmw42]

convert test.tif -geometry 300x300 thumb.jpg

-geometry is a setting not an operator, so it does nothing here. you need -resize or -thumbnail in place of -geometry

[snibgo]

JPG files don't have an alpha channel, of course.

I would expect ...

Code: Select all

convert test.tif -geometry 300x300 thumb.jpg
convert test.tif thumb2.jpg

... to give the same reslts. "-geometry" by itself should have no effect, but as no one uses it by itself, perhaps it has a bug that hasn't been noticed.

Your identify output says it has an alpha channel, but the alpha is unassociated. Judging by samples I have seen on these forums, this flag usually means the alpha channel defines a background that is to be made transparent for some purposes. IM doesn't care about the value of this flag.

Modern versions of IM can:

Code: Select all

identify -quiet -format "%[tiff:alpha]" transparent.tif

This returns nothing or "associated" or "unassociated". You may find that testing this in a script, and setting "-alpha off" for "unassociated", does what you want.

[sacha]

Apologies for -geometry. (I'm not really an IM command line user, I program using the IM APIs, and when things go wrong, I try to find the command line equivalents to see whether convert behaves as expected and it's my use of the API that's wrong.)

FWIW I've verified that -geometry 300x300 and -resize 300x300 produce output that is byte identical:

Code: Select all

% convert test.tif -geometry 300x300 thumb.jpg
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory'.
% convert test.tif -resize 300x300 thumb2.jpg
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory'.
% cmp thumb.jpg thumb2.jpg 
%

So perhaps that's a separate bug to reported elsewhere.

In any case thanks for the tip about unassociated alpha. I'll see if that can be used to work around the fault for the moment.

I've uploaded the image and some outputs to ftp://ftp.ssl.co.uk/sacha/

The images were produced as follows:

Code: Select all

% convert -version
Version: ImageMagick 6.8.9-2 Q16 x86_64 2014-06-04 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC
Delegates: fontconfig jng jpeg png tiff zlib
% convert test.tif test.jpg
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/850.
convert: test.tif: unknown field with tag 40961 (0xa001) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/850.
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/850.
% convert test.jpg -resize 300x300 thumb_from_jpeg.jpg
% convert test.tif -resize 300x300 thumb_from_tiff.jpg
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/850.
convert: test.tif: unknown field with tag 40961 (0xa001) encountered. `TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/850.
convert: test.tif: wrong data type 7 for "RichTIFFIPTC"; tag ignored. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/850.

I would expect thumb_from_jpeg.jpg and thumb_from_tiff.jpg to (a) look the same, and (b) preferably look like thumb_from_jpeg.jpg.

Or if you prefer: I would expect the output of this sequence of API calls:

Code: Select all

def main () {
    local w = NewMagickWand()
    MagickReadImage(w, "test.tif")
    MagickScaleImage(w, 200, 200)
    MagickWriteImage(w, "thumb_from_tiff.jpg")
    DestroyMagickWand(w)
}

to be visually comparable to the output of:

Code: Select all

def main () {
    local w = NewMagickWand()
    MagickReadImage(w, "test.tif")
    MagickWriteImage(w, "test.jpg")
    DestroyMagickWand(w)

    w = NewMagickWand()
    MagickReadImage(w, "test.jpg")
    MagickScaleImage(w, 200, 200)
    MagickWriteImage(w, "thumb_from_jpeg.jpg")
    DestroyMagickWand(w)
}

[snibgo]

Viewing test.tif with Gimp and Windows Photo Viewer, we see a transparent statue against an opaque background, which is the opposite of what is normally desired. Gimp shows that statue pixels have alpha values of zero, with maximum at the background (aliased at the edge of the statue). Again, the opposite of what we might want. As a general rule, modern software treats alpha as opacity not transparency. So zero means a pixel is transparent.

After a simple conversion:

Code: Select all

convert test.tif t.tif

... Windows Photo Viewer shows all pixels opaque, but Gimp still shows the statue as transparent.

For t.tif, "identify verbose" doesn't show any significant change. exiftool says that "IFD0:ExtraSamples='Unspecified'" has changed to "IFD0:ExtraSamples='Unassociated Alpha'".

Code: Select all

convert test.tif -alpha off tao.tif

... removes the alpha channel, and all pixels are opaque.

Code: Select all

convert test.tif -channel A -negate +channel taneg.tif

taneg.tif shows as opaque in Windows Photo Viewer, but Gimp shows an opaque statue against a transparent background.

Code: Select all

convert test.tif -channel A -negate +channel -define tiff:alpha=associated tanega.tif

Windows Photo Viewer and Gimp both show an opaque statue against a transparent background. You could then flatten the image against a white background, if you want.

Sorry, I don't know the equivalent with an API.

[sacha]

Thanks for your input guys.

I've removed the TIFF for the moment, but left the other output referenced in this thread. If any developers want to pursue the fault, give me a shout, I can re-supply the TIFF.