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

open-later
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.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks