From: Robert R. R. <rai...@gm...> - 2014-02-04 21:05:28
|
Hello all, I have some 300x300 png32 tiles and I noticed they take a very long time to load on websites. I would need to reduce the size of the files without loosing quality. The ~size of a tile is 270 KiB and I would like to get to ~80. The tiles can represent sat images, environment images and maps, in general. I managed to convert a tile using imagemagick's convert option and I got a good result with jp2000. The problem is that I cannot keep the transparency. The issue is that I also need the format to support transparency as I have overlays as well.. Can anyone help me out with some suggestions? -- *Raiz Roland Robert* |
From: Robert R. R. <rai...@gm...> - 2014-02-05 09:32:19
|
Hello, Thank you Frederic for the suggestion. It seems quite good. I also managed to fix the transparency in the jpeg2000 format, so now I have 2 options. If there are any other suggestions, please let me know. Thank you, -- *Raiz Roland Robert* |
From: Robert R. R. <rai...@gm...> - 2014-02-05 10:19:07
|
Hello John, Yes, it was the same thing. I am so so bad with mailinglists..I searched for my previous mail and I could not find any trace of it so I posted another one. Sorry for that. Thank you for the clarifications. I will take my time and read it again. I must say that I managed to get great results with jp2 and webp format. I decreased the size to ~50 from ~270 and the quality is very good. Your email helped me understand how it works (the big picture). I am sure I can find a good solution in one of these two formats. -- *Raiz Roland Robert* |
From: Robert R. R. <rai...@gm...> - 2014-02-06 13:52:34
|
Back again, I have one more problem: as you said John, it works as a charm with satellite images. From 270 KiB I went to ~50 KiB and the quality of the image is very good. I just did: with ImageMagick: convert sattelite_tile.png -define jp2:rate=0.1 -define compression=JPEG2000 satellite_tile.jp2 The problem is there where I have overlays (they have transparency) and maps with just a few colors (compared to the sat image): land, water, some lines, roads and so on. In these cases, the resulted jp2 file has a bigger size. From 60 KiB it goes up to 80KiB. I read on Wikipedia, quote: "The PNG<http://en.wikipedia.org/wiki/Portable_Network_Graphics> (Portable Network Graphics) format is still more space-efficient in the case of images with many pixels of the same color". I guess this is the case. Is there a way to work around this? I would pretty much like to keep a standard and use only jp2, not two formats. -- *Raiz Roland Robert* |
From: John B. <joh...@gm...> - 2014-02-06 16:12:47
|
> > > The problem is there where I have overlays (they have transparency) and > maps with just a few colors (compared to the sat image): land, water, some > lines, roads and so on. In these cases, the resulted jp2 file has a bigger > size. From 60 KiB it goes up to 80KiB. > > Is there a way to work around this? I would pretty much like to keep a > standard and use only jp2, not two formats. > > You should look at JPEG XR. I think it does everything you want but I only just realized it existed so I'm not sure. You have two, or three, different types of data and you need the best compression so you need two different algorithms. I don't see any problem with using two formats, so long as you choose supports your user-agent handles. If you want one format you will may up with something like TIFF, which has traditionally been extended to meet all purposes and rarely works because of that (user-agents don't support 'TIFF' they support an unpredictable small number of the sub-formats). After all, you could use HTML - the IMG tag allows you to embed both PNG and JPEG ;-) In other words, I wouldn't limit yourself by aiming for a single format, it's an illusion. Other things that might work; WebP, as suggested and JPEG XR (said to support lossless compression and transparency/alpha) JPEG XR is an ISO standard (*ISO/IEC 29199-2)*, like PNG and the JPEGs. I would be interested in knowing how the lossless mode of JPEG XR performs with the maps against PNG. It may be significantly better than PNG because it treats the image in a more sensible way (as a collection of tiles rather than as a series of rows.) John Bowler |
From: Robert R. R. <rai...@gm...> - 2014-02-06 18:17:23
|
Hello, Thank you John, I will test those and will come back with some results. One problem with webp is that I could not open the files in some web browsers. As I wish to serve these tiles on the web, I need them to open in most of the web browsers. This is probably the most important part, that I forgot to mention. As you said, serving two formats is a good option. I decided today to continue tests with png and jp2. I will try to see if jpeg xr is a viable solution. I also noticed that the output of the png files is PNG32. I should be able to maybe reduce those as well (their size), especially on the tiles that have many pixels of the same color. -- *Raiz Roland Robert* |
From: John B. <joh...@gm...> - 2014-02-06 18:35:52
|
On Thu, Feb 6, 2014 at 10:17 AM, Robert R. Raiz <rai...@gm...>wrote: > I also noticed that the output of the png files is PNG32. I should be able > to maybe reduce those as well (their size), especially on the tiles that > have many pixels of the same color. > > pngcrush or optipng or something similar should be run on all PNG files intended for the web, but even then you will probably find there are too many colors (more than 256) and intermediate alpha levels. At least try explicitly running an option to reduce the number of colors in the image to 256 using a program that dithers the output where necessary. Most image processing programs should be able to do this, though how well they do it is highly variable, and what happens to the alpha channel can be unpredictable. Make sure you use something the produces an optimized palette when reducing colors - some programs use a standard palette (often described as the 'web palette') and that is unlikely to work well for your data. John Bowler |
From: Robert R. R. <rai...@gm...> - 2014-02-18 10:55:24
|
Hello, I have a few results with png8. The images still preserve a good quality, are smaller, but I wonder if I can do even better. In the link below I have 2 samples, png32 version (before) and png8 (after). Is it something more I can do to these files in order to get an even better result? Test Files: http://www.sendspace.com/file/y346v3 -- *Raiz Roland Robert* |
From: Glenn Randers-P. <gl...@gm...> - 2014-02-18 13:09:51
|
On Tue, Feb 18, 2014 at 5:55 AM, Robert R. Raiz <rai...@gm...>wrote: > Hello, > > I have a few results with png8. The images still preserve a good quality, > are smaller, but I wonder if I can do even better. > > You can shrink the files slightly by making a final pass over the image with pngcrush, to remove ancillary chunks that were inserted by ImageMagick: pngcrush -rem alla -rem vpAg png8.png png8_pc.png Run "pngcheck -v" on the before and after images to see what I mean. Glenn |
From: Frédéric K. - C. <cr...@fr...> - 2014-02-18 14:48:28
|
HI, in my experience PNGOUT gives the best compression results on PNG-8 files, if you are using Windows you can try TruePNG first as found in ScriptPNG since it tries many different ways to reorder the palette to improv filtering and compression. On my small set of test files using pngquant 2.1 to reduce PNG-32 files to PNG-8 reduced the overall data size to about 40% of the original size, running ScriptPNG on the files produced by pnquant drove them closer to 36% of the original size (PNGOUT is about 38%): http://frdx.free.fr/png_vs_webp.htm (still a draft) Regards -- Frédéric Kayser Robert R. Raiz wrote : > Hello, > > I have a few results with png8. The images still preserve a good quality, are smaller, but I wonder if I can do even better. > > In the link below I have 2 samples, png32 version (before) and png8 (after). Is it something more I can do to these files in order to get an even better result? > > Test Files: http://www.sendspace.com/file/y346v3 > > > -- > Raiz Roland Robert > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________ > png-mng-misc mailing list > png...@li... > https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
From: John B. <joh...@gm...> - 2014-02-05 00:38:06
|
On Tue, Feb 4, 2014 at 1:05 PM, Robert R. Raiz <rai...@gm...> 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 <jb...@ac...> |