Howdy I've had some thoughts and wondered if anyone wanted to collaborate? (Just some first ideas (of many) lifted from my blog)... Lossy magic (png-vslp) Part I Lossless optimization of png's can achieve reasonable savings, however, substantial compression gains can be made with very slight lossy processing (VSLP). Increasingly png images are produced from vector artwork or touched up in photo editors, introducing common artefacts that bloat up png files but add minimal visual information. Principally I'm talking about excessive palette data and in this context I use this as short-hand for all 4 channels: RGB and (most significantly) alpha. Minimizing this obviously reduces the palette size and may allow small images to be saved with just a 256 palette at only 8bits per pixel (vs. 32bpp). But reducing the palette also greatly improves the compressibility of the file, since we have larger areas of equal colour and alpha values, which is nice for the pre-filters and deflate to crunch on. There are many programs out there for producing lossy pngs, but they tend to discard excessive information and the results are visually obvious. To clarify, I'm talking about removing redundant data that will not be visible in the vast majority of situations (hence VSLP).
Removing this data by hand is pretty time consuming, so I hope the process can be automated by using ImageMagick or some custom program (any volunteers?). I've not had much success using this software, so the following is my list of Tweaks for VSLP which someone might want to script. Note, the first assumption (and significant saving) is that we will only deal with pngs using 8 bits per channel; all 16pbc images will be downsampled. The following convention is used: (Suggested variable name and [default value]) ... 1. Tweak alpha transparency data. It's the decent alpha capabilities that we all love about pngs, but easy gains with least visual impact can be made by tweaking here. The human eye is not so good at judging transparency and yet we preserve high fidelity when scaling and re-touching images in photo editing software. I think reducing alpha data should be the first target, with highest yield vs visual impact.
1.1. Transparent threshold (alpha_threshold_trans [2%]) Below a certain level of transparency the human eye cannot pick up on the subtle effect on the background colour, so we can set that alpha value to fully transparent. This is clearly dependent on the contrast between the background and foreground colours being blended. I have found that below 2% (i.e. A<=5, for 0-255) represents a reasonable threshold point. Below this threshold we set A=0, above the threshold we leave A=A. Example: Scaling an image with full alpha from 128 to 32 pixels will produce many pixels with an A=1 which is not visible or desireable, but may significantly hurt compression.
1.2. Opaque threshold (alpha_threshold_opaq [98%]) An identical case as above can be made for the threshold at which pixels appear effectively opaque. Again from experience, it would seem that near to 2% fully opaque there is little point preserving alpha data (i.e. A>=250, for 0-255) . Above this threshold we set A=255, below A=A. Example as above.
1.3. Transparent colour (alpha_color [1]) Thresholding alpha values may well reduce the palette and transparency tables, but it yields an additional benefit. Often images contain redundant colour data in fully (/highly) transparent regions which may be useful during editing but are not required for the finished image. This can be removed by setting all fully transparent pixels (A=0 after thresholding), to a common background colour. Sensible colour options are: 0] leave colours as they are; [1] set to black [RGB=0,0,0]- which is highly efficient for most images; [2] Pick the most highly used colour in the image (often white or black).
I have numerous other 'VSLP' tweaks that I routinely apply, and will write them up in time. Cheers.
Edited by ace_dent at
counting_pine at
Re: Pseudo-lossless (lossy) pre-processing
If we're talking about images converted from vector graphics, then there's likely to be a lot of anti-aliased edges. Places like that are probably good place for optimisation, For palette images, they would be the best place to look at quantisation. For full-colour, unfiltered images, such pixels could probably be downsampled, so the set of colour values used is lowered.
I'm not sure what the best strategy would be for filtered images, but there are probably many possibilities if you keep in mind the gradients of the four (eight?) adjacent colour values. As long as it lines up approximately with them, then there's probably a lot of flexibility in what such pixel values could be.
Another possibility for transparent areas on filtered images, is to set the colour so that the filtered difference is zero. For best effect though, this would have to be done at the same time as chosing the row filters, and it would probably only save you from having to compress a single edge (the bottom/right one).
There's only so much potential when compressing the alpha channel. For example, if you have solid white with alpha on solid black, the alpha channel will behave like grayscale, so will have the same compression possibilities. Of course, that's a bit of an extreme case, but it's probably quite hard to probably detect and account for. Something like that may have to be controlled on a per-image basis.
I can see potetential for more alpha-related optimisation though - the more transparent a pixel, the more freedom you have to play with its value. I couldn't say what the best way to use that would be, though...
Edited by counting_pine at
David at
I have been looking into this over the past few weeks myself.
The area of quantization is somewhat active in academic research these days. It might be worth looking into what has been published. Very often the papers don't consider transparency data, but I would think that most could be extended to handle a fourth channel, and indeed some already have: see http://pngnq.sourceforge.net/
Much of the work centers on emergent adaptive approaches like neural networks or genetic algorithms (and even both simultaneously).
Some researchers try to make a distinction between error and accuracy, but I see these as more or less the same thing, only developing a system based on (perceptual) accuracy is really just defining your error calculation with a bias that takes into account what the eye can perceive.
There does seem to be a big gap between the published works and what the typical image editor does. Photoshop doesn't even process transparency data correctly when quantizing: it blasts the transparency info as part of the process.
I'm not announcing any products here, but this would make a very nice complement to PNGOUT. It has been a while since I coded up a GA, but I did have the fortune of taking a class in emergent computation with John Holland himself when I was getting my degree.