#2 Dirty transparency removal


This patch clears RGB components of RGBA pixels that have alpha = 0. This doesn't visually alter files in any way, since these pixels are completely transparent anyway, but greatly improves compressibility of images that had transparent areas "dirty".


  • porneL

    porneL - 2009-08-04

    Oops. Forgot to log in. Contact me at *mynickname* @ *mynickname* .net

  • Cosmin Truta

    Cosmin Truta - 2009-08-10

    Hi, and thank you very much for your contribution. It is clear that you put a lot of care and effort in developing it, and I will consider it, as a concept, as part of some future OptiPNG version.

    Unfortunately, I cannot just integrate it as is; at the very least, I cannot let this "dirty alpha cleanup" operation run by default, because this would be in contradiction with OptiPNG's guarantee of losslessness. Future versions, starting with version 0.7, will hopefully allow the user to control the degree of loss, it should be possible to strip things like metadata or the alpha channel, so this idea could come in handy as well. But all these can only be done at the user's request, and it must be assumed that the user knows well what he or she is doing.

    I tried to read the article that you forwarded to me in the email, but, sorry, I can't read russian :-) My impression, judging from the images, though, is that the author is having a crude attempt to premultiply the alpha channel. According to ISO-PNG, however, PNG's alpha is non-premultiplied, and it was chosen to be that way for good reasons. (ISO-PNG lacks the rationale section, per the ISO requirements, but you may read that rationale in one of the earlier drafts; for example, here:

    Another problem that I will have to solve (not too difficult, but it needs to be considered, nonetheless) is that the option that strips the alpha channel and the option that wipes the contents underneath 0% alpha, are mutually exclusive. In other words, I should have an explicit check for the (not-yet-existent) options "-erase alpha" and "-erase dirty-alpha", I can't allow them both.

    In spite that I cannot integrate your contribution in OptiPNG right away, I am very grateful for it. Thanks again!

    Best regards,

  • Cosmin Truta

    Cosmin Truta - 2009-08-10
    • status: open --> open-postponed
  • porneL

    porneL - 2009-08-10

    I understand your goal of losslessness. I'd add this option to pngcrush instead, but its source code is unreadable spaghetti mess I can't work with :)

    I don't understand Russian either, but it's understandable after automatic translation. There's English copy of this article: smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/#dirty-transparency

    It's not premultiplying of alpha channel. It's change of RGBA pixels from XXX0 to 0000 (where X is any value). This loses only information that was completely invisible anyway, and it's perfectly valid in PNG.

  • Cosmin Truta

    Cosmin Truta - 2009-08-16
    • status: open-postponed --> wont-fix-rejected
  • Cosmin Truta

    Cosmin Truta - 2009-08-16

    Hello, pornel,

    I am sorry I am rejecting this patch. I initially set the resolution to "postponed", thinking I will do it later, but, after thinking about it more carefully, I consider it altogether a bad idea for OptiPNG.

    However, do not let yourself be deterred by my decision. You don't necessarily need to put this code in OptiPNG or pngcrush, especially given that ImageOptim works by calling several tools in a chain. If you still want to go ahead with this technique, I suggest you write your own tool, in the same manner as pngrewrite or pngquant, and have it accepted by the PNG community first. (For example, I incorporated the image reductions by taking ideas out of pngrewrite.)

    Back to our issue, it's not just an empty claim of losslessness, and, even if you say it's not about doing premultiplied alpha (I only said it's a crude form of premultiplied alpha, in which you multiply the RGB samples by 0 when A=0), all the disadvantages mentioned in the PNG spec link that I gave to you still apply. Although it's desirable for a web browser to recognize the transparency, it's not mandatory. Internet Explorer up to version 6 ignores the alpha channel by default, and, while inconvenient, it's entirely PNG-spec compliant. (For that reason, even applications that only display the red channel, or only the blue channel, or only the green channel, etc., are also compliant. The spec only mandates how to decompress and interpret the chunk data, but any post-processing that takes place before rendering is entirely at the decoder's discretion.)

    It's one thing when the user has control on what to erase, and what background color to substitute, and how to adjust the image so that it shows up well, regardless what browser it's used for display (as it's shown in that web page using Photoshop). It's an entirely different thing when the user has a browser that ignores the alpha channel (e.g. IE6, or any browser that allows the user to disallow the processing of the alpha channel). By using your method, which, by default, creates a black "erased" region, the web author that uses this risky optimization technique is shooting himself or herself in the foot, because his or her visitors will scoff at that ugly-looking image!!

    I am sorry I don't have a Mac, so I cannot try your application. I would like, however, to ask you to do the following (if you aren't doing it already): disable this kind of optimization by default, and only enable it at the user's request. Also, make sure you provide a confirmation dialog box or something similar, in which the user confirms that s/he is aware of the risks and s/he knows very well what s/he's doing! Otherwise, the user will trust your program, thinking that all optimizations performed are "safe", and have no idea they will end up having ugly-looking that will annoy the web surfers who use web browsers that don't display the alpha channel...

  • Cosmin Truta

    Cosmin Truta - 2009-08-16

    One more thing:

    Compression-wise, this method has to be carefully analyzed as well. It's one thing when you erase wide areas of contiguous alpha=0 pixels, and that helps you with compression; but it's another thing when this is done blindly on any image and you apply it, say, on images that have "transparent salt" (very small areas of transparent pixels surroundend by large areas of non-transparent pixels). For this kind of images, your method will cause a great statistical disturbance that, in the end, will ruin the compression! I expect the effect to be even worse when delta filtering is applied, because the near-zero filtered samples in non-transparent areas will alternate with very large absolute values that appear at the border of transparency areas. zlib doesn't handle this kind of input very well.

    All these problems that I am mentioning do have solutions, but they need to be investigated in detail and understood thoroughly. For example, one thing to do is set up a web page with tests that show how compression increases or decreases after applying your method, and how the images look with *and* without the alpha channel. One possible solution is to replace all samples where A=0 with a color that can be reasonably considered as "background", instead of just RGB=000. The presence of a bKGD chunk might help, but you cannot fully rely on that, as bKGD is rarely present. Another possibility is to use samples that minimize the delta-filtered values, instead of that RGB=000 which undesirably increases the delta-filtered values.

    I hope this helps.

    Best regards,

  • Cosmin Truta

    Cosmin Truta - 2009-08-17
    • status: wont-fix-rejected --> open-rejected
  • Matthew

    Matthew - 2009-08-23

    @pornel: for what it's worth, there's also another potential way to improve compession using dirty transparency removal:

    For an image with binary (on/off) transparency, a careful choice of transparent color will enable the image to be stored without a full alpha chanel, but just using a tRNS chunk.

    Of course, the requirement for this is that the color be unused in opaque regions, which may take some finding, or may not even exist - which is possible in a 16777217-pixel RGB-8 image, or a 257-pixel grayscale-8 image, or even just a 3-pixel grayscale-1 image.

    So, the resulting color (if one can be found) may be unpredictable, in which case a basic algorithm such as "closest match to x", or "lowest RGB value" may be desirable. I'm not sure there are any consistently fast/memory-efficient algorithms for finding unused colors, but it might be something worth thinking about.

    One case such an optimisation would be useful is window screenshots with rounded corners that have transparency behind (e.g. Windows XP). In images like these, 000 and FFF are often already taken.

  • Mechanical snail

    I feel the IE6 issue is now moot, since Microsoft has ended mainstream support and high-profile websites are phasing out support.

    Regardless, dirty transparency removal should be disabled by default since some PNGs care about this hidden color information (see http://en.wikipedia.org/wiki/File:Ipu.png\). I can also imagine scientific visualization applications that treat all 4 channels as data.

  • Ramona Truta

    Ramona Truta - 2012-03-05
    • status: open-rejected --> closed-rejected
  • Cosmin Truta

    Cosmin Truta - 2012-03-05

    Closing patch. Although a w3c-compliant web browser should hide the pixels
    whose alpha channel is 0%, this is not generally the case for
    general-purpose, PNG-compliant image processors or viewers. These programs
    may decide, very legitimately, to discard the alpha channel (as well as any
    other channel, for that matter), in which case the loss appears obvious,
    and, in many cases, quite ugly.

    In the previous note, the-snail correctly mentioned scientific
    visualization applications, which would also be affected by the loss of in
    valid image channels.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks