Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

GIF patent

by didier (Vicar)
on Jun 18, 2003 at 20:01 UTC ( #266967=perlquestion: print w/ replies, xml ) Need Help??
didier has asked for the wisdom of the Perl Monks concerning the following question:

June 20, 2003 will be a beautiful day ! Because it's friday that expires the Unisys's patent over the GIF format.
GIF will be therefore royalties free in US, the licence will expire in France, Italy and Uk in one year, between June 15 and 20, 2004 according to countries.

Once upon the time there was a beautiful baby : the PNG format.
PNG has its pixels expressed in 24 bits while GIF only 8.
PNG is not a lossy compression technique while JPEG, well, yes.

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).
Some of the bests fails
Is that also the case in this prestigious monastery ?
Some shoot under Win32 for some of you ?
Some success, O my God, some success ? How ?
If not what's yours thoughts about why it fails ?

And could we survive in a programming world where PNG under Win32 is the master sin ?

For Tk, under Win32, it means: the only way to describe complexity in a picture must be done through the XPM format (JPEG is 24 bits but some pixels will vanish).
Tk::Photo is able to read 24 bits format, like BMP 24b (internally the lib can use 32 bits per pixel) but it can output only 8 bits for BMP and Gif of course.
Note: the XPM format using the Tk'write() method output 24 bits if you want..
Handle XPM is tricky but can take a while.
Of course there is TIMTOWTDI, but GD is a 8 bits package, remains Image'Magick, Prima(? bits, writing capability ?), Wxperl (?) and Win32::Gui which allows BMP 24b (Writing with DIBitmap) but Tk::PNG is, of course, very best suited for the Tk environment

Win32 Tk users are still expecting 24 bits/pixel embedded in a lossless process.
If one of my dear fellow has already solved this problem, could this neural brother explains his method ?

Comment on GIF patent
•Re: GIF patent
by merlyn (Sage) on Jun 18, 2003 at 20:09 UTC
    PNG is not a lossy compression technique while JPEG, well, yes.
    Please stop saying that as if it was a bad thing. JPEG is not lossy on the things it was meant to capture: natural images. For a fixed number of output bits, JPEG is less lossy on natural images than PNG could ever be.

    -- 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.
      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.";
      
        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.

        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.

      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.

Re: GIF patent
by diotalevi (Canon) on Jun 18, 2003 at 20:25 UTC

    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

Re: GIF patent
by abell (Chaplain) on Jun 18, 2003 at 22:09 UTC
    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 stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket
      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.";
      
Re: GIF patent
by sauoq (Abbot) on Jun 19, 2003 at 02:52 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://266967]
Approved by RollyGuy
Front-paged by Acolyte
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (12)
As of 2014-07-23 16:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (147 votes), past polls