PNG is not a lossy compression technique while JPEG, well, yes.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

JPEG is not lossy on the things it was meant to capture: natural images.

JPEG is just as lossy with natural images as it is with everything else. It's the same algorithm no matter what the image source. The key factor, which you neglect to mention, is the human eye. With the right subject matter and the right compression "quality" setting, most people won't be able to distinguish, by eye, the JPEG from an uncompressed format. Software will though. (Thus, we don't store satellite imagery, for example, in JPEG because of the need for automated analysis.)

For a fixed number of output bits, JPEG is less lossy on natural images than PNG could ever be.

The number of output bits is irrelevant. It's the number of input bits that matters. Neither PNG nor JPEG provides a way to say "compress this image to exactly X bytes." The issue is whether you can decompress your data and retrieve, unaltered, the original input.

It's simple. Both PNG and JPEG are compressed file formats. JPEG makes a trade-off: a slight loss of information for a smaller file size. That's why it is called lossy. PNG doesn't make that trade-off. That's why it is called lossless. Trying to look at it bass-ackward, from the perspective of how many output bits each format results in, and claiming JPEG is "less lossy" than PNG isn't helping anyone, especially not those that are unfamiliar with the concepts.

I know you already understand this merlyn, but instead of a condescending response tainted with a judgement about the original poster's tone ("please stop saying that as if it was a bad thing") why not just make your point...

"JPEG is a very good format for its intended use."

-sauoq
"My two cents aren't worth a dime.";

Neither PNG nor JPEG provides a way to say "compress this image to exactly X bytes."

Just because your image software doesn't have a slider for this, doesn't mean that isn't exactly what you are doing. When you prepare an JPG for the web, you select a compression ratio. If the final image isn't small enough, you select a higher compression ratio and try again, till you hit the desired size.

There's no ratio dial for PNG images though. The only way to make the file smaller is to resize it. Again, there's no dial or slider for "desired file size". You shrink the image until it is the desired file size.

Both these processes degrade the image.

merlyns view is only arse-forwards if you are facing the wrong way (arse-backwards makes no sense, your arse is always backwards) . merlyn has thought about the situation and noticed that both resizing something and lossily compressing something result in less of an intangible thing, which usually gets called 'information'.

Yes, he made a silly statement with "jpeg is not lossless", although it can work in lossless mode if you want it too. But he then made the good point that thanks to the design of JPG's algorithm, JPG usually gives better. more accurate pictures than a PNG of the same size.

And regarding the satellite imagery - the same situation as the web occurs, but because you are focussing on the word 'lossless', you are missing the bigger picture, where the trade-off is made.

When the Martian lander transmitted its pictures back, the engineers had to make a choice. They had a fixed (quite small) bandwidth. That's like the file size merlyn was talking about. To fit a picture into this bandwidth, they could either: reduce the picture size or lossily compress it.

____________________
Jeremy
I didn't believe in evil until I dated it.

PNG doesn't make that trade-off.

No, but PNG makes a different tradeoff... a maximum width-by-height resolution for a given number of output bits.

They're both lossy, just in different directions. Information theory says so. You take the entire rich original experience, and put it into 100K. PNG and JPEG just do it differently. PNG sacrifices width-and-height, while JPEG sacrifices some of the subtler items of a natural image.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Well, mostly. But once something has been JPEGified it is for many intents and porpoises uneditable, because it's a lossy format. This is why I get slightly irritated that my digital camera defaults to saving stuff as JPEG. Thankfully, it can do TIFF too.

I've pondered this argument a long time because something in it didn't sit right with me. I agree with you, but then sauoq is correct as well.

The problem is we're talking about two different levels here.

One is the representation of an image. Even capturing it on any kind of media is already a lossy step, because nothing short of an exact replica of of the entire scenery (that is, in meatspace, with the exact same materials and everything used) can ever record that image absolutely faithfully. Here indeed PNG is lossy as well - by definition, in fact, since there is no such thing as a lossless image capture media.

The other is the representation of a finite stream of bits. On this level it is certainly very possible to achieve an entirely faithful capture of the input. I don't think we need to argue this any further.

I agree with you insofar as people do tend to confuse these issues. However, you failed to point out the distinction as well. I knew both positions in the argument where right even though they seemed to conflict - and even though I'd consider myself at least somewhat knowledgable of information theory, and it is so very obvious in hindsight, it is obviously easy to confuse these.

Also note that repeated reserialization of an image into a bit stream as performed by JPEG will reduce the accuracy of the reconstructed input. JPEG being "lossy" in both sense thus is a downside if you're going to manipulate the image further. It is a mighty fine final storage format, of course.

Makeshifts last the longest.

PNG has its pixels expressed in 24 bits while GIF only 8.

Actually, PNG allows up to 36 bits per pixel.

Update: 48 if you include the alpha channel.

-sauoq
"My two cents aren't worth a dime.";

Point #1: PNG's limitation on image dimensions is 2**31 in both directions. So that makes the image max out at 2**31 * 2**31 (4_611_686_018_427_387_904). Take 8 bits for red, green, and blue color channels: 2**62 * 24 (Yes, it supports 12 bpp and one more channel, I know) Divide by 8 to get bytes: 13_835_058_055_282_163_712 That's 12 petabytes. I'd tell you what size a PNG of that raw image would be, but I can't do it on paper ;) The point is, larger than those dimensions, there is a loss, but I don't see anyone still using PNG by the time we can process that kind of data easily. (chunks are too small)

Point #2: JPEG also has a limitation on image dimensions, I'll leave it as an exercise to the reader. No more math, ugh.

Point #3: If I have a raw bitmap as described above, and feed it into a program (say raw2png), then feed it into png2raw, I will get the exact same bitmap. Lossless

Point #4: If I attempt to do the same with a JPEG converter, my images are different. JPEG estimates images using math. Lossy.

Point #5: If I am publishing an online comic, I'll use PNG. If I am publishing nature stock photos, I'll use JPEG. That's how it is. I'll do the same if I stick a small picture in a GUI.

Point #6: Why was my JPEG lossy? It was either me or my encoder because JPEG supports lossless compression -- must've been me.

Point #7: JPEG (DCT mode (normal mode, that is)) will always be lossier than PNG. It may have been made for natural images, but it's already ruined by being converted to digital representation. There is a great chance that analog images can be approximated using math, in fact, many mathematicians have analyzed this. If there were a way to store analog images on a "computer", then FFT it, then it would be still be lossy to an smaller extent, but PNG would be lossier :)

Okay, now that the points have been laid out, I will say this once and only once: Use the right tool for the job.



---


Another subject of concern is that my fellow monks, merlyn and sauoq, are at each-other's throats. There is a reason this is PerlMonks -- most monks are generally well-tempered and helpful. Try it.   I have reason to believe that neither of you did anything useful for the OP. Maybe one of you needs to be an adult and stop this, or maybe you both need to work it out in private. Whatever it is, get it out of useless threads in SoPW, please.

---

On-topic: I too attempted to use Tk::PNG and had issues on Win32... It's unlikely I have the expertise to sort all of the problems out; sorry.

mhoward - at - hattmoward.org

the licence will expire in France, Italy and Uk in one year

Is that true? As far as I know algorithms are not patentable in the European Union (and hopefully they will never be). What license are you referring to?

the licence will expire in France, Italy and Uk in one year

Is that true?

Yes, it's true. If you believe what Unisys has to say about it, anyway.

-sauoq
"My two cents aren't worth a dime.";

I was hoping you could repost your question succintly. I got completely lost between your thees and thous and other rambling.

However, as far as I know, nobody has been able to compile Tk::PNG under Win32. (Perl AS 5.5x, 5.6.x and 5.8).

I think he was asking if anyone knows how to compile Tk::PNG in Windows. However, I can't be sure.

"Pain is weakness leaving the body, I find myself in pain everyday" -me