Slashdot Mirror
jpeg2000 Allows 200:1 Wavelet Compression
Polo writes "Here is an
EE times article about the ISO JPEG2000 standard that has been
finalized and allows a new wavelet compression scheme that gives
good results at as much as 200:1 compression ratios. It looks
pretty promising. It is royalty-free, but there is also discussion
about a second standard that allows third-party, royalty-based extensions. I wonder if motion-jpeg with wavelets could fit a movie
on a CD or something."
Imagine a DVD-ROM with a truly open navigation system, and mjpeg2000. More video, progressive scan option, and maybe even better quality. :)
The CD-ROM subset would still hold about 30 minutes with at 640x480 with mp2 audio, i bet... and a whole movie at 320x240 (VCD res)
- Chad
...hello, mcfly...
Royalty based, propriatry and encryption based codecs see the least deployment and industry acceptance.
...hello, anybody home?
Who's funding these idiots anyway?
Oh, that's right... people who pay taxes and joe blow consumer...
That explains everything...
I think you misunderstood. Its not really your fault, they should have been more clear. The three pictures on the page are one GIF. They represent, however, what they are labled. The top of the GIF image is converted from the 3MB original. The middle of the GIF is converted from the 19kB JPEG2000. The bottom of the GIF is converted from the 19kB JPEG. They show the relative resolutions achieved by said compressions.
This was done for a number of reasons such as JPEG2000 not supported by web browsers yet, the limited bandwith most users have, and the universal support of GIF images in graphical web browsers.
DVD is MPEG2, but also allows for MPEG1 video. The audio can be uncompressed PCM, MPEG layer 3 for Europe, or AC3 5.1 for America.
For video, have an iso9660 file system with a directory "open_video" off the root directory. In that directory, one would have a "video.ifo" which would have a machine readable description of what scenes, alternate camera angles, and audio tracks, are available in the "video.vob" file. Also, the "video.ifo" could have Java applets (or merely point to them) which could be used for such things as user menu logic, interactive video, internet enabled disks, etc.
I must plea ignorance about the details of wavelet compression, but if it's anything like the Fourier transform or any other integral transform, then it should be rather easy to implement...I don't see how a company can patent an integral.
Besides, the bottom of the article says that companies have already agreed to make all parts of JPEG2000 part 1 royalty-free.
The planned additions for JPEG2000 part 2 do sound exciting (motion, text, etc.), but the article made it sound like the only drawback to part 1 was that it required more work to do the stuff that is capable with part 2.
Give a group a hackers a few weeks, and I'll betcha that there will be free implementations of everything available with part 2.
The sad thing is that this isn't going to be released for another YEAR. It's available now, but it's probably not useful for anything more than storage of images locally...certainly no browsers support the format currently.
Netscape only displays PNGs if using an embeded tag which is completely ass backwards to all other browsers which support PNG along the same lines as GIF and JPEG with an img tag. As well as having a completely shitty and broken implementation of PNG support, typical Netscape err iPlanet.
World-wide wankers will want to know. We need some hard data based on recompression of existing jpg databases like http://www.heartbreaker.com/heart/home.html and on uncompressed source material. If the ratio of decompress to download time is good, the transition will be rapid.
First of all, I doubt it could be done. Second of all, if it could be it's not worth the effort. JPEG is for still images, compression of motion video is much different than compression of a single frame.
Lets say for the sake of argument you use a JPEG/MPEG hybrid format. Ops, we forgot one major thing didn't we? The sound track. Even in Mp3 it's going to take up a pretty big hunk of the disk. Plus, the CPU overhead of our JPEG/MPEG hybrid would probably not leave much extra CPU time for decompression of a stereo mp3 track (much less a Dolby 5.1 track)
Well as long as someone else than Apple takes care of the player, because Quicktime 4 is EVIL. I don't think any other media player ships half of the operating system with it and runs like a slug... :( Crashes like a mother too (at least the Windows version does). Quicktime 3 was pretty much the same way...
Where are you going to get 5gb of storage for well under $25.00 (the cost of most DVD discs?) Unless you can do this for around $10.00 then people are not going to pirate DVD discs because the storage space costs as much if not more than a real DVD... (and they are cool and small). Sure you could put it on 8 CD-R discs but this is a pain in the ass. So lets say we get a neat video format on CD for 8 bucks a pop... these will get prirated for sure becuase CD-R blanks are dirt cheap... Leave DVD alone... it a good standard for everyone and I think it's priced well.
This idea has been around for a while, the only problem is getting people to agree on things like "which textures should we use for stucco?". You'd have to get a photographer to do this as a work for hire, have him/her assign the rights to the standards comittee after receiving payment.
Or better yet, imagine a husband and wife arguing over carpet swatches. Now magnify that times thousands and thousands of images, thrown in a comittee, corporate and national interests (do we really need an Islamic prayer rug texture in the standard, that kind of thing). Mix it all together and let is stew for 10 years. It just won't happen.
Now, on the other hand, if AOL did something like this, and allowed non-AOL users to install a plugin that used the images it would probably work. At least then the AOL disk would be good for something other than frisbee golf.
--Stevecomments@vrml3d.com
Has anyone started to add JPEG2000 to any GPL Library or tool ? Let Linux be the first platform to fully support this.
Basic principal - if noise will compress losslessly it isn't white. This is actually a way of defining white noise - read Shannon.
Why dont you make yourself fameous and add it to imlib or another Linux (Unix) image library. We could then all be using this new technique soon.
It has for example, Lossy, lossless, no compr modes for image data.
Also alpha channel is implemented as color component model. i.e. you could hava any number of color components (here I could be wrong, I read that part of the specs pretty fast).
By the way, reason why specs are not there in the open is that, there might be some changes still, so those jpeg people do not want any incompatible jpeg implementations hanging around.
---
About Jpeg-ls somebody should write gimp plugin to use that method. Jpeg-ls even has reference library, so it could be no brainer.
Interesting, I wonder why MPEG-2 audio layer 3 does not use QM-CODER to code transformed subbands? As arithmetic coder is always more optimal. (I know about the patent problem)
Fortunately somebody said, that MQ-CODER in JPEG2000, which is modified QM-CODER, does not have patent problems.
Anyway about to use DWT to motion based data. I wonder why, MPEG-4 and MPEG-7 still use DCT??? (that information might be incorrect, cause I definitely am no MPEG expert).
Nice GPL image compressor is GWIC http://www.jole.fi/research/gwic/
If the guy was real we would see the results.
.AU isnt large so it shouldnt be hard to track him down, I think I might try a few leads and see.
Hes a fraud, or maybe the DVd consortium paid him $20m to shutdown the project.
Any way,
But think about it, how can a 22yo be a genius not only in video compression, but also audio. You gota be joking its like having a #1 gitarist Jimmy Hendricks also being gifted in Einstein maths thoery
Dolby Prologic is stereo which is just 3% cpu time for mp3. Also MJPEG is quite good today and is great for editing frame/frame, go to jpg.com and get a free encoder for windows that can record in realtime from capture card using less than 12% cpu on a P400.
Give the coder who writes it a BEANIE PRIZE!!
640x480/24bit => 4608 1h30min movie 25fps 640x480/24bit => 622'080'000 = about 1 CD Very nice indeed.
Could you use wavlets to compress audio? Could you stick an entire CD on one floppy disk? Would there be some problem with an mp4 based on wavelets?
Wavelet transforms are highly asymmetric, by which I mean they compress slowly but decompress fast. The decompress speed beats the current JPEG, but compression can be desparately slow, especially if you want optimal results. This is the stated reason MPEG2 didn't go the fractal/wavelet route, though lots of IP and political issues played their part. A mini-DV cam-corder would be impractical with current technology if it used wavelet compression. For studio broadcast TV, where only one compressor is needed for every 100K decoders and size is irrelevant, wavelet compression looks very sane. The MPEG guys wanted a coder for all seasons, though.
What is it and how do you play it? Any *nix ASF players?
The look the same to me. From this demo: http://ltswww.epfl.ch/~neximage/decoder/applets/Bi ke-d-c_0.5.html But the j2k file can be downloaded here: http://ltswww.epfl.ch/~neximage/decoder/applets/bi ke-d-c_1_vm31b.j2k The file size of the j2k is 31.9 KB
If it is, then thats another good reason why it will win out.
I'm the director and house geek for the Thomas A. Edison Papers, working to put a few hundred thousand of his documents on line (reduced from the original 200dpi 8bit grey scans). They are handwritten or printed and range from blueprints to agate-type newsprint (very small). As someone who has searched mightily for a *practical* compression scheme, I am very excited about JPEG2000. HP has a demo application for playing with images using the spec (can't find the URL), and I like the results. I've looked at PNG, AT&T's DjVu (which is wonderful for particular sorts of images, but not ours), and a small heap of less successful schemes, but we're still using standard JPEG because--surprise--the compression is best, even with the stupid halo it throws around sharp edges. For the small-type articles, the printed court records, or those drawings where Edison went into micro mode, we have to use a lesser spatial reduction as well as a lighter JPEG compression. The new standard will be a whole lot clearer for the kind of sharp-edged images we have. A big Yes from this quarter.
I wonder if motion-jpeg with wavelets could fit a movie on a CD or something.
Am I the only one who thought "umm, the DVD people were probably right." If this compression allows a whole movie to be converted and compressed to fit on a single CD with current (hardware) technology... then they are probably right to hammer anyone breaking their protection scheme into the dust.
Not that this comment would be interpreted as anything but flamebait on 'ye olde pirate shippe Slashdot'
How does JPEG2000 compare to Mr SID?????
Contemplating getting a Mr SID license, but hey if this is free, I'll wait a couple of months....
No JPEG or MPEG encoder/decoder uses CPU instructions to calculate cosine waves. In fast DCT implementations, only about 8 distinct floating-point values, corresponding to 1/sqrt(2), cos(3*pi/8), cos(7*pi/16), and a few others, are needed. Those constants are hard-coded in, for extremely fast implementation. The wavelet transform is done in a similar way. JPEG2000 uses the Daubechies 9/7 biorthogonal filter pair. Since both filters are symmetric, only 5+4=9 floating point filter coefficients are needed. These are also hardcoded in. Wavelet compression is slower, though, due to the need to upsample and downsample the input image. It also requires more memory.
Wavelets, at least in their current incarnation, are not ideal for audio compression. The reason is that audio signals are completely different, statistically, than images or video signals. If you look at an audio signal, there is relatively no smoothness. Everything is choppy. While it is true that wavelets can approximate spiky signals well, they do not do a good job on audio. Audio signals are difficult to compress by any means. This is why 20:1 audio compression is very hard to find, while JPEG can compress images 40:1 no problem. What MP3 does is use a 32 or 64 (I forget which) channel filterbank to separate the signal into frequency bands. These bands are then encoded separately, using a psychoacoustic model. One interesting idea is to use wavelets, specifically wavelet packet decomposition, to mimic the filterbank. In normal wavelet compression, a signal is filtered into lowpass and highpass components, and then downsampled. This process is then iterated on the lowpass branch. In wavelet packet decomposition, every branch is iterated upon. The disadvantage of wavelet packet decomposition is that it is very slow. In my Multimedia Coding class, one group demonstrated a wavelet audio codec which had *decent* quality at around 8:1 compression. There is much work to be done in this field.
"Given, it is an older version... [does anybody know, or care to comment how different/what version that Slashdot currently uses? I haven't found that information, or figured out how different it is by comparison, yet. The only hints I've seen are that they are at very least at version 0.4]"
.03 code they dumped on you - it is worse than horrible.
RADICALLY different. Go take a look at the pre
Despite all the handwaving to the contrary, "slash" went closed source as soon as it looked like $$$ could be made. And it will be a cold day in hell before it comes out again.
Witness the abuse Taco and Rob heap on anyone who dares ask them about it.
&sign($AC[0]);
Slashdot: Hype to make us money, rumors for zealots.
Those that live in the western hemisphere may not
be aware that it's already possible to fit whole
movies on a single cd rom - and there are already many hundreds (if not thousands) of titles available. I'm talking about DVCD - yes, that's
DVCD not DVD - those one-disk VCDs that sprung
up not so long ago. It's just MPEG compression,
and while the quality is not a match for a DVD,
it's really quite good.
The best thing is that titles are widely available for around 3 RMB, just a little more than US$0.30.
You know, just about every single movie released
is quickly converted into MPEGs and pressed onto VCDs in illegal operations Hong Kong and Guangzhou... and some titles can be available on the street just a fews days after the premier in the theatres. It's a massive industry.
DVD is already heavily compressed. It uses interframe compression (MPEG-2, specifically) which means that even if JPEG2000 is far more effective at compressing *still* images, you might not get that much of a space saving. (Of course, if JPEG2000 catches on, I'm sure that a corresponding format will be developed that also supports interframe compression - MPEG2000?) In video, there is a great deal of redundancy not just *within* a frame but *between* frames as well. BTW, a single-sided, single-layer DVD holds a maximum of 4.7 gigabytes. With dual-layer, it is (I think) 8.5 gb.
My personal conspiracy theory is, that there exists a *LOT* of expensive hardware that can do Fouries forwards and back to allow real-time encoding and decoding of MPEG movies in good quality. The companies producing these devices will lobby any standards-organisation to *NOT* consider wavelets and stick to good old Fourier. If this holds, it will take a few years until we see Wavelet compressed video :)
I don't know if you kidding or not, but since I feel like picking nits, here goes. The 1D Fast Wavelet Transform requires O(n) operations, where n is the number of data points in the sample. The 1D Fast Cosine Transform (as used in JPEG/MPEG) is O(n log(n)). Now, admittedly, the JPEG/MPEG implementation uses 8x8 squares, which causes the scaling to drop to O(n). Both the Wavelet and Fourier transforms involve a series of inner products and reductions. I suspect that DSPs could easily be assembled and programmed to do either transform quite efficiently and inexpensively.
Darn, I thought of everything but the porn. (DVD consortium burning in flames is a pleasant thought) Still, JPEG = lossy, you know? You'd take a quality hit...
I swear ASF is like DirectX. Two purposes. One -- provide some benefit to the local user community (pretty doubtful, because AVI/MPEG/MOV already existed). Two -- screw the hell outa people using platforms other than Windows, because no one else can use it.
And Microsoft's pushing some new sound format too that beats MP3 by some nice margin...wanna bet it's Windows-only?
Be careful : the JPEG2000 decoder you linked is based an older version of the Verification Model of the JPEG2000 standard (it uses VM3.1B, and the latest one is VM5.2 ...). Though it gives you some idea about the global performance of this algorithm, the final result should be slightly different ... Moreover, the code of this decoder may not be released, since the rights are owned by Motorola (this project was a partnership between EPFL and Motorola). BUT there is another decoder written in Java (see here ) which is not publicly accessible for the moment (only the JPEG members can access it). The latest JPEG meeting proposed that the final JPEG2000 standard would consist of a text AND a reference software (written in C or in Java) which may be accessible to anyone, lucky guys !
JIF rules!!! Down with GIF!!! Let's get some software supporting this!!!
My guess would be .JPEG, since the 3 letter limitation to extensions is only a relic of the MSDOS past, and most real OSs don't use extensions to identify filetypes anyway...
.JPEG, since [...] most real OSs don't use extensions to identify filetypes anyway"). Secondly, it is mostly tools, utilities and applications, rather than operating systems per se, which identify filetypes using extensions (are you counting ld.so etc as the 'operating system'?)
Anyone care to comment?
Yes. Firstly, either your grammar or your logic is flawed ("My guess would be
Since we have a good, new compression technology, how about some of us slashdotters get together, and make two protocols: A working high-definition CD format, and a DVD-ROM replacement. The high-definition format would probably have regular CD tracks, then compressed audio tracks, on a rock ridge format. So, the CD would work in normal CD players, then stick it in a high-def CD player, and off you go for better clarity. For video CD's, someone else can figure out that, as I don't know squat about movie formats.
What I found interesting was the required HTML: .lwf images in the HTTP_ACCEPT variable - now you're stuck using Javascript to test for support. Bummer.
<EMBED SRC="eisbaer.lwf" width="384" height="256" limit="29491.2" type="image/x-wavelet">
It supports the obvious width and height, and allows you to set a limit on the number of bytes transferred - that kicks ass. It's obviously loading the image progressively, and you can see this happen (with the plugin) if you enter the URL of an image directly into your browser. On the downside, the browser won't report its ability to handle
Barring whatever patent issues there are, it's still quite a nice implementation.
Hi, I have a little background in signal processing/image compression/etc, so I thought I might thrown my 2c in. While I haven't looked at the spec in detail, these are just a few points on wavelet compression v. the 'original' JPEG: JPEG is based upon a variant of the Fourier transform, called the discrete cosine transform. Now, as one of the previous posts mentioned, this class of transforms has poor localisation, and to overcome this, JPEG breaks up the image into 8x8 squares. The coefficients from each block are quantised and arithmetic (or Huffman) coded. This is OK, so long as you don't compress it too much. But as you increase the compression ratio, you get really REALLY yucky 8x8 artifacts - any square that has detail in it ends up looking like a little checkerboard, or full of stripes. Sharp edges develop 'ripples' for a few pixels on either side. Try it and see - the sharp edges of these 8x8 squares form an ugly and very noticable 'grid' in the image. (Also, these are pretty much the same blocky artifacts you see in things like heavily compressed quicktime and realplayer files, etc.) Wavelets are *much* better. It's a little difficult to describe why they compress images so much better without going into the maths, but there are good reasons why the compression artifacts are less bad: First, there's no sharp division of the image into squares, which immediately gets rid of the worst problems of JPEG. Wavelets are kind of fuzzy, so even when you go up to very high levels of compression, the artifacts are much less obvious to the human eye. Wavelets also have excellent localisation, which means that sharp features compress more, without the 'ripple' artifacts of JPEG. How much better compression do wavelets offer? It depends somewhat on how much you want to compress the image - 'somewhat smaller' is about right for high-quality, 'a few times smaller' is probably a good answer for your average quality image, but wavelet-based compression has more 'headroom' in the heavily-compressed end of things, where 'many, many times smaller' is probably a better answer, for images of equal 'quality'. To address the question of efficiency, I'm pretty sure wavelet transforms are comparable or faster than optimised 8x8 DCTs. DCTs and FFTs larger than that are MUCH slower than wavelet transforms. (wavelets are order n in the image size; FFT/DCT are both n log n) On the issue of motion-JPEG2000 being better than mpeg - don't think so. MPEG is clever enough to utilise redundancy between images, so I don't think any still-image compression scheme can even come close. (so no, you won't get your DVDs onto CD-ROMS ;) On the other hand, (IMHO) video is much more in need of wavelet compression than still images, although for video wavelets are only the first step. There is still a hell of a long way to go in video compression. A REALLY long way ;)
WAVELET VIDEO COMPRESSION is FAST (NeXT's NeXTTime in 1992 demonstrated that).
_ _ you probably violated that cat-light patent too. Well there are probably about 1000 mathematical programming patents and only a few cat-light patents holding back society.
Although 10's of millions of dollars have been lost looking for patentable efficient wavelet video compression, and some companies died trying (Captain Crunch chip of Pro Audio Spectrum), wavelet video has always been way faster and more pleasing with artifacts than cpu-hostile DCT stuff such as MPEG.
Steve Jobs showed a 4.5 megabyte file of Lucas's "Wow" montage demo playing from a 486 chip PC clone in wide screen format being consumed at about 400 K sec i think, with stereo 44.1 Khz dolby sound and 10,000 observers in Moscone in San Francisco dropped their jaws simultaneously before eventually bursting into standing ovation.
Since that day i thought NeXTTime would take over the world. It never did. Mysteriously. The NeXT Dimension went with a problem-filled C-Cubed DCT chip and a i860 instead of mostly NeXTTime. And NeXTTime codecs never can to the mac, though i think a decoder is hidden in Rhapsody DR1 powerpc in the player app.
Wavelets are real they are exiting. They do take a little more time to decode thatn some techniques because they are very SYMMETRICAL. For example encoding at 2:1 time instead of typically 63:1 cpou time as with current compression schemes not based on Wavelets.
Wavelets are great for very very low bandwidth because it looks like fuzzy videotape, instead of wierd JOEG artifact cubic shimmering near edges of objects.
Wavelets are the greatest thing ever discovered (or rediscoverred) in math since 1988 or so, but sadly its a patent-filled litigious mess besaddled with snake oil selling fraudulant hucksters.
One time a southern university announced a proprietary video compresion breakthrough, and distributed object code that was quicky reverse engineered and shown to be existing stock wavelet code!
All those fraudulent "fractal" compression companies that went public on the sleazy Vancouver Canada stock market did not help bring honor to engineers trying to make wavelets work.
The hubble telescopre stores stare fields with wavelets (monochromatic). And i am aware of other uses. But only about 7 or 8 different programmers have ever shared public domain wavelet libraries. Dr Dobbs had two nice wavelet articles WITH WORKING SOURCE CODE.
Alas, that was many years ago. Wavelets seem to be discussed about as much as Neural Network code (the BackPropagation Hopfield type and relatives).... ie.. that is harldy at all. Its like a passing fad that never caught on.
Fractal-labelled compression existed. Berkely Systems (AfterDark Screensaver fame) used a 3rd party fractal compresser with thier static slide show Marvel Comics screensaver. But Fractal compression has been a CNN news scam multiple times, otherwise.
I wish NeXTTime was better well known. if so i am convinced thousands of firms would have spent more money trying to replicate the dream.
Frequency compression that preserves both time and frequency information when given more cpu is absent with FFT and FFT is our grandpappy's crap (crica 1954 for computer usage). Wavelets are the most exciting thing i have ever seen and
This JPEG compression trick to add a GPV style intellectual virus into the reference source by requiring patent liscen is repulsive. I hope someone, somewhere, who is well versed in mother functions, wavelets, colorspace perception, etc, will donate some time to help code a PATENT FREEE version of the proprietary scam JPEG 2000 proposal. Maybe the nice guys who work on BSD could bone up on wavelets and help out.
I do not want to have a GPV on my code and i want a simple reference source example i can honestly build up from and happily optimize and contribute BSD-style code back to humanity to share. But if its like the 4 different patents that infest teh ridiculous MPEG-4 audio AAC stuff, then ISO and IEEE etc, need to adopt a strict definition of prepetual cheap or free patent liscensing for ENCODING AND DECODING and not just decoding.
This kind of cocktease just makes me mad instead of happy, because it means more delays in the world benefiting from wavelet compression. Of course wavelet audio compression is needed for mp3z collecting, much more than ho-hum static image wavelet compression implemetations such as bloatware clouded-up JPEG is needed by mankind.
This announcement looks like its about one year premature, and the crap thats downloadable today looks like a race to make money of a proprietary codec. No thanks. Keep yOur image destroying digital fingerprint fascist crap out of my eye space. Photshop 5 was slowed down to scan every file opened for copyright infringement hinted at by watermarks.. as if that app is not slow enough with its long history of insane file formats and pathetic 32Kilobyte file read requests.
When i get this mad i seem to ramble on a million topics... and get quite tangential. Sorry about that. Lets start a new source tree and in 3 years i bet we will get firsther than the JPEG 2000 attempt and we can make it fast and free! what do you think? Maybe the concept of programming itself is patented so maybe we can't program anymore in the US though. Hell this ACTUAL patent for playing with my cat I have violated routinely http://www.patents.ibm.com/details?&pn=US05443036
ARRRGHGHGHGHGH! >
Open standard, lots of whining for support and zero open source development. And microsoft is laughing all the way to the bank.
If there was money to be made selling individual software licenses for the linux platform somoene would step in... but the big ones dont even try cause of linux hostility to commercial software. (and the rest of the free OS's dont really count, no user base to speak of) And the common saviour for handy app's, shareware, has never worked in the open source OS world.
Free software (in either sense) doesnt work for everything, and the biggest hurdle for open source platforms is their anomisity to other forms of software... for some kinds of software the only way it gets written is if somoene ends up paying for it. Not support, not porting, or any of the other oft quoted open source way's of making money with software... just good old buying a single copy with full copyright restrictions intact.
Maybe RH&VA can spring in with their hoards of Ill gotten booty to fund what otherwise normal developers would do on their own... but since there wont be a big tangible pay off from open source development I doubt their investors would appreciate it.
If movies become this cheap to distribute on the net, the same thing will happen to them that is happening to music. Music is starting to break free from the recording industry. Movies will do the same from the big studios. Yes, they will still make money on the really big productions. But it is going to become easier from small film makers to tell their stories. This was inevitable. The price is falling on communicating your ideas to the world in many forms. I wonder how it will change our world in ways that we haven't even guessed.
Thats what you get when you combine X's middle button pasting, a slightly dodgy middle mouse button and not previewing your comments
:|
-Yarn - Rio Karma: Excellent
They have a patched version of XV on their page, and I've been playing with it for a bit. Its almost lossless at 25:1 compression on a Q3 screenshot I have.
-Yarn - Rio Karma: Excellent
In this case, um... Lucas has me especially baffled. I didn't see any mention of intellectual property above, just of a technical standard that would allow packing more data into a given amount of bandwidth or storage capacity.
I would think the biggest market for such a thing, if applied to motion pictures, would be the manufacture of lower-cost video players, not movie piracy. The ability to pack a movie onto a CD would allow movie distributors to bring prices on their product down to the point where piracy simply wouldn't be worthwhile.
If you're going to extrapolate effects of this technology, I'd say it would be better to look at what it could (potentially) do to the video rental business, not how it could be used to steal intellectual property. I mean, if you could *buy* a movie CD for $7 or $8, who'd rent one?
- Robin
> drop the patent (I don't know if this can be done)
I am not a lawyer, but a patent can be "dropped" quite easily. Once the patent is active, its owner has to pay an annual fee, which is pretty high if you want the patent to apply world wide ("world wide" = in those countries where 95% of the global market is). If you don't pay the fee, the patent is no longer valid. This is actually done very often, because usually after 5 - 7 years, upholding a patent is not worth anymore. Either the technology is outdated, or some new patent has made the old one obsolete, or the revenues from licences with other companies no longer cover the costs - there are many reasons for dropping a patent.
For instance you can't losslessly compress white noise using any known method.
This sounds flat out wrong to me. You can take white noise and apply a Huffman scheme to it.
Fundamentally you are always limited by mathematics: if you have a 1 to 1 matching function, your domain and range must be the same size. A lossless compression scheme is a 1 to 1 matching function, mapping the original image data to a unique "compressed" image. So you're stuck. Now, most images that we're likely to compress have the sorts of patterns that allow us to do some compression, so generally we don't have to worry about that.
What is often missed regarding lossy compression, however, is that that nature of the loss is very significant in the perceived quality of the compression. For example, one problem you often see in compressed video is changes in parts of the image that shouldn't change: the viewpoint is still, a wall is still, but compression artifacts on the wall are different from frame to frame. Software that evaluates the effects of losses on an image, taking things like this into account, would be good -- as would compression software that does likewise.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Well as far as I know, the DCT is hundreds of times faster than the wavelet transform. Compare the CPU usage during mp3 compression to the CPU usage during noise reduction and you'll see the mp3 compression infinitely less intensive than the noise reduction. The heart of the noise reduction filter is a wavelet transform. Mp3 compression uses a DCT plus FFT. When they switch to wavelet based compression you can forget about making movies in software. Nevertheless if they offer a no-cost implementation Linux will be the first platform to support JPEG 2000 in Quicktime.
Basically, .mp3 will do fine until something better comes along that's supported... then it'll go the way of the LP, the 8 track, etc. For support, all one needs to do is get the major players onboard (nullsoft, real, the xmms gang and maybe mung$oft) and everyone else will pick it up for fear of being left behind.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
"People will pay big bucks for the luxury of ignorance."
hehe...
:)
:) yes, cowboyneal *could* store all his porn in his vram :P
;)
we need a hardware decompressor for this... so we can put it on a video card and do 200:1 texture compression
if the decompressor was fast enough, just think, it would be a way around the bandwidth current bandwidth limitations... if you can transfer blah gigs of data to your videocard 200 times quicker, that leaves quite a bit of time to do decompression of it and keep up (or be faster with later implementations..)
hrm.. 200x32meg = 6 gig of textures
smash(err.. i assume he has less than 6 gig... or he needs help
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
maybe this is why the paranoia about people copying DVDs is so great ;)
.. maybe what.. 10 to 1?
;) copying to CD would be basic.
lets say we have an 8 gig dvd. assuming it gets average mpeg compression
8 gig = 8,000 mb / 20(20 times better than 10:1) = 400mb.
still not quite 0 day warez, but the modem download time would be mere days as opposed to weeks
besides, i am pretty sure you could get way better than 200:1 on motion video... if you compare the quality of mpeg stills to jpeg stills, mpeg is much more lossy... because it moves you notice less.
interesting...
smash
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
White noise, by definition, has no redundancy.
:) looking at it on a byte by byte level (1 each for RGB), each byte can only have 256 different values, so if you have more than 256 pixels, at least 2 of them must have the same value.
:)
hmm... by that definition, I doubt you would get white noise in many pc files.
the reason for this would be quantization (i guess):
for example, say you have an image file greater than 4000x5000 pixels in 24 bit color. that is 20 million pixels. 24 bit color only allows a total of 16.7 million colors, so at least a *couple* of the pixels must be redundant
in the "real world" you could definately get white noise... but due to computers being digital, there is only a maximum resolution you can work with...
smash (over-tired... hope that made some sense
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Well, naturally they had to convert all three results (including the 3 meg original) into 256 gif (or better yet, jpeg uncompressed)
:^)
because I doubt your browser can show JPEG2000 files. They had to put the results into a framework you could see.
Naturally, no, not in my case either, but it can display 24-bit JPEGs and PNGs. There's no leap of logic that can explain why the image had to be converted to an 8-bit gif (unless, of course, you're afraid that someone will connect to EE Times via an old copy of Mosaic
Stating on Slashdot that I like cheese since 1997.
...add it to imlib? So we can use the images in X and X alone??? Why not use the software NOW? It's there, for download.
Stating on Slashdot that I like cheese since 1997.
what characteristics of full-color images makes them especially susceptible to wavelet compression, versus say, a text file or an executable binary? :)
I'd guess perhaps the fact that it's OK to perform lossy compression on an image, and that people see image compression as 'good' if most of the main image features are there (that is, good enough that a human observer won't immediately notice a difference). You wouldn't be too happy, I suspect, if you decompressed a text file and found that gzip had trimmed it down to something resembling Cliff Notes
Daniel
Hurry up and jump on the individualist bandwagon!
You forgot to mention that there is a version of the free MrSid viewer for Linux. My whole State's [NY] recent aerial photos are being distributed in this format.
www.lizardtech.com
2.LICENSE
The LuraTech Software Product are licensed to users, not sold. The license issuer retains the right of use of the enclosed software and any accompanying fonts (collectively referred to as LuraTech-Software-Product) whether on disk, in read only memory, or on any other media. You own the media on which the LuraTech-Software-Product is recorded but LuraTech and/or LuraTech's licensor(s) retain title to the LuraTech-Software-Product. The LuraTech-Software-Product in this package and any copies which this license authorises you to make are subject to this license.
Eyewww.....
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
If Redhat turns around and buys LZW for $20m from Unisys, then Redhat is just justifying software patents, which are a Bad Idea.
InThane
For those interested in code: you can find the GPL'ed C++ code for performing integer wavelet transforms I (and a few colleagues) wrote for my Ph.D. at http://www.cs.kuleuven.ac.be/~wavelets/
That was pretty much about time someone took the wavelets into image compression.
:)
I worked with wavelet transforms (Daubechies wavelets) a year and a half ago, and back then it was pretty clear that it would be possible to compress images and sound much harder using the wavelet domain rather than the Fourier domain.
For those who don't know, the trick is:
JPEG/MPEG/MP3 uses Fourier transform to transform the image/sound data into their spectral components. But this spectral representation of the data does not say anything about the _locality_ of the frequency components. Therefore representing spikes/discontinuties will require a very large number of frequency components when using Fourier domain, which in turn leads to poor compression. You can see this problem by drawing a few sharp lines in an image and compressing it hard with JPEG.
Wavelets on the other hand, represent both an equivalent of the frequency component, along with locality information. Spikes/discontinuities can be approximated well using only a few wavelets. This in turn leads to good compression.
Another nice thing about wavelet compression is, that wavelets tend to represent discontinuities well, even with hard compression (eg. a lot of missing or roughly approximated wavelet components). Therefore a very hard compressed image will still have fairly sharp edges, completely contrary to JPEG compression. This is pretty important if you compress a picture holding text.
Anyways, someone is now working on JPEG with wavelets... What about sound and video ?? There is no reason as to why wavelets should not provide equal improvements in both audio and video.
My personal conspiracy theory is, that there exists a *LOT* of expensive hardware that can do Fouries forwards and back to allow real-time encoding and decoding of MPEG movies in good quality. The companies producing these devices will lobby any standards-organisation to *NOT* consider wavelets and stick to good old Fourier. If this holds, it will take a few years until we see Wavelet compressed video
Since the comparison in the EE times article is so useless, I decided to do my own testing. I started with the JPEG2000 applet on the NexImage site, and the example they gave there.
:)
I found that the comparison on their site was biased rather strongly in favor of JPEG2000, in two ways. First, their JPEG encoding for comparison was notably inferior to libjpeg 6b with Huffman table optimization. Second, the comparison at very high compression ratios is not particularly meaningful. When compressing at 96:1, there is virtually no image detail present above half the original image resolution. Thus, scaling the original image down prior to compression (the usual practice with JPEG images) produces good results with standard JPEG.
When these biases are removed, the quality gap between JPEG2000 and JPEG narrows substantially. JPEG2000 is somewhat better, most noticeably in its relative lack of chroma bleeding, but the margin is quite slim. My recommendation is to make up the difference by using a little more bandwidth and/or storage.
I've prepared a summary of these results, with example images, on a comparison page. The page is on the slow side of a DSL, so please be gentle
LILO boot: linux init=/usr/bin/emacs
There's an enlightening discussion of JPEG2000 in the gimp-devel archives. See the or iginal question posted 9 Dec 1999, as well as the followup, particularly th is reply by Nick Lamb.
LILO boot: linux init=/usr/bin/emacs
Maybe I'm just being too cynical, but I think that one of the major points of the JPEG2000 effort is to fix the "bug" in the original JPEG (or at least the universally implemented arithmetic coding-free subset) is patent free.
And basically, I agree with Tom's assessment here. While JPEG is far from perfect, it is "good enough" for photographic images, and the massive increases in bandwidth and storage capacity kinda make high compression ratios irrelevant.
Finally, a 200:1 compression ration is pretty meaningless without some kind of context. A much more meaningful comparison is how many bytes are required to get the same quality image as some other compression standard, such as the original JPEG. The figure itself reminds me of when Triada was hyping their 200:1 lossless compression. Joe Bugajski gave a talk on this at Berkeley, and started waxing raphsodic on the incredible stuff that the Library of Congress had in their collection. Books and audio materials were fine, but when he got to the Stradivarius violins, my fellow grad students just broke up laughing. It's not hard to imagine 200:1 compression of that, but uncompression is tricky at best
LILO boot: linux init=/usr/bin/emacs
The comparison in the EE times article is rigged to the point of almost being faked.
Basically, what they did is take a high resolution image and compress the shit out of it with both original JPEG and JPEG2000. Yes, JPEG does poorly at such high compression ratios.
What they neglected to point out, however, is that you can get excellent results from just shrinking the image. From what I can tell, the test image is displayed as a GIF shrunk 3x from the original "3 MB" image. A very reasonable thing to do, if you want a 19k target file size, would be to first shrink the image 3x, then compress it 17:1 using plain JPEG. I tried this, and got results entirely comparable to the JPEG2000 example (the problem with my informal test is that the GIF dithering artifacts are noticeably softened, which is basically a problem with the fact that they presented the image as a GIF instead of true color).
So the bottom line is that JPEG2000 performs a lot better if you're doing something stupid with it, but take the claims of dramatically better compression with a grain of salt.
LILO boot: linux init=/usr/bin/emacs
Actually all European DVD's I have seen have AC3 5.1 audio.
I'm still an undergrad, a dangerous state: not educated enough to really know what I'm talking about, but educated enough to think I might. ;-)
Anyway, I'm curious: I understand that current JPEG uses Fourier transforms (a full integral transform, or a Fourier series?) to get a spectral representation of the image data, then drops subtle information from that transformed data to get a similar image from the reverse transform.
So I assume the new JPEG (aside from all the quicktime-esque formatting overhead) uses the same technique, just with a different complete set of functions, the wavelets.
So my first question: is there anything about the above that I'm misunderstanding?
And my second question: What are wavelets? Bessel functions? Something I haven't heard of? Is there a simple formula, or a simple ODE generating wavelet solutions, that I could look at or plug into Maple? I gather that whatever they are they approximate discontinuous functions with much better convergence than sines and cosines... but that could describe a lot of things.
If you can't compress an 1MB TIFF (uncompressed) to a smaller JPEG than 800kB, you have a problem. For those ultra-high quality things you'll never need anyway, try changing your subsampling options, if your JPEG software can do it (GIMP 1.1.7 (?) and upwards can).
Remember, MJPEG (which is basically only a lot of baseline JPEGs streamed together, optionally with some audio and hooks for hardware cards) usually compresses 3:1 for broadcast video (perhaps slightly more, if your TV station is really big).
/* Steinar */
(This comment is of course GPLed.)
As I said, you should check your software. libjpeg (and thus cjpeg, and to a lesser extent the newer versions of GIMP) has some nice `wizard' switches that may help you a lot. Again, I won't believe you until I actually see a real-world example (and not the stupid GIF that was in that article).
/* Steinar */
(This comment is of course GPLed.)
First: The page you give me doesn't have anything to do with JPEG2000, it's some kind of proprietary wavelet compression (even worse than JPEG2000 with all the patents it _perhaps_ will have :-) ). Second, since I don't run Windows, I'd be happy if you mailed me the BMP image (possibly gzip or bzip2-compressed) -- thanks.
/* Steinar */
(This comment is of course GPLed.)
IIRC, when the original JPEG standard came out it specified how to compress images, but not a file format to store the compressed data. So there were some JPEG programs that wouldn't read or write files produced by other JPEG programs, because the file format was different.
Eventually people created the JPEG File Interchange Format (JFIF) and this is what modern 'JPEG' files are stored as. I hope the standards body has given some thought to file formats this time round.
-- Ed Avis ed@membled.com
Okay, it has been shown that CSS does nothing to protect copying, per se, of DVD content. However, it does prevent format conversion, and arguably this is what the DVD CCA is most worried about.
If a DVD can be decoded with DeCSS and converted into mjpeg2 with mp3 audio, the result could possibly be stored on a single CD-R. This would make content copying considerably more convenient and less expensive than having to use DVD-R.
By no means does this justify any injunction against DeCSS, but it does prove RMS' maxim, "information wants to be free". Ultimately, it will be.
Copyright cannot be enforced by technical means, it has always relied upon good faith, combined with legal remedies against those who are caught in violation. Nothing prevents me from taking apart a copyrighted book, scanning it page by page, and reprinting it or transmitting it electronically, except my ethics and respect for law.
DVD should expect nothing more, nor less, than the same.
Peace and love, y'all
Compiled binaries can indeed be compressed.
However the compression technique has to "understand" your binary, wavelets would not be a good choice.
Just so that people understand. A compressed file is a concise description of the original file. A compression technique is an agreed upon way of describing things. And, just as you would use different methods of description for describing a book and a painting, different compression techniques are appropriate to each kind of signal.
And to clear up another piece of confusion. Lossless compression means that you have a complete description, you can recover the original exactly. Lossy compression means that you have an incomplete description. You have a description of an approximation of the original, the distinguishing details got filed in the circular file.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Anything is as compressible as you want with lossy compression. :-)
That said, our visual perception of white noise is itself a highly lossy form of compression, therefore it is easy to fool.
Incidentally wavelets are widely used for "denoising" because they are able to handle both smooth regions and sharp boundaries. Therefore they are much better at concentrating the sharp edges into a relatively small number of big components, so that you can distinguish a sharp edge from white noise. Fourier transforms don't do a good job of telling the two apart, and are therefore frequently unsuitable for denoising.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
It doesn't matter if some of the pixels match if which ones do is random, so it is at least as hard to specify per pixel what it matches as it is to say per pixel what it is.
Understanding it that way could be complex, let me give the direct definition for a binary signal.
A source of a stream of 1's and 0's is a white noise generator if each digit is randomly (50-50 odds) and independently a 1 or a 0. The resulting signal carries the maximal information/pixel possible, and hence there can exist no compression method that is an overall win in compressing white noise.
What does this look like? Start tossing a coin and record what comes up! (OK, that is not perfect but it is close enough.)
As an image it looks like..static.
When played, the noise sounds like..static.
Any signal with a large amount of information/bit looks like white noise and hence looks like..static.
It is a fundamental fact of information theory that white noise (which resembles static) is identical with a perfectly encrypted signal is identical with a perfectly compressed signal.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
White noise, by definition, has no redundancy.
:-)
Many things that look like white noise are not, but white noise itself?
Incidentally static is what white noise sounds like, and any efficiently compressed signal looks like white noise, which is why a modem sounds like static.
Another interesting fact - a compressed file is a pretty good source of random data, and a compressed encrypted file is substantially more secure than a file just encrypted with the same algorithm. OTOH an encrypted compressed file is a PoS. The encryption messes up the attempted compression.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Check out DjVu (pronounced deja-vu) by AT&T.
It compresses a high resolution full color scan of a magazine page by 1:200. And I am talking about real-life performance here, not ideal cases.
The trick is an algorithm which automatically separates text and line art from continuous tone images and compresses each one with a different algorithm. The continous tone algorithm is wavelet based, of course. This is mentioned in the JPEG2000 article as a possible future extension but DjVu has been doing it for almost two years now.
They have a Netscape plugin for viewing this stuff and the compressor is free for noncommercial use. It supports linux and many other operating systems.
There are many compression schemes better than JPEG being promoted by their inventors. I believe JPEG2000 will probably be the winner for a very simple reason - the name JPEG.
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Looks sweet.
We need to get support for this in gimp, ee, etc...
It'd be cool if these beat commercial packages to the punch.
Hang on, isn't that a 256 color GIF they used for the comparison?
Yeah, I noticed that too. Kind of like those TV ads that show an HDTV picture... they don't look too impressive on my ordinary TV set.
My guess is that they used GIF so they could control the color palette and make the presented images appear to approximate the image appearance. In other words, it's a demo.
--JT
I thought this article might be a good place to mention AT&T's DjVu image format. I have been working with their DjVu tools to develop quite a few web applications and they are phenominal. The format takes an image (it is designed for scanned documents) and creates an IW44 (wavlet compressed) background layer of the image and then creates a non-lossy overlay foreground layer to compress foreground components like text and lines.
The net result? 300 dpi full page scans in under 50K! When you print them, they are true enough to the original to justify the difference between a 5MB TIFF and the 50K DjVu.
I'm very glad to see some of the same technology being adopted into JPEG. I'm kind of dissapointed that the spec doesn't seem to allow the mixing of compression algorithm's inside of one image, which is what most all of the very very good compression methods seem to rely on -- the fact that different information in the same chunk of data can be optimally compressed in different ways. I mean, depending on the image, JPEG in some cases can smear wavlet-based methods into the dirt.
Just some food for thought...
~GoRK
When IE-whatever supports JPEG2000, I'll move to them on my website - but only 'cause I don't have to make a living from it.
The article states that jpeg images use the fourier transform. They don't. Jpeg images use the discrete cosine transform (DCT).
-Erik -- --This message was written using 73% post-consumer electrons--
Here is why it hasn't cought on. The C code to decode an animated GIF89a is about 600 lines (14kB) including all the file handling and error checking. The memory overhead beyond the resulting pixels is about 1.5KB, 1KB of that being the RGBA colormap. Adds about 10-15kB to your resulting executable code space.
The code for zlib, which is only a part of .png is 9k lines (309kB), and the libpng code is another 23k lines (798kB). Memory useage is rather large, and the executable swells just a wee-bit. Sure it has all kinds of nifty extentions, but it's all just a block of pixels in the end.
Some of us still think about things like memory usage and code size. And dont forget at least a few bugs in all that code.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
If you mean Starfleet Academy, those cut scenes looked pretty dire (the colour was terrible).
Consciousness is not what it thinks it is
Thought exists only as an abstraction
The inventor and holder of the patents for fractal compression is Iterated Systems.
I'd thought they'd had these techniques rolled into JPEG and MPEG already but it looks like you're right, they've kept the techniques for their own products.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
I remember reading about fractal compression, which was supposed to blow JPG away. It was in the early 90s, and obviously it didn't have much effect on the industry.
Because the inventor held onto the patent too closely. Fractal compression works... encoding is horribly slow but decompression isn't too bad at all. Compression ratios are amazing, better than wavelet I think. But if the inventor ever wants to see it in widespread use, he has to let go and make it free.
*sigh*
Life's a bitch but somebody's gotta do it.
There are some examples using a java applet to render the actual jpeg2k image clientside, which makes for a more impressive demonstration.
http://ltswww.epfl.ch/~neximage/de coder/applets/ They're very slow, though.
I might be jumping to conclusions here, but... The only point to data being digital is that it doesn't lose quality as it's being copied. Therefore, you'd really not want to put a VHS tape on to a CD, if you could help it. Which would mean that the real market for such a format - (Motion JPEG2000) - would be for transfering video from DVD to CD. That fucking sucks...
Yeah, DeCSS needed to be created so that Linux users could watch movies, but now witness the rush to create a method which enables people who don't own DVD players or DVD discs to be able to watch DVD on their CD drives. And everyone here said the all that DeCSS was solely to enable the viewing of movies on Linux.
I'm only ranting like the because that seems to be obviously what Roblimo or Polo meant when they mentioned the fitting of a movie onto a CD. Seems no one here respects IP anymore... Yet they don't criticize themselves, or their forum. Just others. For instance why isn't slash GPLed? Because IP is real, and there is value to it... Just as the movie industry puts up huge amounts of cash in hopes that they can convince the customer to see a movie, Rob had been donating his time until the IPO to make this site as it was and knows that if anyone could use his SW, he'd be at a competitive disadvantage... he'd essentially be doing R&D for potential competitors...
Whoops... Didn't mean to go that overboard.
END OF RANT.
I find it strangely disturbing that the ISO would resort to year version numbers. Aren't they supposed to be one of the few non-commercial, 'above the hype', good-of-the-state-of-the-art entities out there?
-- What you do today will cost you a day of your life.
For instance you can't losslessly compress white noise using any known method. This sounds flat out wrong to me. You can take white noise and apply a Huffman scheme to it. (Emphasis mine.) Compression works by recording patterns instead of writing them out each time. If the data doesn't have any patterns, it is changed slightly so it does. But this changing is lossy and that's not what we're talking about. By definition, white noise doesn't have any patterns. If you run it through a lossless compression scheme, you'll get the same data plus the compression overhead. So TimoT is correct. Lossless compression of white noise is impossible. cheers, sklein
You still use bitmaps for that? Why not PNG? With PNG you may not even have to keep a separate master copy. Welcome to the present!
cheers,
sklein
Hang on, isn't that a 256 color GIF they used for the comparison?
Anyway... it sure looks promising, but I'm not really impressed by that 158:1 result on this particular image, most of it comprises of a gradient that should compress rather well with their scheme. I'd like to see results with images containing more detail.
-W
Last year, wasn't there some Australian guy who claimed to have developed a codec that could send DVD quality motion+sound over a 56k modem?
It was on slashdot, but I can't find it in the article history. It was also published in many computer magazines and newspaper articles.
Obviously, it was a hoax - but he got quite a bit of capital from investors. What has happened to this guy?
While these extensions (whatever they happen to be) may be useful, people need to understand that they will be useless for interchange. Graphic file interchange is a big deal these days, thanks to the Internet, especially the WWW part of it.
Over the last 5 years or so, the average cluefulness of Internet users has drastically fallen. We have seen people email MS-Word documents, and many (most?) web pages are written by people who use Netscape's and Microsoft's markup languages and extensions, instead of just HTML. In other words, when Joe Average sends data to Jane Average, he doesn't stop and think -- he just sends the data in whatever file format that he use internally. Then it's Jane's problem, and if she can't read it, she's told to just "upgrade" her software.
I am concerned about the aforementioned royalty-based extensions. There's a certain company who is infamous for their embrace-and-extend strategy. All they have to do is bundle some content creation software with their operating system and web browser, and have it create these "extended" JPEG images, and they will have a good way to inhibit interoperability.
And since the new format will be called JPEG instead of something new, the attack would be pretty stealthy and hard for Joe Average to understand.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I haven't bothered checking out the spec in its entirety, but I've got to wonder about a few things:
1. Is the 2:1 5/3 'mother wavelet' truly lossless for any and all inputs?
2. What kind of 'average' compression can we expect? One poster already mentioned that the example had a simple gradient as a background which would certainly compress well.
3. How CPU intensive is it to decode these things? Will MJPEG2000 (or whatever) practically require a hardware decoder for DVD-quality playback?
Anyone care to comment,refute, or otherwise flame? *g*
I'm no expert, but I've been working with the FFTW - "the Fastest Fourier Transform in the West" - and it's really kick-ass fast. I've been wondering what kind of FT algorithm these image-compression guys tend to use. I figure, a faster FT means less time required to compress and decompress data, which in turn means that more detailed data that once was unfeasibly large and slow to process will not cease to be large, but may cease to be slow. May this yield a feasible alternative? FTs are "the workhorse of DSP" - a very well-known and familiar technique. So why not? (I'm sure there's a damn good reason why not...)
To the editors: your English is as bad as your Perl. Please go back to grade school.
Wavelets CAN be theoretically best, depending on the type of the information. Each basis is best at encoding things that look like the basis vectors: thus the Fourier basis is best for encoding sine waves. And for pictures that have localized bumps (like most normal pictures), wavelets that have localized bumps will do best.
Oh, and best here can be rigorously defined: just plot mean squared error vs number of components. The lower, the better.
Also, there are fast wavelet transforms. In fact, some of them are O(N), rather than O(N ln N) as for the FFT. Again though, depends on the wavelets that you're using.
Movie piracy is already fairly rampant. At least among those of us with high speed connections. (2.5 mbit adsl, 5 IP's, 5 emails, $65CDN/mo, kicks ass!) You can get pretty much any new movie a few days after it comes out in theatre, usually in ASF, MPEG or AVI format. Normally a 1.5hr movie comes out to 350-400 megs in .asf format, but you can sometimes get high quality mpeg versions that end up being 800m-1.2g, which sucks because then they have to go on 2-3 cd's. They're all pretty low quality, alot of them are just some guy videotaping the movie in the theatre with a camera, but hey... ya get what you pay for eh?
Wavelets work in a similar fashion, using the wavelet transform. The difference is that wavelets are localised in space, unlike frequencies which are infinite sine waves. Thus when you forget the low coefficients and only save the highest wavelet coefficients, you can still retain things like discontinuities and local detail. The wavelets representing the local discontinuity have high coefficients and so are kept. In the frequency domain (used in Fourier transforms), discontinuities have components in all frequencies. When JPEG filters out the low coefficients, sharp discontinuities become blurred.
This is very cool to see wavelet compression start to move into the mainstream. One application already in use: the FBI uses wavelet compression to store fingerprint data (source: Wavelet Toolbox for Matlab documentation). Another common application of wavelets is removing noise from signals. Standard frequency filtering removes the noise and part of the signal. Wavelet de-noising can remove just the noise (it's really pretty amazing). I had an internship at the University of Washington where I used wavelets to remove RF interference from experimental physics data.
-Nathan Whitehead
I have writen programs to test compression using FWT, and I have some disagreements with other coments:
I think that should be noted that computing the Fast Wavelet Transform (FWT) is realy a lot slower than the Discrete Cosine Transform (DCT) in current hardware.
The reason for this is that current compression standards (as JPEG, MJPEG (not realy a standard), H261/H263, MPEG1/2) compute the DCT in blocks of 8x8 pixels needing very few multiplications and aditions (on the order of 150 per block, 2.5 per pixel), and also exploiting the locality of data (64 pixels fit in the L1 cache of almost all current CPU's).
On the other side, the computation of the FWT to be realy effective in image compression have to use block sizes larger (I think that 32x32 should be the minimum), having less locality of data, and needs about 4 multiplications per pixel using a 5 coefficient filter. (the number of coefficients in the filter affects the "blockiness" of the transform, with 2 coefficients you get a very blocky image, in my experience you need at least 6 to compress effectively "smoth" images).
The only advantage in the computation of the FWT is that the code is very regular, so it is easy to write it using MMX, 3DNow or SSE. But stil it isn't as fast as an 8x8 DCT.
For stil image comression this isn't a problem, but if you want realtime compression and decompression, you are at trouble.
Also, in Video compression you have to exploit the motion redundance, so it is fundamental that a "motion compensation" stage be applied before Transform coding. This stage is ussualy the slowest in video compression.
In other topic, I did test FWT in audio compression, but it was before I learned about physicoacoustical models... so it sounded very bad at same rate as audio mpeg layer 2.
The audio mpeg compressors use sub-band filtering for band separation and FFT (fast fourier transform) only to determine based in the physicoacoustical model the best quantization factors on each sub-band. In mpeg layer 3 a DCT is used to separate bands (giving better resolution to the quantization).
In theory FWT can be used instead of the sub-band filters, as they are very similar, but I think that it won't be any advantage.
Seeing a story like this makes me wonder what the time lapse is going to be between the time a standard is issued and the time it can actually spead into wide usage. Look at PNG, which has been around for around 4 years now. Sure, some people can view PNGs in their browsers, but support is still imcomplete in most implementations despite its both technical and legal improvements on the ol' GIF format. Its still not to the point where a mainstream web site would want to use it for fear of shutting out some users.
Lets see here you need updated graphics programs (I'm sure GIMP and Photoshop, et al can have this fairly quickly). You need updated browsers (should be rather easy for Netscape/Mozilla, and technically not to difficult for IE, depending on whenever MS wants to get around to it). I'm still thinking 2 to 3 years before you seed wide usage, which is unfortunate becuase the big advantage is for those of us still stuck using lousy POTS lines to connect to the internet. Ironically, those who would get the biggest benefit from this (like be on this on-a-good-day 28.8 line) will probably have broadband access of one sort or another by the time it becomes widely used for the web at least.
Then again, the whole 28.8 to 56K changeover seemed to happen rather quickly and both required upgrading your hardware, and a dueling set of standards....
DrLunch.com The site that tells you what's for lunch!
The compression on DVD is relatively low (MPEG2 based). I believe a DVD video could be recoded to the Wavelet sheme without a big quality loss and still fit on a CD-ROM.
dude, if you going to be pirating anyway...
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
I found that out. I guess thats what I get for posting at 4 am or whatever...
And I don't have that much karma, only 31 points right now.
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
music is made from waveforms. What you would see on an ocilliscope if you were plaing the audio. It has nothing to do with wavelet technology, witch only applies to images and video
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
DVD disks are not anymore exspensive then CDs.
The only diffrence between the two is the laser used. DVD drives cost about the same amount. In anyevent, DVD moves cost about as much as audio CDs, so I don't see why putting movies on CD would make them any cheaper.
"Suble Mind control? why do html buttons say submit?",
ReadThe ReflectionEngine, a cyberpunk style n
The best thing to do if you want something supported is to create a free library written in C like IJG did for normal JPEG. Almost everybody is using their code because it's stable and portable.
That way, all browser creators have to do is link it into their project... At least that works for an additional image file format decoder.
This makes me wonder: What is the "right" extension for JPEG files? .JPEG, .JPG, .JPE? I've seen all of them.
.JPEG, since the 3 letter limitation to extensions is only a relic of the MSDOS past, and most real OSs don't use extensions to identify filetypes anyway...
My guess would be
Anyone care to comment?
I strongly believe that trying to be clever is detrimental to your health. -- Linus Torvalds
I haven't seen any discussion here of Geographic Information Systems applications, so I thought I'd chime in.
We've been using MrSID compression on an environmental information system. We've been using sat photos as base layers on maps, and plotting data on top of the map. MrSID is a wavelet compresseion system that is now supported in several commercial GIS packages.
There are three really cool aspects of wavelet compression.
First, there is the raw compression; 10 or 20:1. Since we work with satelite photos of entire counties, these can easily be well over 200MB per image. Keeping a bunch of uncompressed images around is pretty awkward, and normally you need a number of them (different seasons or months, leaf on leaf off; black and white/infrared; etc.) With this kind of compression you can burn a pretty comprehensive library of images onto a CD.
Second, there is speed. You can open up a map of a good size county, and the image loads very, very quickly, but looks very sharp, because it throws out detail too small to be seen. As you zoom in, it clips out the region you can't see, and brings in another level of detail, so the map repaints and still looks sharp. You can easily start with a map 100 miles across, then zoom down to less than a mile across, with individual buildings easily recognizable. With uncompressed images, you could not use the same image to cover the wider geographic areas because display would be very slow. It makes for terrific demos -- being able to zoom from an astronoauts view to the view from a small plane feels like you've strapped on a pair of seven leage boots.
Finally, there when you go beyond the zoom level where there is no more data, instead of getting sharp pixel boundaries you get smudgy edges -- like you are a little out of focus. This is less distracting and more intuitive than seeing large, blocky pixels.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
could someone give a terse overview of what Wavlet compression is? I'm curious as to how it succeeds in producing such high compression rates.
fractals and wavelets have been proven to be mathematically similar to one another.
i read this somewhere a while back... dont quite remember the link.
Yow. I just finished reading the dvd thread then this pops up. DeCSS aside, could this do for movie piracy what mp3's did for music?
OTOH, it could also be a boon for home or low budget movie makers.
P.S. I could claim "first post", but that would either be wrong or obvious.
Ideology is for ideots.
huh ? Thats total bullshit. my website uses PNGs and displays find with an image tag on netscape 4.7 (Solaris, NT, Linux)
Ha ha. That sample image is composed _entirely_ of gradients. It would be nice to se some results from a standard image. Most of the work I've done is in video compression, but we always used a set of standard images. Lena, Suzie, Mother + Daughter, and the news crew. I'm sure the still picture groups have a standard image set too.
I created a still image compression program for the IOCCC about a month ago. I didn't have access to any standard images so I used this one.[1] It has gradients, steps, fine textures, and most everything else you could want, except color.
[1] Thanks to Phil Greenspun and his great photo site. He is a photographer and a CS professor at MIT. See his work at Photo.net
Ryan
Oh ya, you da man! You figured it out ;)
Try to imagine the top image in 1200x800 instead of 400*267. Then try to imagine taking that 1200x800 image and compressing it to 19kb with normal jpeg (still with a size of 1200x800). I think you'd get something that looks like the bottom image (if you can just try to imagine that image too in 1200x800).
// C
So when is this expected to become mainstream? I mean, I'm guessing it'll be released later this year for people to start using, but when will most browsers start supporting it and it becomes commonplace? It sounds like a really cool piece of technology though, I've been waiting for it for a while.
I am blindly posting this without first trawling through other posts or going through the web on a research tramp, so take it with a grain of salt.
You can think of all things as functions. An image, for example, is a function of two variables, x and y, which give a pixel location. The function should return a color, and perhaps an alpha value. Fundamentally, one should be able then, to simply write down the formula for an image on a napkin. The image can then be generated by simply filling in the formula over the domain (width and height).
In practice, however, it is very difficult to derive this function. So we must approximate until it is close enough. As I see it, this is basically what wavelets do. They approximate the function with a series of trigonometric wave functions.
If you think about movies, now, they are just really frame after frame of images. So you simply have a three-variable function: x, y, and frame #. Theoretically, you should be able to reduce a movie to a function also. and just feed in three variables and be able to render an image.
I guess you could also represent images and movies as functions which returned matrices. You could probably do some nifty mathematics which would account for areas which stayed the same and would not have to be changed again...essentially 'masking' the new image over and over again with new image matrices.
Anyway, that is my take. It might not be perfectly accurate, but I've always thought of images, and movies, and data in general (the same procedure can be performed on arbitrary binary streams), as simply functions of position.
Jazilla.org - the Java Mozilla
It's 10 PM. Do you know if you're un-American?
Actually, a "white" random process (a series of random variables) is defined as being "uncorrelated" to some order, usually second-order. If samples are non-Gaussian, then they can be "white" but still be statistically dependent. Compression would still be possible.
(Reality reasserts itself sooner or later.)
There is no optimal image compression
This is dead wrong for non-lossy compression.. which is obviously what he is talking about (since he mentioned information theorey). He is making two eperate statments (1) you can not do any better with a non-lossy algorithm (but the compression phase is slow) and (2) wavelets degrade better then anyhting else if you start leaving out the big parts (lossy compression).
You could start spouting bushit about how (2) is subjective, but (2) is not the part of his post which you quoted.. and (2) is probable stil true *enough* in the near future.
Jeff
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Well, it's about time we got something better than resolution-specific DCT's.
Of course, I'd *really* love to see Barnsley's fractal compression go mainstream, but it seems that iterated systems doesn't quite grok how to make an image format catch on.
Still, 200:1 and resolution independence would be sweet.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
There's not a whole lot of variation, image-wise, in porn. If the picture is just a model against a plain background, it should compress *very* nicely.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Yes, and suddenly we're looking at three of everyone's favorite topics:
1) Huge farms of Linux-based machines
(doing compression necessary for)
2) Piracy
(because we're)
3) Not buying expensive DVD-RW drives.
Because I'm sorry, compressing a layer 3 audio file takes long enough, just imagine the CPU time needed to crunch entire movies. I'm assuming we'll be seeing hardware-assisted encoding boards, which will have some lame sort of copy-protection built in to prevent this sort of thing.
And as luck would have it, the lame protection scheme will also make the compression processors useless under any OS besides Windows, so it'll be the sworn duty of the open source community to defeat said scheme and take more bad press from the ignorant masses.
I should call myself Nostradamus.
I've had this idea for a long time now and this jpeg2000 stuff seems kinda similar.
Why couldn't we take samples of millions of textures, catalog them, and distribute them to every browser in the world (big honking download, one time). The image creation software could sample an image and find similarities between patches of the image and textures in the generic library and simply send the shape/location of the patch and it's corresponding texture ID. The viewer would pull that texture out of the library and paint it into the corresponding patch in the image. The truly unique information in the image could be super-imposed over the "patches" to make the final product. Seems like an image could be described in this manner with much less info. It wouldn't be "real" but what's real anyway? My arm doesn't have jagged edges like "real" digital images make it out to be. This idea is similar to vrml and if we take it a step further....
For $50 we all run down to Kinkos or some other copy place and get 3d scanned. We smile and frown and talk and so on in order to get a good representation of our expression, posture etc. They put our 3d representations on a CD(s) or eventually on a DVD and we give copies to all our friends. Now when we want to videoconference, our friend pops in their simulation of us and we theirs, and we're video conferencing ALA deathmatch. Facial expressions, movements etc. are simply codes telling the viewer's puter which slides of our sim to play/morph blend whatever. Might not work too well on 28.8modem but maybe it would. Sort of a Max Headroom (old people like me will remember) kinda thing but maybe better. Quake 5 will have the ability to load our sims and put our avatars directly into the game. Of course, fiber running into my house would make this obsolete pretty quick but I doubt I'll see any serious bandwidth at home for years.
The difference is that PNG isn't proprietary. It can be supported by any Web browser, but some don't because they're old versions. It's good when the standards improve, because then the web browsers don't have to invent their own rules just to make any progress.
--
Win dain a lotica, en vai tu ri silota
You mention that mention that mainstream websites tend to not switch their formats for fear of locking out users... But how many websites make themselves (for example) Shockwave required, or Windows only, or IE 5.0 only?
There's not so much of a desire to be compatible with everyone as there once was when you look at the everone-uses-windows website designer mentality.
Progress is one thing, but this is a sad thing.
That everything that happens in the computer industry is to enable better faster pr0n then ever before. First it was more colors and better resolution (cga->vga), then multimedia (motion and sound), and now we make advances to make it faster to download and sacrifice less quality in the internet age.
Good thing we have DeCCS amd MP3s or the harddrive market might take a hit. =
So an algorithm of complexity O(n) (DWT) is hundreds of times slower than an algorithm of complexity O(n log n) (DCT). Try putting a big N there and watch how the operation count of the DCT goes up. The wavelet transform is a lot faster than DCT.
Maybe it has got something to do with the complexity of the operations, noice reduction does both forward and backward transforms and a lot of logic in between, this is in no way a valid comparison of the efficiency of the different transforms.
The MPEG-2 audio layer 3 uses a polyphase filter to do subband decomposition into 32 subbands. Then it does a MDCT (multiply with window function then DCT) on those subbands and then uses a psychoacoustic model to quantize and huffman-code the transformed subbands. The MDCT's overlap to get rid of edge discontinuities (in image compression these are called blocking artifacts) and aliasing. Actually a wavelet coder could be a lot more efficient than a DCT coder, because of the lower algorithmic complexity...
The technology is called `Adams Platform', developed by an Australian [Adam Clark] who needed to pipe video through PSTN lines for a video wall at a shopping mall. Some journalist's believe the story and have been demonstrated the technology. I'm not quite sure what to think...the level of compression has been acknowledged by Clark as impossible according to existing theory...
f otech1.html for more details.
It promised to compress 1.3Gb AVI's to a floppy.
Check out http://www.theage.com.au/daily/980519/infotech/in
Here's an interview with Adam Clark...
h tm
http://www.abc.net.au/ra/elp/innovatn/inots675.
Am I the only one who thought:
"What a great way to piss of the RIAA, make the DVD consortium superflous, and archive my multiple gigs of porn on one CD in one fell swoop."
:-)
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Lizardtech is another company doing similar research that is seems luratech is doing. My company has done some alpha/beta testing for lizardtech (we're in the graphic arts industry). The cool thing is that they have a web server application (interfaced in perl) that allows you to zoom in on images in a web site.
Another company that has done probably the most ground breaking work in wavelets is Iterated Systems who we also helped out in the past. They are not as adept at bringing tools to market but have done a lot of original research into wavelet compression.
Jason
The JPEG committee page has links to more information regarding this image format. http://www.jpeg.org/public/jpeglinks.htm
The patent holder is Michael Fielding Barnsley, with Iterated Systems, and I believe it is a US patent (or several). He describes the IFS (iterated fractal system) algorithms for image compression and decompression in his book (with Lyman Hurd) Fractal Image Compression copyright 1993. Definitely an interesting read, and it has references to all the published papers where the in depth details of the algorithms are proven.
Fractal images also have no inherent dimension and can be decompressed to any size, like vector formats.
This is true, but also a misleading statement... when images are decomressed to resolutions beyond that of their original creation, image data is "created" based on the fractal characteristics of the attractor generated from the surrounding data in the original image. It will have all the same characteristics as the surroundings, but if there are new, completely different details that would not have been present in the original image, they will not be present in a "higher resolution" image... instead you see what could be reconstructed from the general descriptions of the system.
This is not to say that the image compression is not amazing, because it is amazing for some applications, but you wouldn't want to use it for some things, like medical/hospital images.
So if the only thing holding this technology back is the lackof a way to wreck it with commercialization, why isn't anyone doing anything about it?
Do you want RealNetworks controlling the wavelet business, or do you want it distributed free with every OS out there?
Check out Project Upper/Mute, an all-around awesome compiler fra
I saw an article on using wavelets for image compression a while back now, and it's nice to know there's a standard.
:)
Anyone know where I can find some reference implementations?
I hope JPG2000 spreads better than PNG has so far.
I hope the examples on this page aren't typical - the original jpeg seemed to do a much better job - no "out of focus" and no loss of small details.
Not so much "out of focus", more like "blind spot". Weird.
From having been involved in the Jpeg2000 work from the technical side of things, I feel safe in saying that claims of 200:1 compression is ...well... nice and everything in a specialized case. In reality, the compression results for what was finally adopted as Jpeg2000 Part 1 are only about 10-20% better than JPEG baseline for the same realitive quality level -- be it error numbers, etc -- on average. At high bit rates, there is relatively little that differentiates wavelet scemes from dct based schemes. Where wavelets show better quality is at high-compression ratios (even like the example given in the EETimes article) the reason there is that the wavelet transform operates on the whole image rather than individual blocks, like the 8x8 blocks in JPEG. Thus, you have more flexibility in the data you throw away -- better energy compaction, etc. Where JPEG 2000 was supposed to be useful, according to those in charge, was not in compression performance but features. It should be noted, in addition to having more features, Jpeg2000 is also more complex than JPEG. More memory is required as well as more computational complexity. It is a tradeoff, to gain features. Will it succeed? Who knows. I think that makes some sense...anyway...
http://www.informa tik.uni-rostock.de/~urausche/imgbookmarks.html
- SEAL
Wavelet image compression has been around for several years now, mostly in proprietary form. Let me give you one particular link - and no I don't work for them :)
Lightning Strike
Best regards,
SEAL
1) It has been proved that a wavelets can represent the theoretical minimum information for an image. Proof uses the information's counterpart of the Heisenberg's Uncertainty Principle. That's right folks - you cannot get any more compressed than that - it simply isn't possible.
Uh, not so fast. Compressing an image means making a fake image that looks as much as possible as the original. How much we approach the original is a very subjective thing and would differ from person to person. A good image compression teqhnique would take into account the human visual system and make some kind of average on what people think looks best (and the lossy compression algorithms already do this, JPEG for example compresses black/white information less than color information). There is no optimal image compression as well as there is no optimal sound compression since the compression scheme is adapted to an analogue old-fashioned eye or ear which can differ much from person to person.
"Well, good luck finding a judge that doesn't run a bestiality site."
This image claims that the top third is the "3Mbyte Original".
Of course it is, even though it's part of a ~150KB GIF.....
Pablo Nevares, "the freshmaker".
Pablo Nevares, "the freshmaker".
I can get rid of all those stinking gif's
In fact, the 200:1 compression ratio was an average taken from the developer's entire porn collection.
Unfortunately, his whole collection was comprised of pictures of gradients having sex.
---GEC
Bow-ties are cool.
First, lets clear up some misinformation: JPEG and MP3 both use the Discrete Cosine Transform (DCT). They don't use the Discrete Fourier Transform (DFT). The elegant DCT is an inexpensive approximation to the holy grail, the Karhunen Loeve Transform. And it is a very good approximation at that.
MPEG-2 goes even further by having quantizer scale factors on a macroblock basis. This allows a coder to use more bits on the subjectively more important part of a picture. Read this as locality.
Wavelets are just a transform. That's all. The zerotree, which its inventor Shapiro says is very similar to the humble EOB symbol in JPEG, has been applied to DCTs just as easily, with trivial results. The same can be said for SPIHT.
Wavelets have some advantage in reducing blocking artifacts at high compression ratios, perhaps for video conferencing. But even at that they are on the wrong side of history. Bandwidth is going up not down.
OK, by now you've gotten the idea that I've got a bad attitude about wavelets. This is true. I was at a seminar at UCSC a few years back when a wet behind the ears grad student said that in five years time, wavelets would dominate the market. Oh, I'm sorry, that was five years ago. Time flys.
PNG is necessary. JPEG2000 is completely unnecessary.
I just followed the link and didn't find the original jpeg to be better. At the partial bit rates I thought the 2000 was clearly better. At 1bpp i thought it was a wash.
We tried to license Intel's Wavelet compression used by RealNetworks and Microsoft in their video players (look for the "Optimized for Intel" logo), but when we disclosed that our player was a Java based solution, they quickly refused to let us work with them. It seems that no price could get us in the game; they gave us the feeling that it was more important to keep the technology firmly rooted to the hardware than to get a license fee from their IP. Not too much of a surprise, since Intel backed out of the consortium for the Java Media Framework API after v. 1. Too bad all the IP that IBM brought to the consortium didn't have a Wavelet tool kit...
According to the EE Times acticle,
Barthel (of LuraTech) said all involved companies have signed agreements that give developers royalty-free rights to part one of JPEG2000.
So it means that the respectively patent holders would still keep their patents but allow developers to them royalty-free.
Well, SLASH isn't neccessarily GPL'ed... but it is (well at least an older version of it) pretty much free-wared with an advertising type clause "put up our logo and a link to us"
Given, it is an older version... [does anybody know, or care to comment how different/what version that Slashdot currently uses? I haven't found that information, or figured out how different it is by comparison, yet. The only hints I've seen are that they are at very least at version 0.4]
Here is the 'license' included with the SLASH pre 0.3 tarball: /really/ don't want the logo, you can give me money. Also, you probably need to register mysql if you use it- it's cool, its fast, and they deserve some money. You can give me money too. I don't have any." [Obviously this is old. ;)]
Here's the Slashdot FAQ which tells you a bit about the hardware setup and software: http://slashdot.org/faq.shtml""LICENSE There isn't technically a license in this file, and we're still working out the details. Please don't screw us over on this folks, we're working real hard. The license is do-whatever-the-hell-you-want, but if you use our code, you must put our logo on the site and link it back to http://slashdot.org. If you
Here is the link to the SLASH page about SLASH with links to other implementations and add-ons: http://slashdot.org/code.shtml
Here's the actual software code.. http://slashdot.org/slash/code
This sounds like great newz for us film makers. At the moment I use a DPS PVR to do my editing but for full motion broadcast video I use up 6Mb/s and the dedicated Ultra Wide SCSI drives are a bit pricey.
.oO0Oo.
MJPEG2k (yuk!) is the great news for digital video.
As usual the pir8 FUD will get in the way but it's a market where quality isn't really the defining factor. If you've seen a few VCD's recorded live in Hong Kong with ppl coughing and laughing and walking in front of the camera you'll know what I mean.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
for 24 frames/second, if each frame is a 19Kb jpeg2k picture, and we're talking about a two hour feature film, this works out to about 3.2 Gb, or 5+ CD. In other words, no big win (if at all) over MPEG. -- Eythain
Well, this is too cool. I hope mozilla supports the standard right out of the box. That way I can start designing my web pages with it! On a related note, when the hell will gifs finally die! I'm amazed at how long it is taking for pngs to catch on. If this is any indication, I wouldn't expect to be able to include jpg2000 images on my web site for several years.
Fractal compression was used for the cut scenes on some of the Star Trek CD-ROM games, but I agree it hasn't been widely used.
Wavelet compression of video has been out for a while. Indeo 4 and 5 (but not Indeo 1,2, and 3) use wavelet compression. The Indeo 5 codec for .AVI files is a major improvement over Cinepak, the previous leader in .AVI codecs. Indeo 5 has far fewer annoying artifacts than Cinepak, even at higher compression ratios. Check out my Kick the Crooks Out, 15 seconds of Indeo 5 video.
How did someone like you get that much karma?? Wavelet theory provide ways of compressing *ANY* wavelike data, including audio, images, and video.
I remember looking at 1MB TIFF file that was a picture of a models face. Lots of colorful makeup, colored background, and wispy hair. I could get a decent JPG to 800k, but wavelet looked as good as the original at 10k. These guys aren't lying when they make their quality claims.
Did wavelets a few years ago in uni, so I hope I've not screwed up my information in the few years lag, but another few points to add to this excellent summary:
1) It has been proved that a wavelets can represent the theoretical minimum information for an image. Proof uses the information's counterpart of the Heisenberg's Uncertainty Principle. That's right folks - you cannot get any more compressed than that - it simply isn't possible.
2) Unfortunately, finding the coefficients for the minimum possible representation is a bit hard on the computation side - so normally certain constraints are made like fixing the angles of the wavelet. However, decompression is pretty much standard in any case - easier. But nothing quite as close as FFT.
3) JPEG chops the picture into managable bits - you may get discontinuities at boundaries. Wavelets sweep across the picture, from big to small, gradually improving the quality at smaller areas. So you can get a nice smooth degradation of details if you decrease the size of the file - or in other words, if you are downloading incrementally, your picture kinda shimmers in nicely.
4) Wavelets have a normal like-curve. Normal like curves occur frequently in nature -- for example the human face can actually be represented by very few wavelets - the eyes, nose, mouth, face all fit quite nicely. Probably good for photos.
Diggs
If guns are so evil, how come Sarah Brady can hold one and not turn into a raving lunatic?? Oh yeah, she is one already.
(http://www.luratech.com/products/productoverview/ pricelist_e.html)
What I can't find is information regarding the patents/etc. regarding the new format - anyone?
I/O Error G-17: Aborting Installation
Here are some quotes from an article about JPEG2000:
Since August of 1998, a team within the Digital Imaging Group (DIG) has been developing a rich file format for JPEG 2000
It surely took a long time to develop it. I hope it's worth it.
Image authors will also have the option of saving the picture in lossless format for archival storage
This is great! It means I no longer need to keep all of these uncomressed BMP files lying around.
Wavelet technology also provides for a continuous download stream of data that allows the user to control the amount of image resolution desired
This is also great. If I understand it correctly, it will allow you to download 30% of the image and get 30% of the quality, download %50 and get 50% quality or download it all and get full quality. But I might be mistaken.
Another innovation is that a new standard, "sRGB" will be the default colorspace for this format. In the current JPEG standard, there is no notion of default colorspace. This lack of precision contributes to inconsistent JPEG color rendering
This is a Good Thing, too. Great for printing.
The JPEG 2000 standard for metadata also provides for extensibility of the metadata properties. In other words, new functionality can be added without having to rewrite the standard. And speaking of adding information, the metadata catalog can be modified without having to rewrite the entire image file. These abilities make for a very nimble, adaptable image file format
Well, we don't seem to need this (using different formats is easier). If the format is too extensible, it can lead to the "get-the-latest-viewer-you-moron!" syndrome, like all the problems with the HTML that we have now.
If all goes as planned, the official schedule for implementation will be released in January 2000
Other good links:
.j2k files for your viewing pleasure (I wish a had a viewer :-)
JPEG2000 Requirements and profiles document, V.6.0
SEMINAR ON IMAGING SECURITY AND JPEG2000 - this is an interesting collection of documents about digital image security and watermarking. These gyus take security seriously!
JPEG2000 bitstreams - actual
JPEG2000 Decoder (Version 2.3.1) - written in Java, the source is not available yet (it will be)
Barthel said this patented variable-sized window-scanning technique has been incorporated into the JPEG2000 committee draft. Besides LuraTech, Ricoh and several other committee members found bits and pieces of their patented technology in the spec. Barthel said all involved companies have signed agreements that give developers royalty-free rights to part one of JPEG2000.
The open source community should be very conserned about this issues. We don't want the LZW patent screw-up with the GIF format to happen again. There are two sollutions: either drop the patent (I don't know if this can be done, any lawyers?), or make sure that the software using it can be GPLed forever. The word "forever" is very important, so that we won't have any problems.
I believe that we should put enough pressure on this standart and make it really free. If the screenshots are real, it is definitely worth it.
By the way, I am not completely sure that this is real. Something like this usually pops up every second year, and usually it's fake. I remember reading about fractal compression, which was supposed to blow JPG away. It was in the early 90s, and obviously it didn't have much effect on the industry.
Such advances are really great for the IT industry and the commmunity. I can't wait for downloadable high qualit movies to become available. The next big thing after MP3 will be movies. Either pirated or commercial, movies will be available on the Internet. I can see all the big movie companies making movies available for download for a small charge (even if it's $3 or $5 I will gladly pay it, instead of spending hours looking for the same movie on some pirate site. The Internet will drop the marketing and distribution costs for most of the movies, and it will make it profitable to make the files available, even if the piracy level stays high.
Hey, I made a 6Kbyte version of the top original "3Mbyte original" using standard JPEG compression! And it looks as good as the top one! Does that mean I've achieved 500:1 compression?! You would think they would a more REAL example, like include the original 3Mbyte file, a real JPEG and maybe a converted TIFF or something lossless of their compression format. Bah...
Does anyone know of any freely (or otherwise) available drafts of the JPEG200 spec, including some mention of the algorithms at work? Wavelets have been a popular research fad in the world of image compression, and I'm interested in seeing how JPEG2000 stacks up against freeware R&D wavelet based compressors. There are a myriad out there, and most do outperform baseline JPEG...
I am an imaging scientist, an editor of a document related to the JPEG2000 document. This article is SO misleading. The reality is that wavelet compression is only 0-20% better (depending on scene content) compression to get to similar image quality than DCT/Huffman (which is what JPEG uses). Most of the advantages in wavelet are the ability to decompress on a "sliding" scale, allowing for obtainment of the desired resolution and for progressive decoding!