Legacy ImageMagick Discussions Archive

For assembling a movie file from individual frames, ffmpeg needs all the frames to be of the same type. For example, it throws a wobbly when some PNG fles are paletted but others are not.

So I want to ensure that none are. I can do this by prefixing IM "convert" output files with "PNG24:". But this has the side effect of removing any transparency, which I need for titles, special effects and so on before they reach ffmpeg. My editing software can keep track of transparency and issue PNG24: or PNG32: as required, but it is a pain.

Is there a mechanism in IM for ensuring an output file isn't paletted? If not, can one be easily added?

("-type truecolor" doesn't prevent the output having a palette.)

try -define png:color-type=6

see http://www.imagemagick.org/Usage/formats/#png_write

if that does not work, then wait for glennrp to reply.

Setting color-typw to 6 a similar effect to the PNG32: prefix: it prevents a palette but also forces an alpha channel. I'm currently using PNG24 or PNG32, but my software has to keep track of which frames have alpha.

fmw42 wrote:try -define png:color-type=6
...
if that does not work, then wait for glennrp to reply.

That has the same effect as writing all frames as PNG32, whether they have transparency or not. It should work for you. Is it a problem if there is an all-opaque alpha channel in some of the images?

ffmpeg explicitly disallows type=6. It can't handle an alpha channel, even if it is entirely opaque.

In the normal course of events, as a frame goes through the edit process, it will sometimes acquire transparency and then lose it. ImageMagick handles that for me, so I don't need to keep track of it. But I have to ensure a frame doesn't end up at the assembly stage (ffmpeg) with a palette. The obvious way (it it was possible) would be with "-define png:NoPalette" or whatever.

Of course, I can just do a flatten before assembly. But there are 100,000 frames per hour of video, so I prefer not to.

I do not see how you can have no palette and still have transparency without using PNG32 or -define png:color-type=6.

If you use PNG24:, you get no transparency. If you use PNG8: you get transparency but also a palette. If you use PNG32, you have transparency, but no palette, but that is like -define png:color-type=6, as I understand it.

Glenn will have to respond on this as I don't see any recourse for you if you cannot use PNG32.

Perhaps I misunderstand your requirements.

IM can take care of 24 or 32 for me. It does this automagically, and that's great. Every frame ends up at ffmpeg without an alpha, exactly as it should.

The problem is, IM also "helpfully" convert some frames to paletted. ffmpeg doesn't like this. ffmpeg handles zillions of video formats, but is very limited to a few still image formats.

I want to tell IM, "Don't add a palette." I can't do this without also saying, "Add an alpha channel" or "Ensure there is no alpha channel." Doing this in a video editor, where some effects will add transparency and other will remove it, is a hassle.

fmw42 wrote:If you use PNG24:, you get no transparency.

Not strictly true. PNG24 can carry "gif-style" transparency, i.e., where one color is
named the "transparent color" and all instances of that color in the image are
fully transparent. So you cannot rely upon a PNG24 being opaque.

Glenn,

Thanks for the correction. Anthony's notes at http://www.imagemagick.org/Usage/formats/#png_formats suggest that IM cannot write such a format. Out of curiosity, if that is incorrect, how would one go about doing writing a PNG24 with binary transparency in IM?

Fred

fmw42 wrote:Glenn,
Thanks for the correction. Anthony's notes at http://www.imagemagick.org/Usage/formats/#png_formats suggest that IM cannot write such a format. Out of curiosity, if that is incorrect, how would one go about doing writing a PNG24 with binary transparency in IM?
Fred

The PNG encoder checks for the situation where a single color is transparent, and all instances of that color are transparent, and if so, writes a PNG24 with the tRNS chunk naming that one color. There's no way to specifically request that format. If all pixels and the transparent color are all gray, then it'll write a PNG with color-type 0 + tRNS. You can prevent either of those by requesting PNG32, which doesn't have the tRNS chunk. The entry on Anthony's page for PNG24 should say "possibly with binary transparency".

I haven't figured a simple way to satisfy the request to suppress indexed PNG output while allowing both PNG32 and PNG24. In fact it is the downstream application that cannot handle indexed PNG files that is broken, not ImageMagick.

glennrp wrote:The PNG encoder checks for the situation where a single color is transparent, and all instances of that color are transparent, and if so, writes a PNG24 with the tRNS chunk naming that one color.

Perhaps I misunderstand. If I do this, so that all transparent pixels are gray, I cannot find any tRNS chuck! And the type=truecoloralpha though that may be correct. So how do I tell that it is PNG24 with binary alpha and not PNG32?

convert rose: -fuzz 20% -transparent white -background gray -alpha background rose_tmp2.png

identify -verbose rose_tmp2.png


Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 70x46+0+0
Units: Undefined
Type: TrueColorAlpha
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
...
Alpha: srgba(126,126,126,0) #7E7E7E00
Rendering intent: Perceptual
Gamma: 0.45455
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: gray
Border color: srgba(223,223,223,1)
Matte color: grey74
Transparent color: none
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 70x46+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2013-03-17T20:52:20-07:00
date:modify: 2013-03-17T20:52:20-07:00
png:bKGD : chunk was found (see Background color, above)
png:cHRM : chunk was found (see Chromaticity, above)
png:gAMA : gamma=0.45454544 (See Gamma, above)
png:IHDR.bit-depth-orig : 8
png:IHDR.bit_depth : 8
png:IHDR.color-type-orig : 6
png:IHDR.color_type : 6 (RGBA)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height : 70, 46
png:sRGB : intent=0 (Perceptual Intent)
png:text : 2 tEXt/zTXt/iTXt chunks were found
signature: b0d812d8c5cc82fdba542cf4fec1af74338230438601029b8c8c8a116f95009d

I certainly wasn't saying IM was broken. If it's too difficult to implement a "don't make palettes" switch without side-effects of forcing or disabling alpha, well, that's life.

I think my video editor now correctly keeps track of what clips, effects and frames have or don't have alpha, and thus should be written as PNG24: or PNG32:.

I would now have though PNG24 has transparency at all!

If the PNG code can do binary transparency with PNG24, then that is news to me. I suppose you would need to specifically set it up that way yourself.

That is something like...
convert http://www.imagemagick.org/Usage/formats/a.png \
-channel A -threshold 50% +channel \
-background hotpink -alpha background \
png24:a_png24_boolean_alpha.png

Hmmm testing... Hey That works!!!!

But naturally it will not do it UNLESS you meet all the conditions. (boolean transparency, one transparency color)
Also that color should NOT be a foreground color (is this checked?)

PS: the above is essentially what GIF and PNG8 handling should be doing.


The above example has been added to IM Examples, Formats, PNG Output Formats
http://www.imagemagick.org/Usage/formats/#png_formats

fmw42 wrote:

glennrp wrote:The PNG encoder checks for the situation where a single color is transparent, and all instances of that color are transparent, and if so, writes a PNG24 with the tRNS chunk naming that one color.

Perhaps I misunderstand. If I do this, so that all transparent pixels are gray, I cannot find any tRNS chuck! And the type=truecoloralpha though that may be correct. So how do I tell that it is PNG24 with binary alpha and not PNG32?

convert rose: -fuzz 20% -transparent white -background gray -opaque background rose_tmp2.png

identify -verbose rose_tmp2.png

png:IHDR.bit-depth-orig : 8
png:IHDR.bit_depth : 8
png:IHDR.color-type-orig : 6
png:IHDR.color_type : 6 (RGBA)

Because of the -fuzz, your command produces a number of different nearly-white transparent colors.
Here's an extract from rose_tmp2.txt (after converting to txt):

• 58,12: (255, 96,112,255) #FF6070 srgba(255,96,112,1)
  59,12: (213, 75, 85,255) #D54B55 srgba(213,75,85,1)
  60,12: (225,170,164,255) #E1AAA4 srgba(225,170,164,1)
  61,12: (255,255,254, 0) #FFFFFE00 srgba(255,255,254,0)
  62,12: (252,255,255, 0) #FCFFFF00 srgba(252,255,255,0)
  63,12: (253,253,254, 0) #FDFDFE00 srgba(253,253,254,0)
  64,12: (254,250,245, 0) #FEFAF500 srgba(254,250,245,0)
  65,12: (255,250,249, 0) #FFFAF900 srgba(255,250,249,0)
  66,12: (254,240,244, 0) #FEF0F400 srgba(254,240,244,0)
  67,12: (234,220,219, 0) #EADCDB00 srgba(234,220,219,0)
  68,12: (239,230,219, 0) #EFE6DB00 srgba(239,230,219,0)
  69,12: (235,237,228, 0) #EBEDE400 srgba(235,237,228,0)
  0,13: ( 68, 64, 53,255) #444035 srgba(68,64,53,1)
  1,13: ( 65, 61, 51,255) #413D33 srgba(65,61,51,1)
  2,13: ( 59, 54, 45,255) #3B362D srgba(59,54,45,1)

anthony wrote: But naturally it will not do it UNLESS you meet all the conditions. (boolean transparency, one transparency color)
Also that color should NOT be a foreground color (is this checked?)

Yes, the transparent color must not also be the same color as any opaque pixel

PS: the above is essentially what GIF and PNG8 handling should be doing.

GIF and PNG8 force the conditions to be true. The other PNGnn fall back on a
format that can accomodate whatever the conditions happen to be.

The PNG tRNS chunk
doesn't have a concept of "fuzz" so I'm not sure what happens in that case. I think
a tRNS chunk will be written but only those pixels that exactly match that color will
be rendered transparent.