On Tue, Feb 4, 2014 at 1:05 PM, Robert R. Raiz <raizrobert@gmail.com> wrote:
I have some 300x300 png32 tiles and I noticed they take a very long time to load on websites.

The same as the mapserver files in your other message?  The uncompressed size is 360KiB, so your 270KiB compressed PNG (75% compression) is certainly a lot less well compressed than a lossy algorithm should produce.

In the other message you observed that JPEG2000 is producing a result with no discernable loss of quality, so the images are compressible by removing the stuff JPEG2000 removes.   Notice that JPEG removes the alpha channel and that immediately reduces the uncompressed size to 270KiB!

So the first comment is based on the fact that your PNG files are storing a full alpha channel - i.e. one that can store alpha values other than 0.0 and 1.0.  You should take a look at the files and see if the alpha channel really does have partially opaque pixels.  I would guess that it doesn't, or that if it does there are very few of them along the edges of the opaque areas.

You can eliminate the alpha channel  by replacing it by PNG transparency - nominate one color to be transparent, eliminate that from the opaque regions and use it to color the transparent regions.

The resultant image may compress a whole lot better than the original and, even if you take away partial alpha, the result is unlikely to look any different.

The second comment is that your data are not all the same:

The tiles can represent sat images, environment images and maps, in general.

Satellite images are photographs, often with a lot of noise.  Environment images and maps in general are either machine generated or are scans of very low color originals.  They should be treated independently.

Sat images: get rid of the noise ;-)   That's what JPEG2000 does (and JPEG for that matter.)  You can eliminate the noise using standard image processing or simply smoothing the image.  Or you could just compress it with JP2000 then try re-compressing the result with PNG!

The actual number of distinct and useful colors in a Sat image, taken with a relatively low bit-depth camera, will be much smaller than 24-bit RGB might suggest.  Even a 14-bit sensor (from a very high end camera) really only produces around 171 *useful* levels of 24-bit RGB output.  A 10-bit sensor has about 156 distinct levels and an 8-bit sensor only around 109.  The remaining levels in the 24-bit image are noise.

If you smooth the noise out image quality might increase and while there will still be 256 levels to the RGB components the result is likely to compress much better with PNG.  You could also truncate the data to 6 or 7 bits per component (dropping half or three quarters of the possible values) however this is likely to result in some observable quality loss.

WebP is certainly worth investigation for this, though I don't know whether it supports alpha with a lossy compressed RGB.

For the other data - maps - remove the alpha channel (convert it to transparency) then attempt to palette-map the image.  In practice even though a map may contain well under 256 colors a picture of the map contains intermediate colors at the edges.  You can avoid this by using 600x600 tiles with no intermediate colors and asking the browser to scale them down.  A 600x600 image with a small number of colors may compress very well compared to the corresponding pre-scaled 300x300 image and the uncompressed size is the same as your 300x300 RGBA image.

Another approach which may work for both types of image is to scale it to a 150x150 tile and ask the browser to scale it up.  Even uncompressed 150x150 meets your target and browser scaling is getting better (though many browsers still do it wrong.)  In this case you would probably want the full alpha channel, but check very carefully along the edges - this is one of the areas where many writers of scaling code make a mistake (failing to multiply by the alpha before scaling.)

Notice that the 150x150 technique is, in very crude terms, what algorithms like JPEG and JPEG2000 do; spurious spatial accuracy is eliminated from the image.  These algorithms, however, can scale by much more than a factor of 2 hence the better compression ratios (well... that's one way of looking at it.)
John Bowler <jbowler@acm.org>