>WRONG! > >jpeg is lossy even at 100% quality. The standard >requires storing 1/4 of the Crominance and >Saturation values. (they user 4x4 pixel >Crominance and Saturation boxes for each 8x8 >pixel luminance box)
JPEG uses the YCbCr colorspace (luminance, chroma-red, and chroma-blue). Grayscale JPEG stores only the Y component.
The spec doesn't *require* it, although most JPEGs do downsample the Chroma-blue and Chroma-red components to half the spatial resolution, taking advantage of the reduced sensitivity of the human visual system to those components.
Even if all of the components are stored without downsampling, though, the method can still be lossy due to possible differences in roundoff in the coder and decoder.
Reverse engineering wouldn't be necessary if people would use an open standard format (i.e, the Open Electronic Book Initiative). See the proposal at http://www.openebook.org/specification.htm
cdrom.com has been hosting the infozip and PNG web sites since November 1997 when we were booted off our previous host due to a sudden increase in traffic when Netscape started supporting PNG. Several days ago the infozip (zlib, zip) home pages were unceremoniously moved by CDROM from cdrom.com to
http://www.freesoftware.com/pub/infozip/
which came as somewhat of a surprise to the infozip people; we've still got a lot of broken links to clean up. The PNG site has also moved, to
http://www.freesoftware.com/pub/png/
but the cdrom.com PNG site is still there for now. At least it was last night...yup, still there.
> I think the next big breakthrough will be a compressor that > can take a file with not much repetition of data (therefore hard > to compress using current algorithms) and create a file with > much more repetition in it (and perhaps larger) and then compress > that down.
That's precisely what the filters in the PNG graphics format do. By calculating differences between adjacent pixels, a new datastream is created that has more repetition in it, and that new datastream is handed to Jean-loup's DEFLATE engine. Because the PNG filters are reversible, the original datastream can be recovered after decompression.
> Judging by the latest trend in patenting everything under the sun, >I think you can patent everything under the sun except for what someone >else has already patented.
People get away with patenting those, too. Witness the two patents (IBM and UNISYS) on LZW compression.
I had nominated Greg Roelofs for his "PNG: The Definitive Guide" but he didn't make the list. It's a good book anyway, well written, and including working code.
Copyright and license are two different things. You get a copyright on your software, which extends for 95 years, simply by writing down a copy of your software. You can put a dated copyright notice within the software, and you can formally register your copyright, but it's not necessary. As the copyright owner, you can license it to others however you want, including BSDL or GPL.
I doubt that there is or should be such a thing as a "three-year temporary copyright"; creating one would involve legislation and treaty.
It looks as though this case could be used in an argument against UNISYS's idea of "contributory infringement" of their LZW-compression patent.
UNISYS wants to hold web-site operators responsible for GIFs that appear on their site (search for "LZW" to see previous discussions here, or visit www.burnallgifs.org).
This case might apply when the only GIFs on a site are those that are passed through by an ad broker, leaving the ad broker and not the site operator responsible for paying the GIF tax, which is the way I think it ought to be.
} >But kW/h is wrong, and kWh/h is ACTUALLY CORRECT, as silly as it may seem. } Nah, it ain't so. kWh/h is a delta parameter, like acceleration. kW/h is a measure of the rate } of power consumption, and is correct in the given context.
Good grief. kW is a measure of rate of power consumption. kWh is total power consumed. kWh/h is the same as kW.
| I confess I haven't looked closely at the specs | for the gif format. Is the LZW compression an | absolute, or is it possible to have uncompressed |images in gif? (I suspect it's not possible,
It's possible, and John Miano's recent book, "Compressed Image Formats, JPEG, PNG, GIF, XPM, BMP" shows how. You encode all the data using 9 bit codes, and write a "clear" code after each 254 codes.
| Second - we can't expect everyone to convert to a new format if we haven't actually supplied | folks with a decent toolset, which includes easy to use tools to create animated [P|M]NGs.
If you have installed ImageMagick, version 4.2.9, which is freeware, you can do the following in a directory full of animated GIFs:
for x in *.gif do name=`echo $x | sed s/.gif$//` convert $x $name.mng done
The only thing missing AFAIK is proper translation of animated GIFs containing the "dispose=previous" method. I haven't seen any animated banners that make effective use of that feature anyhow.
} Be careful with PNG and BeOS! The PNG translator } that ships with current versions of BeOS } can create corrupt PNG files. Applications which } use libpng are typically unable to } read/display these damaged files.
A bug report has been filed with BeOS, and the bug is very simple (the IEND chunk is omitted), so I expect that that will be fixed very soon.
| the likely targets (web development houses, | corporate web sites) are much more likely to | have purchased and used the professional | software (such as photoshop) for the creation | of gifs than the unlikely targets (personal | web pages, small businesses).
At the risk of being moderated down for redundancy, it is demonstrably true that the big ad brokers are using unlicensed software (Gifbuilder and demo and unregistered copies of other software) to produce animated banners. They are also not smart enough to at least run a comment-stripper.
The UNISYS threat is to charge webmasters who serve such banners a fee (not necessarily only $5000). I imagine that the ad brokers themselves would make an attractive target, too. If I were running ads, I'd insist on a hold-harmless clause in my contract with the ad broker.
| I'm no lawyer, but aren't you just as liable to | pay any licensing fees after using gif2png as | you were before? It's not the gif itself that | means you have to pay, but the way the gif was | generated.... you still used an unlicensed | gif-generator at some point in the image's past.
I've been wondering about that myself but haven't seen evidence that UNISYS has thought of stooping that outrageously low.
} I don't think this has been brought up before, } so here goes. Why doesn't the internet } community come up with a single program that } uses the LZW compression, pay UNISYS for } the license, and then distrubute this
In fact, you can buy GIF-producing software for less than $50US. If you can guarantee that the final compression of all GIFs on your site were compressed with that software, you would be in the clear. It would be helpful if said software would write a GIF comment proving that it made the file. You would need to be prepared to prove to UNISYS that you actually own a paid-for copy of the software.
The main problem for webmasters that I see is the provably unlicensed banners that the big ad brokers like Burst and Double-click are still serving (/. is serving some, too). And, to make matters worse, if a webmaster is serving ads, he or she isn't even qualified for the generous terms of UNISYS's "special" $5000 license.
Of course, I'd rather see people use the convert-to-PNG solution, but even on my own sites I have to bear the non-capable browser in mind and provide a JPEG or text alternate for them to look at (never GIF, though).
} if gif2png is going to decompress the GIF and } then re-compress into PNG, it seems that the } image quality may still suffer a bit even if } the quality of PNG compression is better than } LZ for the simple reason that by the time it } gets to the user it will have gone through } two (lossy) codecs.
All of the decompression and compression ops are lossless in gif2png. The "quality" of PNG compression is better only in that it results in smaller files.
Of course not. Netscape did not discover GIF animation until summer 1995, after the PNG design had been frozen.
} Then there was MNG. To replace GIF, which takes } about 20K worth of C source } code (a little for for animation), I now need to } support two formats
MNG includes PNG as a proper subset, so you only need to support MNG.
| even the reference implementation didn't even | work right for months
That's the breaks with beta software. There are no known bugs in libpng (version 1.0.5a) now.
| Do you know of any programs that can create a 67 | byte PNG? Does the GIMP? I've not been | able to get anything under 100bytes (or even | 100bytes)...
| GIFs are also far more compact than PNGs; you | can have GIFs with two or three colors. I don't | believe PNGs have this ability.
In fact, you can have a 3-color PNG, but with GIF you can't. GIF palettes must be a power of 2 in length. You can have a 150-color PNG but with GIF you have to waste 105 palette entries if you have 150 colors.
Slashdot Mirror
>WRONG!
>
>jpeg is lossy even at 100% quality. The standard >requires storing 1/4 of the Crominance and >Saturation values. (they user 4x4 pixel >Crominance and Saturation boxes for each 8x8 >pixel luminance box)
JPEG uses the YCbCr colorspace (luminance,
chroma-red, and chroma-blue). Grayscale JPEG
stores only the Y component.
The spec doesn't *require* it, although most JPEGs
do downsample the Chroma-blue and Chroma-red
components to half the spatial resolution, taking
advantage of the reduced sensitivity of the human
visual system to those components.
Even if all of the components are stored without
downsampling, though, the method can still be
lossy due to possible differences in roundoff
in the coder and decoder.
Reverse engineering wouldn't be necessary if people would use an open standard format (i.e, the Open Electronic Book Initiative). See the proposal at
http://www.openebook.org/specification.htm
which came as somewhat of a surprise to the infozip people; we've still got a lot of broken links to clean up. The PNG site has also moved, to
but the cdrom.com PNG site is still there for now. At least it was last night...yup, still there.
> I think the next big breakthrough will be a compressor that
> can take a file with not much repetition of data (therefore hard
> to compress using current algorithms) and create a file with
> much more repetition in it (and perhaps larger) and then compress
> that down.
That's precisely what the filters in the PNG graphics format do. By calculating differences between adjacent pixels, a new datastream is created that has more repetition in it, and that new datastream is handed to Jean-loup's DEFLATE engine. Because the PNG filters are reversible, the original datastream can be recovered after decompression.
> Judging by the latest trend in patenting everything under the sun,
>I think you can patent everything under the sun except for what someone
>else has already patented.
People get away with patenting those, too. Witness the two patents (IBM and UNISYS)
on LZW compression.
I had nominated Greg Roelofs for his "PNG: The Definitive Guide" but he didn't make the list. It's a good book anyway, well written, and including working code.
Copyright and license are two different things. You get a copyright on your software, which extends for 95 years, simply by writing down a copy of your software. You can put a dated copyright notice within the software, and you can formally register your copyright, but it's not necessary. As the copyright owner, you can license it to others however you want, including BSDL or GPL.
I doubt that there is or should be such a thing as a "three-year temporary copyright"; creating one would involve legislation and treaty.
| it's amazing that no one here has mentioned
| having color cases yet!!!
I did (subject Color Visors) but was moderated
down for being off topic.
I ordered a couple of color Visors--one yellow and one blue--when they were announced several months ago, but so far they are completely invisible.
The company did contact me last month to confirm the order and promised delivery "within a week" but I didn't think to ask which week.
It looks as though this case could be used in an argument against UNISYS's idea of "contributory infringement" of their LZW-compression patent.
UNISYS wants to hold web-site operators responsible for GIFs that appear on their site (search for "LZW" to see previous discussions here, or visit www.burnallgifs.org).
This case might apply when the only GIFs on a site are those that are passed through by an ad broker, leaving the ad broker and not the site operator responsible for paying the GIF tax, which is the way I think it ought to be.
Yesterday's Red Hat article doesn't seem to have any first posts. It was released in the middle of the night after the kids had been sent to bed.
} >But kW/h is wrong, and kWh/h is ACTUALLY CORRECT, as silly as it may seem.
} Nah, it ain't so. kWh/h is a delta parameter, like acceleration. kW/h is a measure of the rate
} of power consumption, and is correct in the given context.
Good grief. kW is a measure of rate of power consumption. kWh is total power consumed. kWh/h is the same as kW.
| Seeing as intel and AMD ar both working on
| 1 ghz chips, I wonder how many people actually buy these...
Why not? They could use the Kryotech to refrigerate the 1GHz chip and overclock *that*,
couldn't they?
Waiting for a dog-manure bot..
| I confess I haven't looked closely at the specs
| for the gif format. Is the LZW compression an
| absolute, or is it possible to have uncompressed
|images in gif? (I suspect it's not possible,
It's possible, and John Miano's recent book,
"Compressed Image Formats, JPEG, PNG, GIF,
XPM, BMP" shows how. You encode all the data
using 9 bit codes, and write a "clear" code after
each 254 codes.
| folks with a decent toolset, which includes easy to use tools to create animated [P|M]NGs.
If you have installed ImageMagick, version 4.2.9, which is freeware, you can do the following in a directory full of animated GIFs:
The only thing missing AFAIK is proper translation of animated GIFs containing the "dispose=previous" method. I haven't seen any animated banners that make effective use of that feature anyhow.
} Be careful with PNG and BeOS! The PNG translator
} that ships with current versions of BeOS
} can create corrupt PNG files. Applications which
} use libpng are typically unable to
} read/display these damaged files.
A bug report has been filed with BeOS, and the
bug is very simple (the IEND chunk is omitted),
so I expect that that will be fixed very soon.
| the likely targets (web development houses,
| corporate web sites) are much more likely to
| have purchased and used the professional
| software (such as photoshop) for the creation
| of gifs than the unlikely targets (personal
| web pages, small businesses).
At the risk of being moderated down for redundancy,
it is demonstrably true that the big ad brokers
are using unlicensed software (Gifbuilder and
demo and unregistered copies of other software)
to produce animated banners. They are also not
smart enough to at least run a comment-stripper.
The UNISYS threat is to charge webmasters who
serve such banners a fee (not necessarily only
$5000). I imagine that the ad brokers themselves
would make an attractive target, too. If I were
running ads, I'd insist on a hold-harmless clause
in my contract with the ad broker.
| I'm no lawyer, but aren't you just as liable to
| pay any licensing fees after using gif2png as
| you were before? It's not the gif itself that
| means you have to pay, but the way the gif was
| generated.... you still used an unlicensed
| gif-generator at some point in the image's past.
I've been wondering about that myself but haven't
seen evidence that UNISYS has thought of stooping
that outrageously low.
} I don't think this has been brought up before,
} so here goes. Why doesn't the internet
} community come up with a single program that
} uses the LZW compression, pay UNISYS for
} the license, and then distrubute this
In fact, you can buy GIF-producing software for
less than $50US. If you can guarantee that the
final compression of all GIFs on your site were
compressed with that software, you would be in
the clear. It would be helpful if said software
would write a GIF comment proving that it made
the file. You would need to be prepared to prove
to UNISYS that you actually own a paid-for copy
of the software.
The main problem for webmasters that I see is the
provably unlicensed banners that the big ad
brokers like Burst and Double-click are still
serving (/. is serving some, too). And, to make
matters worse, if a webmaster is serving ads, he
or she isn't even qualified for the generous terms
of UNISYS's "special" $5000 license.
Of course, I'd rather see people use the
convert-to-PNG solution, but even on my own
sites I have to bear the non-capable browser
in mind and provide a JPEG or text alternate for them to look at (never GIF, though).
} if gif2png is going to decompress the GIF and
} then re-compress into PNG, it seems that the
} image quality may still suffer a bit even if
} the quality of PNG compression is better than
} LZ for the simple reason that by the time it
} gets to the user it will have gone through
} two (lossy) codecs.
All of the decompression and compression ops
are lossless in gif2png. The "quality" of PNG
compression is better only in that it results
in smaller files.
} But could it do animation? Of course not
Of course not. Netscape did not discover GIF
animation until summer 1995, after the PNG design
had been frozen.
} Then there was MNG. To replace GIF, which takes } about 20K worth of C source
} code (a little for for animation), I now need to } support two formats
MNG includes PNG as a proper subset, so you only
need to support MNG.
| even the reference implementation didn't even | work right for months
That's the breaks with beta software. There are
no known bugs in libpng (version 1.0.5a) now.
| Do you know of any programs that can create a 67 | byte PNG? Does the GIMP? I've not been
| able to get anything under 100bytes (or even | 100bytes)...
echo "P2 1 1 255 0" | pnmtopng > 67byte.png
give you a PNG with
signature 8 bytes
IHDR 13 bytes content + 12 bytes overhead
IDAT 10 bytes content + 12 bytes overhead
IEND 0 bytes content + 12 bytes overhead
The 10 bytes of IDAT content is actually
1 byte content + 9 bytes zlib overhead
| GIFs are also far more compact than PNGs; you
| can have GIFs with two or three colors. I don't
| believe PNGs have this ability.
In fact, you can have a 3-color PNG, but with
GIF you can't. GIF palettes must be a power
of 2 in length. You can have a 150-color PNG
but with GIF you have to waste 105 palette entries
if you have 150 colors.
| The MNG format (basically an animated PNG) is
| currently being worked on. It's not done yet, | but...
The format is done. The applications aren't.
But ImageMagick's implementation of MNG-LC is
fairly complete.
Read the spec at http://www.cdrom.com/pub/mng/