If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#76
|
|||
|
|||
Image formats
On 17/02/2020 05:37, Paul wrote:
I tried this test too. I was shocked to discover that PNG 0 was 70MB, PNG 1 (slight compression) was 37MB, and PNG 9 (max compression) was 37MB. In other words, a picture from a camera, there was only one level of lossless compression available in a sense. It makes the compression level setting (almost) worthless. PNG compression is a bit odd, the higher number doesn't always give the best compression, though it usually does. When I'm using a PNG on a website I often run it through optipng to find the compression parameters that make the smallest file. http://optipng.sourceforge.net/ The JPG it was made from was maybe 6-7MB or so. JPG can have quite high compression, and the ratio of the sizes isn't that high of a compression by JPG standards. Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. The secret weapon for JPG is the turbojpeg library. It uses SSE, AVX, and/or multiple cores. And while there is IDCT acceleration (inverse discrete cosine transform) available from video cards, I don't know whether that fits into viewing or not. When I tried JPG in Irfanview for example, it appeared "instantly" on the screen. Whereas for PNG, I doubt those sorts of acceleration are on offer. One thing that was weird, was when I saved out a PNG with "zero" compression, the output step was still slow. And someone did think of parallelizing PNG compression. He views it as the same problem as PIGZ (which is a parallelized GZIP compressor, I think runs on two cores at least). Maybe the idea is to break a PNG file down into multiple IDAT blocks, and do a compression for each one on a different core. The blog entry is from August 30, 2018. https://brionv.com/log/2018/08/30/pa...-a-png-anyway/ It's amazing how slowly parallization passes into software lore. Even PIGZ (a "prototype of parallelization") did not get picked up in any substantial way. (I don't think Igor included that in 7ZIP for example, only 7Z got accelerated.) If you want GZIP compression, it's still largely a "single-core world". Maybe it's just that good or best compression ratio sells both new compression methods and new compression software. While parallelized compression is usually a lot faster it doesn't quite compress as well as a single threaded implementation, though typically it's close. I use this archiver a lot and it can parallelize several of the most intensive compression methods it supports: https://www.powerarchiver.com/ -- Brian Gregory (in England). |
Ads |
#77
|
|||
|
|||
Image formats
Brian Gregory wrote:
Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. TIFF files support various types of compression, including JPEG. |
#78
|
|||
|
|||
Image formats
In article , Andy Burns
wrote: Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. TIFF files support various types of compression, including JPEG. however, they're nearly always uncompressed. |
#79
|
|||
|
|||
Image formats
Andy Burns wrote:
Brian Gregory wrote: Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. TIFF files support various types of compression, including JPEG. The Wikipedia TIFF article lists the 'Usage and support' of JPEG compression as 'Uncommon', so it's probably not wise to expect this to work for most software. 'TIFF' (- '2.4 TIFF Compression Tag) https://en.wikipedia.org/wiki/TIFF#TIFF_Compression_Tag (FWIW, I happen to use TIFF with CCITT Group 4 fax encoding for black-and-white scanned images of handwritten text. I don't remember if my (Epson) scanner software defaulted to that format or that I got the idea elsewhere.) |
#80
|
|||
|
|||
Image formats
On 2/17/20 3:30 PM, this is what Brian Gregory wrote:
On 17/02/2020 05:37, Paul wrote: I tried this test too. I was shocked to discover that PNG 0 was 70MB, PNG 1 (slight compression) was 37MB, and PNG 9 (max compression) was 37MB. In other words, a picture from a camera, there was only one level of lossless compression available in a sense. It makes the compression level setting (almost) worthless. PNG compression is a bit odd, the higher number doesn't always give the best compression, though it usually does. When I'm using a PNG on a website I often run it through optipng to find the compression parameters that make the smallest file. http://optipng.sourceforge.net/ The JPG it was made from was maybe 6-7MB or so. JPG can have quite high compression, and the ratio of the sizes isn't that high of a compression by JPG standards. Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. The secret weapon for JPG is the turbojpeg library. It uses SSE, AVX, and/or multiple cores. And while there is IDCT acceleration (inverse discrete cosine transform) available from video cards, I don't know whether that fits into viewing or not. When I tried JPG in Irfanview for example, it appeared "instantly" on the screen. Whereas for PNG, I doubt those sorts of acceleration are on offer. One thing that was weird, was when I saved out a PNG with "zero" compression, the output step was still slow. And someone did think of parallelizing PNG compression. He views it as the same problem as PIGZ (which is a parallelized GZIP compressor, I think runs on two cores at least). Maybe the idea is to break a PNG file down into multiple IDAT blocks, and do a compression for each one on a different core. The blog entry is from August 30, 2018. https://brionv.com/log/2018/08/30/pa...-a-png-anyway/ It's amazing how slowly parallization passes into software lore. Even PIGZ (a "prototype of parallelization") did not get picked up in any substantial way. (I don't think Igor included that in 7ZIP for example, only 7Z got accelerated.) If you want GZIP compression, it's still largely a "single-core world". Maybe it's just that good or best compression ratio sells both new compression methods and new compression software. While parallelized compression is usually a lot faster it doesn't quite compress as well as a single threaded implementation, though typically it's close. I use this archiver a lot and it can parallelize several of the most intensive compression methods it supports: https://www.powerarchiver.com/ optipng doesn't change the image quality any? I've never used it, just installed it on my system. I ran a test and some images were cut in half. My eye doesn't see any quality diff. Al |
#81
|
|||
|
|||
Image formats
"Big Al" wrote
| optipng doesn't change the image quality any? I've never used it, just | installed it on my system. I ran a test and some images were cut in | half. My eye doesn't see any quality diff. | Oh, that's easy. Just open your other eye. |
#82
|
|||
|
|||
Image formats
"Big Al" wrote
| optipng doesn't change the image quality any? I've never used it, just | installed it on my system. I ran a test and some images were cut in | half. My eye doesn't see any quality diff. | Informative piece he http://optipng.sourceforge.net/pngtech/optipng.html I just tried optipng on an existing 20.5 MB PNG image. It took several minutes and reduced the size by only a small bit. It says 2.57%. The problem is that if you need to save those little bits then you almost certainly don't want PNG in the first place. JPG can be much smaller. Its lossy compression is designed to drop out data that the human eye is not likely to notice. So it can be greatly reduced while still looking almost the same as the unaltered image, as long as you don't need to enlarge it. |
#83
|
|||
|
|||
Image formats
On 17/02/2020 20:38, Andy Burns wrote:
Brian Gregory wrote: Don't forget you're comparing two very different things. JPEG compression is lossy. PNG and TIFF compressions are 100% lossless. TIFF files support various types of compression, including JPEG. OMG. TIFF seems like a nightmare compared to PNG. -- Brian Gregory (in England). |
#84
|
|||
|
|||
Image formats
On 17/02/2020 22:02, Mayayana wrote:
The problem is that if you need to save those little bits then you almost certainly don't want PNG in the first place. JPG can be much smaller. Its lossy compression is designed to drop out data that the human eye is not likely to notice. So it can be greatly reduced while still looking almost the same as the unaltered image, as long as you don't need to enlarge it. Depends what you're doing. I wouldn't be wanting to reduce the size of a PNG for a website if it was a photo, I'd use JPG. I'm not stupid. On the other hand if the PNG was a graphic logo with a transparent bvackground the PNG would probably be way smaller than a JPG which, er, wouldn't have a transparent background WOULD IT? -- Brian Gregory (in England). |
#85
|
|||
|
|||
Image formats
On 17/02/2020 21:48, Mayayana wrote:
"Big Al" wrote | optipng doesn't change the image quality any? I've never used it, just | installed it on my system. I ran a test and some images were cut in | half. My eye doesn't see any quality diff. | Oh, that's easy. Just open your other eye. Idiot. It's all LOSSLESS compression. Look it up. -- Brian Gregory (in England). |
#86
|
|||
|
|||
Image formats
On 17/02/2020 21:23, Big Al wrote:
optipng doesn't change the image quality any?Â*Â* I've never used it, just installed it on my system.Â* I ran a test and some images were cut in half.Â* My eye doesn't see any quality diff. No. Just tries different lossless compression parameters to see what works best for this particular file. -- Brian Gregory (in England). |
#87
|
|||
|
|||
Image formats
"Brian Gregory" wrote
| | optipng doesn't change the image quality any? I've never used it, just | | installed it on my system. I ran a test and some images were cut in | | half. My eye doesn't see any quality diff. | | | Oh, that's easy. Just open your other eye. | | | | Idiot. | It's all LOSSLESS compression. | Look it up. | Calm down. Just a joke. Are you on the payroll of the International PNG Marketing Council, by any chance? |
#88
|
|||
|
|||
Image formats
On 18/02/2020 15:43, Mayayana wrote:
Calm down. Just a joke. Are you on the payroll of the International PNG Marketing Council, by any chance? You're the one who's insisting TIFF is best, claiming PNG is over complicated when clearly TIFF is a way more complicated format. -- Brian Gregory (in England). |
#89
|
|||
|
|||
Image formats
Brian Gregory wrote:
On 17/02/2020 21:48, Mayayana wrote: "Big Al" wrote | optipng doesn't change the image quality any? I've never used it, just | installed it on my system. I ran a test and some images were cut in | half. My eye doesn't see any quality diff. | Oh, that's easy. Just open your other eye. Idiot. It's all LOSSLESS compression. Look it up. I'm not sure that's true. Be careful there. There are three levers. 1) DEFLATE compression. Lossless. 2) Pre-filter to (1) to improve compression performance. Still lossless. 3) Palette reduction. Potentially lossy in the color domain. If you start with a JPG with 100,000 false colors because of math roundoff, then pass it through palette reduction, the colors might get scrubbed down to 256 colors and usage of the 8 bit palette. The difference between the original set of colors and the new "256 approximate colors" is a loss of some sort. If you use pngcrush, it might be testing stuff like that for you, and making a decision based on byte count. Paul |
#90
|
|||
|
|||
Image formats
On 18/02/2020 16:21, Paul wrote:
... There are three levers. 1) DEFLATE compression. Lossless. 2) Pre-filter to (1) to improve compression performance. Â*Â* Still lossless. 3) Palette reduction. Potentially lossy in the color domain. Â*Â* If you start with a JPG with 100,000 false colors because Â*Â* of math roundoff, then pass it through palette reduction, Â*Â* the colors might get scrubbed down to 256 colors and Â*Â* usage of the 8 bit palette. The difference between the Â*Â* original set of colors and the new "256 approximate colors" Â*Â* is a loss of some sort. If you use pngcrush, it might be testing stuff like that for you, and making a decision based on byte count. Â*Â* Paul Nobody's even mentioned anything called pngcrush. The program we're discussing is called optipng and it clearly says in the first paragraph of it's website that no information is lost. -- Brian Gregory (in England). |
Thread Tools | |
Display Modes | |
|
|