Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

•Re: Re: •Re: Re: •Re: GIF patent

by merlyn (Sage)
on Jun 19, 2003 at 07:31 UTC ( #267101=note: print w/replies, xml ) Need Help??


in reply to Re: •Re: Re: •Re: GIF patent
in thread GIF patent

PNG doesn't truncate¹ the input data.
Right, because it doesn't need to, since that had to have been done in the first place when you picked a width-and-height.

Think of it this way. From the original image, for a given output file size, there is an upper bound on the number of pixels times the absolute accuracy of each pixel times the overall accuracy of the image. Information theory tells us that. PNG choses to hold the overall accuracy and absolute accuracy constant, thus bounding the number of pixels. JPEG choses to hold only the overall accuracy of the picture constant, thus allowing the number of pixels to vary inversely with the individual accuracy.

Certainly, if individual accuracy is important, you can't use JPEG. I'm not arguing that. I'm just saying that at some point, you had to go from "real world continuous values" into "discrete values stored in a file". That's lossy. PNG just lets you pick certain things to hold sacred in that process, and JPEG lets you pick certain other things to hold sacred. I'm happy we have both.

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

  • Comment on •Re: Re: •Re: Re: •Re: GIF patent

Replies are listed 'Best First'.
Re: •Re: Re: •Re: Re: •Re: GIF patent
by sauoq (Abbot) on Jun 19, 2003 at 11:07 UTC
    Right, because it doesn't need to, since that had to have been done in the first place when you picked a width-and-height.

    The point you are arguing is completely void of semantic content.

    File formats and compression algorithms have nothing to do with the inability to perfectly reproduce a visual scene. That doesn't matter because you couldn't get two people to agree on what a perfect reproduction was anyway. It only matters that you have the ability to capture X bits of information. After you capture those X bits of raw information, you are faced with the problem of storing them and must choose a file format.

    If you pick JPEG, you can store that information in less space, but you'll never be able to reproduce your original X bits of information. Hence, we call it "lossy."

    If you pick PNG, you can store that information in less space though probably not as little space as you could if you had chosen JPEG. On the other hand, you will be able to reproduce your original X bits of information. Hence, we call it "lossless."

    Let's hit the salient points again.

    • You can only capture X bits of information.
    • If you choose JPEG to store those X bits, you won't be able to get them back again.
    • If you choose PNG to store those X bits, you will be able to get them back again.

    Hence, we call JPEG "lossy" and PNG "lossless". The accepted terminology is really quite simple.

    Yes, collecting real world data is inherently a "lossy" process. No, that's not relevant to discussing the differences between PNG and JPEG which are applied after the data is already collected.

    -sauoq
    "My two cents aren't worth a dime.";
    
      You can only capture X bits of information.

      This is where you are getting it backwards. You can take your 3 megapixel camera, take a photo and compress it with PNG to get a X Mb file.

      I can then then go get a 4 megapixel (oh how I wish), take a photo and also compress it to X Mb.

      But the JPG may actually have more information, because it had more pixels to analyse while is was compressing. It could make a choice about with pixels to drop. However your 3 megapixel camera has already performed a lossy compression by throwing out a random 1 million pixels.

      Hence, we call JPEG "lossy" and PNG "lossless". The accepted terminology is really quite simple.

      The terminology is also quite deceiving. Of course if you feed digital data like an executable into both formats, JPG will corrupt it and PNG won't. But that's not what we are doing. We are feeding a digital representation of analog data into the formats. You have to consider the system as a whole.

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

        The terminology is also quite deceiving.

        When you start questioning terminology that is widely used and generally accepted without a bit of controversy, it's time to wonder whether the misunderstanding is on your part or that of the majority who remain unconfused.

        Of course if you feed digital data like an executable into both formats, JPG will corrupt it and PNG won't. But that's not what we are doing.

        Uh... that's exactly what we are doing.

        We are feeding a digital representation of analog data into the formats.

        What the digital data represents is entirely irrelevant. In fact, erroneously taking it into account has badly biased your argument. The fact is, you don't know where the data is coming from or whether it is in fact a representation of analog data. For example, what if it is entirely created in The Gimp?

        You have to consider the system as a whole.

        No. You don't. Just as you can talk about the properties of a car's tires without mentioning the engine, you can talk about the properties of compression algorithms without discussing the camera that uses them.

        -sauoq
        "My two cents aren't worth a dime.";
        
Re: •Re: Re: •Re: Re: •Re: GIF patent
by Anonymous Monk on Jun 19, 2003 at 07:58 UTC

    Merlyn says: I wonder if the picture people are ever going to stop arguing...the one s that don't understand that all file formats are lossy

    If my camera captures an image and saves it in tiff format. NO INFORMATION IS LOST. Non-lossy file format.

    If I then choose to convert this tiff into a .png, the image will be compressed, the output file size will be reduced, but STILL NO INFORMATIO WILL BE LOST. A non-lossy, compressed file format.

    If I choose to convert this program to a .jpg, the output file size will smaller than the tiff, and depending upon the options select during conversion, it may also be smaller than the .png. BUT THIS OUTPUT FILE SAVING WILL HAVE COME AT THE COST OF LOST INFORMATION. DETAIL WILL HAVE BEEN DISCARDED FROM THE ORIGINAL IMAGE. This is a lossy format.

    All the images will remain the same size (width x height) as the original (unless I choose to crop the image, which has nothing to do with the output file format).

    Your statements in this thread that elude to the idea that .png is a lossy format are simply false, misleading and wrong.

      If my camera captures an image and saves it in tiff format. NO INFORMATION IS LOST.
      But that's the step at which information is lost, but you're part of the process.

      For you to have a PNG of a certain file size, you are picking an upper-bounded width and height to take your picture.

      JPEG allows you to make that tradeoff later in the cycle by trading some of the individual bit accuracy for the overall pixel count.

      There is always a loss in the process. You do not record every nuance of the original analog experience. You are reducing it to some discrete value in various stages along the process, during the capture by deciding bits-per-pixel and total pixels, and during file storage by deciding whether you are willing to trade either or both of bits-per-pixel or accuracy of individual pixels to retain overall image quality. PNG and JPEG just do that second step differently. PNG is optimized for when the individual bit accuracy is important. JPEG is optimized for when the individual bit accuracy can be traded off so that the overall image information can have a higher number of pixels.

      {sigh}

      Please go study some information theory. Ten pounds of information doesn't fit in a five pound sack, no matter how you represent it. It's like why you can't keep gzip'ing a file over and over again to get a smaller file.

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

        I think the subtlties of analogue to digital conversion may be lost on some people here. This, of course, has the same scope as with music. When you record someone singing or playing an instrument (just as with taking a picture) you make an approximation of your data.

        By definition, analogue data can have an infinite number of values where as digital data cannot. The best analogy I can think of is for you to draw a sin wave on a piece of graph paper (squared paper). Colour each column upto the line. However, if the line goes below the half way line of a square, leave it blank. If it goes above the half way line, fill it all in.

        You should now find your nice smooth curve all nice and *jaggy*. Immediately you have lost information in the process of conversion. However, if done on a grand scale this approximation (like in digital cameras and CD audio) is kept to an acceptable level (ie you can hear or see the difference).

        The rest is about trying to keep the space that your approximation takes up as small as possible (as discussed already).

        SP

        But that's the step at which information is lost, but you're part of the process.

        Wrong! No information is lost at that point, because you cannot loose what you never had. Agreed, the image as captured by the camera does not contain all the data available at the original scene, but then neither do your eyes!

        They omit capturing the infra-red part of the spectrum & below; and the ultra-violet spectrum & above. Come to that, the camera does not capture the temperature, or your personal mood. All of which is totally irrelevant.

        The TIFF format failthfully records, in a lossless manner, all of the information available at the point of capture. Anything else, including the size of your hat is information available at the original scene, but not lost, because it was never captured.

        For you to have a PNG of a certain file size, you are picking an upper-bounded width and height to take your picture.

        This is also irrelevant. You don't start with a file size and then say "How big an image can I fit in it". You start with an image of a given size (width x height x color depth) and say how big will the file be when I save this to disc.

        • Tiff record everything available at the point of capture. That is, the digitally encoded recording of the result of analog-to-digital conversion performed at the point of capture.
        • PNG will use LOSSLESS compression techniques to reduce the filesize without throwng away information available in that original image.
        • JPG will also use compression techniques reduce the filesize, and can reduce the filesize more than PNG. However, regardless of the options chosen, even if you specify minimum compression, JPG will still discard what it chooses to deem irrelevant detail from the original image.

        This is the reason the 'ISO SC29/WG1' committee, otherwise known as the Joint Photographic Experts Group defines the JPEG image compression standard as

        JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with. (There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.) JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans. If you plan to machine-analyze your images, the small errors introduced by JPEG may be a problem for you, even if they are invisible to the eye.

        JPEG allows you to make that tradeoff later in the cycle by trading some of the individual bit accuracy for the overall pixel count.

        So wrong! The implication of that statement is that JPEG can somehow increase the size of the image provided you accept that color of the individual pixels may not be the same as they started out. JPEG can't autovivify extra pixels for you. It can only throw away detail from the original captured image--which further reduces the fidelity from the original scene--in order to save a few bytes of disc-space or bps of bandwidth. The information lost is carefully chosen, and if disc-space or bandwidth are your criteria, then this may be a trade off you wish to make, but that is all irrelevant in the context of the discussion of whether JPG is lossy and PNG/TIFF are not.

        Please go study some information theory. Ten pounds of information doesn't fit in a five pound sack, no matter how you represent it. It's like why you can't keep gzip'ing a file over and over again to get a smaller file.

        To quote you once more, {sigh}. If you want to get into a pi**ing contest about who has the greater expertise in information theory, take it up with the ISO SC29/WG1 committee.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://267101]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2020-02-17 10:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?










    Results (71 votes). Check out past polls.

    Notices?