Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#27 OptiPNG do not know how to choose the correct color mode.

open-later
Cosmin Truta
None
3
2013-12-29
2011-08-04
adam socha
No

OptiPNG do not know how to choose the correct color mode.
Often for small files OptiPNG selects paletted mode.
This gives a worse outcome than other optimizers using RGB mode.

OptiPNG reduces pallet before compression - this is not the best solution.

OptiPNG should select all MATCHING MODES to the input image ...for more TRIALS.

I propose additional switch:

c0-6

0 - grayscale
2 - RGB
3 - paletted
4 - grayscale+alpha
6 - RGB+alpha

With this OptiPNG optimizations will be the best on the market ...better in all cases of GIF format.

Discussion

  • adam socha
    adam socha
    2011-08-04

    • priority: 5 --> 6
    • assigned_to: nobody --> cosmin
     
  • Cosmin Truta
    Cosmin Truta
    2011-09-12

    I am moving this to the Feature Requests section, and I am assigning it a lower priority.
    I do have in plans to implement a better heuristic that would automatically move, say, from palette to RGB when the image is very small. In that case, the color palette will not be such a big win, but it could be a big overhead, and reverting that would be good for compression.
    On the other hand, iterating over other variables such the color type (-c), bit depth (-b) or even the zlib window size (-zw) is work for which I do not have sufficient spare time at this moment.

     
  • Cosmin Truta
    Cosmin Truta
    2011-09-12

    • priority: 6 --> 3
    • status: open --> open-later
     
  • Ian
    Ian
    2013-10-28

    I know this is a little stale, but I came here to make the exact same suggestion. The assumption that an indexed PNG is always the best is not good. It is nearly always the wrong option for grey-scale, partial transparency, small images, and any image with low detail or variation that the filters can compress well.

    However, it isn't necessary to iterate through all colour types, since there are at most two (lossless) options for each image. Colour images only need to be compared against a palette (with a transparent colour if the alpha channel is all or nothing, or tRNS chunk when there is partial transparency). And vice-versa. A reasonable algorithm is to try to compress with the current colour type, then try with the other possibility. One exception would be with that any colour image containing only shades of grey should always be converted it into a grey-scale format first and processed accordingly.

    You could do the same with grey-scale images, but in practice these almost never improved with a palette. They are already 8-bit (sometimes plus alpha) pixels so the gains from using a palette are much more limited than for colour images with 24-32 bits per pixel. I've never seen grey-scale image with partial transparency that improved with a palette, since the additional overhead of a tRNS chunk is quite large. Perhaps this would be an option but not part of any preset.

     
  • Cosmin Truta
    Cosmin Truta
    2013-11-04

    Thank you, Ian. You are correct, an indexed PNG isn't always the best. For example, the RGB-to-palette reductions do not happen if a simple heuristic (comparing the uncompressed RGB image size vs. the uncompressed paletted image size plus palette size) says so.

    There is, however, a current design limitation in the image reductions that prevents expanding from palette to RGB(A). Nuking the palette is easy, but growth of image rows, 3 times (for palette-to-RGB) or 4 times (for palette-to-RGBA), isn't done yet.

     
  • Ian
    Ian
    2013-11-04

    I suspect it is impossible to produce a heuristic which can predict which colour type will produce the smallest file. RGBA images with little detail and few colours compress to virtually the same size as the same image represented from a palette, but there is no way for a heuristic to predict this.

    To add more information for any eventual solutions, I have manbaged to produce a grey-scale image with partial transparency that is smaller when represented from a palette (plus a tRNS chunk) although it took some effort. It is almost impossible for grey-scale without transparency to work better from palette since they have reduced bit depth but without the overhead of an explicit palette. Just possibly when the allowed bit depth doesn't quite fit the required colours, for example 17 colours which would require an 8-bit greyscale chunk but only a small palette, The situation is difficult to analyse because optiping does not reduce the bit depth below 8 on grey-scale images and no other tools really optimise this type of file optimally.

     
  • Cosmin Truta
    Cosmin Truta
    2013-12-29

    Ian, would it be possible for you to please upload that grayscale image with partial transparency that you produced? Although I don't suppose that an implementation would go to such great lengths to accommodate corner cases like this one, I would, nonetheless, be interested in seeing this example.

     
  • Ian
    Ian
    2013-12-29

    I don't have the original image, but I'll try to recreate it. It was large, with a very limited number of colours, and I think a wide range of transparency values.