A New Web Image Format 154
MrP- writes: "BetaNews is reporting that a company called LizardTech has developed a new image format for the Web called DjVu." Apparently, it differentiates between forground and background components of an image, and compresses each appropriately. Good idea, but I'm skeptical of improvements (especially because they say it's "20 times faster then gifs" -- which measure compression in terms of speed? And they also say it compresses faster then pdf, but pdf isn't really an
image format). No Linux support. And I don't see any source code on the format, so don't expect it to get a lot of support on any major Web sites, regardless of the compression.
Re:Yeah, but... (Score:1)
Re:Boycott DjVu - Use PNG ! (Score:1)
Open technology.
Even if this company ports its format on a variety of OS, I won't be able to use it in my own products, I won't be able to use it with my favorite browser, etc. See what happened with GIF.
Slashdot, June 28 1998 (Score:1)
Talk about posting the same story twice...
Why are people so stupid? (Score:4)
Look at the ways to get a scanned document on the web:
1) GIF, PNG, JPEG: Large filesize or bad rendering. If I need to send a 300dpi page to a web browser, the browser isn't going to let a user pan and zoom on it and it certainly won't print it correctly. JPEG is the only one of the three formats that actually has a place to store the document DPI regardless.
2) PDF: Creating a pdf from a scanned image means either encapsulating a lossy or losless image in a file or doing OCR and risking unreliable information.
DjVu regularly achieves compression ratios of 1200:1 or more at very very acceptible quality. There is a IW44 fractal compressed background layer and a loslessly compressed foreground layer. The information is progressive also. As the file downloads the foreground shows, then the background, then the color information loads. Example documents on the DjVu website have shown entire 300 dpi full color sharper image catalogs compressed to fit on a floppy disk.
Btw not only are djvu plugins available for windows, macintosh, linux, and solaris. Let's not forget HP-UX and IRIX. How's that for covering the bases? If youre not supported, you can write your own for your particular flavor of UNIX.
Geez get it straight.
~GoRK
no linux support (Score:1)
Re:-1 redundant (Score:1)
No, it isn't. Think about how handy it would be to let someone dial in their own image quality, or do it for them of course. Some poor bastard on a 28.8kbit/sec modem would be able to set it to super low quality, which would look somewhat lousy but be quickly navigable.
This would be handy in a system with CPU to spare but limited storage, like a 200mhz+ embedded webserver using flash memory to store images. Then again, you'd have to store them compressed there, as well, but at least you wouldn't have to store N different versions of the file for users with various different quantities of bandwidth.
Let's get all worked up about nothing! (Score:3)
Re:Some facts off the top of my head... (Score:1)
Re:-1 redundant (Score:2)
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
Comments from a wavelet expert (Score:1)
The website clearly indicates that this software is designed for images that come from scanning papers documents that contain both text and graphics. The algorithm is supposed to recognize the text and store it as a separate layer (but still as an image) from the rest of the image. Furthermore, the image can be transmitted in such as way that the text and significant features of the image are transmitted first, followed by the bits representing less important features later - a technique known as progressive image transmission (among other names).
I certainly believe that they use wavelets to do this. In fact, the hot wavelet method of the 90's, EZW (Embedded-Zero tree Wavelet) compression allows for exactly that: to compress an image in such a way that the more significant bits come first, followed by the less significant bits in order of significance. Picking out text that is layered on top of a background image is relatively easy with wavelets: just pick out the really large coefficients in the wavelet expansion, since those most likely correspond to parts of the image where large jump discontinuities occur. This can all be done automatically, of course.
Please read and think before post (Score:1)
Some of the members of the team include Leon Bottou, Yann LeCun (the guy who was one of the few inventors of Backprop), Yoshua Bengio, Patrick Haffner, Patrice Simard, and Larry Rabiner. I know those guys and they're very good. Don't know why ATT ultimately sold this product, though.
As far as the text compression goes - it works by clustering individual characters into subgroups and using the latter as a highlevel compression scheme plus encoding the differences. So you could even 'edit' the text (they did it but didn't release it for some reason). Anyway, it's pretty cool stuff.
PNG popularity (Score:1)
a jpeg-like codec (Score:2)
The codec emits a byte stream considerably larger than the raw image (4x) but this stream is easily compressed by bzip2 or gzip. It reads and writes portable gray map (.pgm) files (both ascii and binary). If you want color I suggest you transform the image into YUV colorspace and compress each plane seperately. The color planes should be downsampled 4:1 (2x2 blocks) and compressed at very low quality (less than 15).
Build instructions:
Save the code as 4a.c
gcc -O2 -ansi -Wall -o en -DMAGICK=1.0 4a.c -lm
cp en de
Running the program:
convert image.gif image.pgm
cat image.pgm |
cat image.4a | bunzip2 |
convert image2.pgm image2.gif
To make a pgm from a jpeg use:
djpeg -grayscale -pnm image.jpg > image.pgm
Hints:
Try quality settings from 15 to 200.
Bad input causes core dumps.
The image is cropped if the dimensions aren't divisible by 8.
====================
/* 4a by Ryan Salsbury */
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#define D(a,i) a=(i); while (a--) {
#define i int
#define d double
#define szi sizeof(i)
#define szd sizeof(d)
#define gc() getchar()
#define pc(c) putchar(c)
#define w while
#define v void
#define L goto
#define _9 2+7
#define _27 3+24
#define di(F,A,B,C,G,E) \
v F(i j,i h,G* M,E* S){ d O = 0.0; i x,y,u,q,s,t; D(t,h/8)D(s,j/8)D(y,8)D(x,8)\
D(q,8)D(u,8)O+=M[u+q*j]*(A?ca[u]*ca[q]*(lQ[u+q*
co[B*q+C*y]; } } S[x+y*j]=O*(A?1.0:ca[x]*ca[y]/(lQ[x+y*8]-23.5)/LQ
8; S+=8; } M+=j*7; S+=j*7; } }
i nm()
{
i c = gc(), a = 0;
L0: if (c > 32) L L1;
c = gc();
L L0;
L1: if (c - 35) L L2;
L3: if (c == 10) L L0;
c = gc();
L L3;
L2: if (c <= _9*_27 || c >= _27*_9) return a;
a=a*10+c-48;
c = gc();
L L2;
}
v rp(i* x, i* y, d** X)
{
d K, *V;
i h, m, p, G, H, I = gc()*gc();
*x = (p=nm())&~7;
*y = nm()&~7;
m = nm();
*X = V = malloc(256 + szd **x **y);
K = MAGICK;
D(G,*y) D(H,p)
if (I==4240) h = gc();
else h = nm();
*V++ = h*K - 128.0;
} V-=p-*x;
}
}
v wp(i x, i y, d* V)
{
i n;
printf("P2\n%i %i\n255\n", x, y);
D(n,x*y)
i l = *V+++128.0;
l = l&~0xff ? l>>31?0:255 : l;
printf((n%20)?"%i ":"%i\n", l);
}
pc(10);
}
d co[64], ca[8], LQ;
char* lQ = "%! %,9CK\"\"#(.IJF##%,9HRG#&*0Ca[L'*7GQtoY,5FN\\pweA
di(fw,0,1,8,d,i)
di(rv,1,8,1,i,d)
i main(i argc, char* argv[])
{
char T[32];
i x, y, *pi;
d* ui;
d p = 0.1963495408494;
d pp = 0.3535533905933;
D(y,8) D(x,8)
co[x+y*8] = cos((2*x+1)*y*p); }
ca[y] = y?0.5:pp; }
if (argv[0][strlen(argv[0])-1] == 'n')
{
LQ = 100.0 / ((argc-2) ? 70 : atoi(argv[1]));
rp(&x, &y, &ui);
pi = malloc(x*y*szi);
fw(x, y, ui, pi);
printf("%i\n%i\n%f\n", x, y, LQ);
fwrite(pi,szi,x*y,stdout);
}
else
{
x = nm();
y = nm();
LQ = atof(fgets(T,32,stdin));
ui = malloc(x*y*szd);
pi = malloc(x*y*szi);
fread(pi,szi,x*y,stdin);
rv(x, y, pi, ui);
wp(x, y, ui);
}
return 0;
}
Re:Dumbass. (Score:1)
I don't know if "dumbass" is neccessary though. I was refering to the fact that the W3C seems to have a preference for PNG so perhaps we should stick to their standards.
Proliferation of file formats (Score:1)
Re:Reminds me of FIF (Score:2)
Re:Reminds me of FIF (Score:2)
But figuring this out ammounts to exhaustive search. Apparently IFS had decent heuristics that got decent compression in only a few minutes. I think this is what was licenced, and that the file-format was open? This was a while ago, so I'm filling in the gaps in memory by guessing.
I thought PNG did that effectively? (Score:1)
Secondly, isn't compression becoming less of a concern since more and more people are stepping into the broadband arena?
It seems to me like the product makes sense, but it would have been much better received 10 years ago or a year ago when Unisys was going insane.
Yes, we have no spoon.
Better yet (OT) (Score:2)
Re:Reminds me of FIF (Score:1)
The licensing fees for FIF and other iterated technologies are huge. And the weird thing is, if they were open source, Iterated would be in much better straights than they are now. We'd all be using infinitely zoomable, highly comrpessed images [both GIF, JPG, and PNG are web standards due to seeming freeness], and despiute the fact they'd loose the revenue, they'd be known as the number one player in town for fractal image creation tools. And people would but their software over the other utilities which use the same Open Source image format, because they had the fastest algorithms, extra features, or other competitive advantages.
Just a thought.
a rebuttal (Score:1)
The Internet has become a place where images rule, and visually pleasing Web sites reign over the simpler, more text-based sites.
The man has obviously never been to asciiboner.com [asciiboner.com]. Anne Marie should check this site out too, so as to get an idea of what to expect on our wedding night.
--Shoeboy
Misleading (Score:3)
DjVu is a document format (like PDF), not an image format, and the techniques mentioned in the article refer to compression of documents.
LizardTech do have a compressed image format. This is called MrSID, and uses completely different techniques for compression.
I would be interested to see an independent comparison between MrSID and PNG - unless there are huge advantages of using the proprietry MrSID format over the OS PNG format, I don't predict much of a future for MrSID on the web (although it would seem that LizardTech are touting it more for internal use rather than for general distribution anyway).
[Happosai]
DjVu has Linux support (Score:3)
Also the summary picks on LizardTech's use of speed as a feature. While this isn't a standard measurement, it is a way to tell people that you will get your images faster because the files are smaller. That's not a big crime. They also do talk more specifically about their format producing smaller files, so they do understand real measurements. BTW, while it is possible that they say elsewhere that DjVu compresses faster than pdf, what I saw was that the documents download faster, not compress faster.
The Slashdot write-up complains about LizardTech's comparison of DjVu with pdf, pointing out that pdf isn't an image format. True, but the LizardTech description refers to DjVu as "DjVu for Documents", and their web page describes why DjVu is good for documents. Images seem to be just part of the data they need to handle.
Finally, I haven't seen any source for Acrobat either, but it is very popular on the Internet, so lack of source won't necessarily keep LizardTech from succeeding with DjVu.
Is DjVu actually any good? I have no idea. Slamming the product with incorrect and misleading comments doesn't help one decide, though.
Here's some prior art from 1994 for you (Score:2)
My algorithm was lossless and what strikes me the most is the speed - my algorithm was notable for the speed of decompression, and we used it in particular just because it was so much faster than GIF, which was a significant advantage when you were scanning through lots of images on CDROM. While I only implemented it for 8-bit indexed images I felt it would likely work fine for any bit depth or color space.
Medior was later purchased by AOL [aol.com] and renamed to AOL Productions. I think AOL Productions isn't around anymore but lots of old Medior people still work for AOL, for example former Medior President Barry Shuler is a high-level exec at AOL.
Basically, my invention worked by dividing the image up into lots of little subregions and encoding each pixel in a given subregion in the minimum number of bits required to encode the number of colors that occurred in that region.
For example, in an image that was black on top and white on the bottom, I'd have two subreqions with zero bits each and a single element color table that was either black or white.
If it was snow - black and white pixels randomly intermixed - the whole image would be one bit with a two-element color table containing black and white.
The big trick was to divide the image in a good way, in such a way that the whole image was reduced the most and the size of the data required to reconstruct the regions wasn't too big. In practice I found it worked OK to start with lots of small fixed-size squares then merge adjacent squares that had similar color schemes.
I wrote a document for Medior that described what I invented in great detail and what I predicted this could be made to do. What I actually got it to do in practice was not nearly what it was capable of, but this was because of the limited time available to implement it.
Michael D. Crawford
GoingWare Inc
Re:Why are people so stupid? (Score:2)
Perhaps you're unaware of the PNG pHYs [w3.org] chunk, then, which lets you specify the physical resolution of the image.
Re:-1 redundant (Score:1)
PNG's are good, BUT:
Software for creating/reading them (end-user software as well as API's) still isn't as common and widespread as it *should* be. These things take time, yes, but they are slowed by factors like popular browsers not supporting PNG's properly anyway.
Don't get me wrong though, I would like to see PNG becoming the dominant format. But PNG seems to forever be stuck in the "early adopter" phase ..
Re:Actually quite an old product (Score:1)
lists DjVu Solo 3.0 (encoder for single pages only) as a free download. Could you use that?
http://www.djvu.att.com still has source for the reference library for people wanting to write viewers, but an encoder would be harder - I guess there might be patent issues too.
Re:-1 redundant (Score:2)
So for time, order of magnitude seems to be the differentiator, while size has a linear importance.
Re:Boycott DjVu - Use PNG ! (Score:1)
Linux has always been the primary development platform for DjVu products. Typically the release cycle is Linux and other unix platforms, then Windows, and finally Mac.
You'll also find the 2.2 DjVu Reference Library is available with GPL licence. The 3.0 Reference Library is scheduled to be released shortly...
http://www.lizardtech.com/products/djvu/referen
The old thing again? (Score:2)
Wait till it's a "standart" then ask for license fees.
The idea sounds pretty nice, but I'd like to see quality / compression ratio comparisions with hard numbers
Re:Actually quite an old product (Score:1)
That was almost 2.5 years ago. The reason they compare against pdf is that the target application seems to be text; compress the black and white text with one-bit RLE, and the background with JPG sort of deal.
Re:Boycott DjVu - Use PNG ! (Score:1)
Actually, it is just that PNG has a far more
complicated interphase for selecting options.
Once you select the right options, PNG will compress on the average about 10-20% smaller than
a GIF. I've seen as high as 50% smaller. The
only thing I've seen that is better for lossless
compression hasn't been released publicly yet.
When it is, I'll be happy to tell people about it.
Boycott DjVu - Use PNG ! (Score:1)
Reminds me of FIF (Score:3)
If these guys don't have an open format they will simply go the same way.
Re:Boycott DjVu - Use PNG ! (Score:1)
Has this been patented yet? (Score:1)
And how the heck does it figure out what the "foreground" and "background" components are, anyway? If I have to go in and mask out the background before saving, then forget it.
They got it from AT&T (Score:4)
See DjVu "non-commercial" site [att.com].
--Daniel
Re:They got it from AT&T (Score:4)
Re:Some facts off the top of my head... (Score:5)
I am one of the four persons who created DjVu in the first place. The events took place in AT&T-Labs Research between 1997 and 1999.
Hope this helps :-).
- Leon Bottou, AT&T-Labs Research.
There IS some source code (Score:1)
That was real nice of them.
-1 redundant (Score:4)
Speed of compression is not a factor in compression - otherwise we would use bmps or xpms, which have zero compression time - because they're uncompressed. Size matters. Speed doesn't.
I really can't see much market, and very little application for this compression. On-the-fly compression of images for web download would be redundant, since a png would be smaller than this format, so the speedy on-the-fly compression of uncompressed images is pointless.
And in any case, modern PCs are more than powerful enough to almost transparently display well compressed images, so a simpler format is about 10 years out of time.
If it was open source, it could perhaps have a market in replacing things like xpms, which are used in games for processing speed, but even it was, the benefit would be marginal, since hard disk space is, relative to image size, almost infinite, so compressing them slightly wouldn't make much difference - and for download those images would be gzipped anyway.
Re:Browsers (Score:2)
http://www.lizardtech.com/cgi-bin/products/desc
Cheers,
Tim
Re:Reminds me of FIF (Score:1)
Re: (Score:1)
Re:Will it help me get goatsex down the pipe faste (Score:1)
____________________
Re:Reminds me of FIF (Score:1)
Last time? There's never been a first time, for me. This is the first I ever heard about it, and I'm not exactly a newbie.
Stefan.
It takes a lot of brains to enjoy satire, humor and wit-
Re:Has this been patented yet? (Score:2)
As it only works on scans of paper documents, "background" is bland paper-texture, perhaps coloured. You can easily use an edge-detection filter to work out which is which.
Re:Why would I use this? (Score:1)
Re:It is Official: You are Stupid (Score:1)
Re:Whatever! LizardTech has the market cornered! (Score:1)
--
?! (Score:1)
This exists already! (Score:2)
Since JPEG is already fairly-well supported, why not use it? The only thing that needs to be changed is the image-creation software; it needs to know how to detect the difference between background and foreground content. Image-creation software also has a huge advantage here; layers (and their relative z-Indexes) give great hints as to what is, and what isn't, "background"
--
Re:Comments from a wavelet expert (Score:2)
The photographs need moderate colour AND spatial resolution (say 24 bit, 72 DPI). This is a very old idea. Colour print systems in the 70's used it. What's neat is the idea of "gating" the lower resolution colour data through the higher resolution "shape mask" to get the properties of both, at least for real world pages.
Appropriate (and quite well known) compression techniques are then used on the 2 channels.
The wavelet technique you describe sounds like it would get the frequency separation concept in a more "implicit" way. DjVu is very explicit. BugBear
Re:Some facts off the top of my head... (Score:1)
Re:I saw this working at Seybold (Score:2)
I wish people would get off the "if it's not OSS it must suck" bullshit attitude. LizardTech has some really well-designed software, and if it bothers you that they're proprietary (and IMHO, grossly overpriced), then bigod go out and clone it. Having an OSS equivalent of MrSID and DjVu, especially in a form that would be usable to the point-and-drool crowd, would be a very strong selling point for getting Linux into the MS/Adobe-dominated document archiving market.
--
Re:goat sex (Score:1)
Thank you
Um.... (Score:1)
It IS available for Linux (Score:2)
Have a look at:
http://cgi.netscape.com/cgi-bin/pi_moreinfo.cgi?P
Will
djvu is not new, it's OLD. (Score:1)
http://djvu.research.att.com/
Even mentioned in slashdot LONG ago (and we know how timely slashdot is
http://slashdot.org/article.pl?sid=99/03/29/031
http://slashdot.org/article.pl?sid=older/980628
Do a search on slashdot for djvu for more links.
Link.
Re:-1 redundant (Score:1)
PNG and GIF are lossless compression formats.
The reason JPEGs are smaller is that they don't have all the information in there. So on the size front it's no surprise that JPEG "wipes the floor with" PNG. They just look crappier.
What's wrong with the old encoder? (Score:2)
If you have a free open-source encoder, you can continue using it for no cost. No $2000 fee.
Is it just me... (Score:1)
But wasn't DjVu developed a GOOD while back by AT&T or Bell Labs or something? I could have sworn I took a look at this 2 or 3 years ago.
--
Dave Brooks (db@amorphous.org)
http://www.amorphous.org
Re:What's wrong with the old encoder? (Score:2)
Re:Actually quite an old product (Score:1)
It was really just a proof of concept anyway....so it's not costing me enough bandwidth to matter having switched away from DjVu.
DjVu, MRC, TIFF-FX, JBIG2 and more acronyms (Score:1)
This scheme has the advantage that it keeps high-frequency content (the edges of the text) out of the background, enabling it to compress better (wavelets and JPEG don't handle high frequencies well: they either smear them, add ringing, or require a lot of bits). Another advantage is that there are specialised algorithms for compressing binary (1 and 0) images containing text. The one used by DjVu is called 'SPM' (Soft Pattern Matching). It works (roughly) by breaking the text image up into isolated characters, then deciding which characters look similar to each other. On most pages, there will be a lot of repeated characters. You can then get improved compression by storing only one instance of each unique character shape. SPM does something fancier than that but that's the basic idea.
This three-layer model is known as MRC (Mixed Raster Content). It's used outside DjVu - most notably in a file format called TIFF-FX. This is an extension of TIFF intended for Internet Fax (including colour fax). TIFF-FX is, if I remember right, RFC2301. There is an extension to TIFF-FX in the works to add support for JBIG2. What's JBIG2? It's a format standardised by ISO for doing bilevel image compression, using the same concept of improving text compression by identifying repeated shapes. (Actually, there's a lot more in JBIG2 but I'll leave that aside). The concepts used in DjVu's SPM were incorporated into the JBIG2 design (AT&T participated in the design of JBIG2), so JBIG2 can do anything SPM can do. JBIG2 was approved by ISO and ITU this past spring.
Another file format that includes a lot of the same concepts as DjVu (MRC, repeated shape compression) is ScanSoft's XIFF - it's yet another TIFF extension, and is used in ScanSoft's Pagis line of products. In fact, much of the stuff in TIFF-FX is a standardised version of features that appeared in XIFF. MRC is also going to be in one of the later parts of JPEG-2000.
I've been involved in the work on XIFF and TIFF-FX and I was the editor of the JBIG2 standard. So what do I think of DjVu? One problem is that AT&T abandoned the standards process - they felt it was moving too slowly. This means that they opted for a proprietary solution over an open standard one. Yes, the standards process is slow, but when it works it produces things like JPEG and PNG (a W3C standard) - formats that everyone can use, and where you have a choice of encoders, a choice of decoders, and few worries about interoperability. Another problem is its reliance on arithmetic coding - while that gets you good compression, it can have speed problems. JBIG2 offers the choice of arithmetic compression (for applications where size is the most important issue) and Huffman-based compression, for applications where speed is the most important issue. I've personally seen a JBIG2 decoder decompress at over 1 gigapixel per second...
The facts. (Score:1)
I have long given up on slashdot reporting the whole truth and nothing but the truth...
-Chris
Uh... this was on slashdot before (Score:1)
Re:-1 redundant (Score:1)
CmdrTaco needs more sleep (Score:3)
New Image Compression Algorithm claims 1000:1 ratio
Hasdi
Re:Actually quite an old product (Score:1)
Re:DjVu has Linux support - including SOURCE CODE! (Score:1)
Not only is there a Linux x86 binary available, the source code is also online here [att.com].
Re:I thought PNG did that effectively? (Score:1)
Maybe the advertizers demand that their ads run as GIFs not PNGs.
Re:Better yet (OT) (Score:1)
Re:Reminds me of FIF (Score:1)
Hmmmm, nah. Some jokes are too easy....
Re:I thought PNG did that effectively? (Score:1)
Re:-1 redundant (Score:2)
Re:Actually quite an old product (Score:4)
The big problem I have with this article is that DJVu isn't a "new image format". It doesn't even display things inline (like GIF, PNG and JPEG). It is however an excellent alternative to PDF if size of file is your main concern.
The extensive references to "speed" when compared to GIFs and PDFs could be one of two things. They could be talking about Download speed (my personal experiences show DjVu files to be about 10 times smaller than GIFs and even more when compared to PDFs. Or, they might be speaking of encoding speed which DjVu seems to excel in
Here is a problem however: the command line encoder used to be free for non-commercial use. I was using DjVu for encoding swim-team documents for a small non-scholarship collegiate swim team. Certainly this counts as non-commercial. HOwever, the new version from Lizard Tech would cost me $2,000 USD to run. That is absurd by comparison. So I'm abandoning DjVu since I can no longer afford the encoder.
Incidentally, if you want to see how it worked for me, I used it on nearly every swim meet results page for a few years. Here is an example, just click on the links next to the word "Splits" in each event: http://www.k-swimming.org/cgi-bin/swimming/results /meet_view.pl?8 [k-swimming.org]
Re:Reminds me of FIF (Score:2)
Last I used it (on a 486 laptop, mind,) I could compress a JPG image in about five seconds to the FIF's 150 seconds or more. The images were comprable in quality--FIF did a visibly better job on some photos, but not so much of a difference that it justified the extra effort of encoding them.
Again, this is all from pretty old experience; the compressors may be far better now, and there's also the fact that an open source format/non-licensed technology approach would have likely resulted in better compressors. Any more recent info on how FIF fares, performance-wise?
$ man reality
What about it? (Score:2)
First you have to have a good format, then it has to be accessible and affordable, then it has to be accepted. For the life of me, I can't figure out why PNG hasn't replaced GIF.
Actually, though, that's part of the final hurdle -- a Catch-22. No one will adopt it until web pages and browsers support it. Web pages won't support it until browsers do and browsers have no reason to until web page creators demand it.
Re:Okay, so it's another wavelet-based compression (Score:2)
~Tim
--
There is Linux support (Score:4)
They have a browser plugin for Linux/x86/glibc2 available for download here [lizardtech.com]
Yes, I know that link is broken becauseActually quite an old product (Score:5)
Hence the Open Source products generally only seem to be there to satisfy existing licensing requirements from prior to Lizardtech's purchase. It's doubtful Lizardtech tend to encorage that aspect of the technology, and they're only promoting the closed source stuff.
However, the compression is indeed very real and the cross platform nature makes it quite useful for archiving stuff that won't be modified frequently in the future - remeber, that text ain't vectorized, it's just another layered image, AFAICT.
Won't go anywhere (Score:2)
JPEG = "JAY-peg"
PNG = "ping"
DjVu = "duh-ju-voo"
So you have the choice between drooling on yourself or saying "deja vu," which has more syllables, tone changes, and stops than its nearest competitors. Plus the danger of the illiterate calling it "day-JAH-voo."
-----
Go ahead, blame me... I voted for Nader!
almost cornered (Score:2)
Lately we've been much more interested in MrSID and have been using it a little bit, but are hoping to include it in our home brewed media management system.
Jason
There's nothing here that TIFF6 can't do (Score:2)
One for bilevel compression, say using CCITT group 4 compression (Faxes use group 3, group 4 is better ratio, but bigger disaster if you drop a bit), or maybe JBIG (IBM have a patent on the statistical model of the Q boxes, not on the actual compression algorithm, so all you need are your own Q boxes). Both of the above compare the current line with the previous line, and barf horribly when given dithered bilevel images, such as newspaper photos, or noisy scans.
The second layer is the full colour one, and can be implimented as a JPEG.
Tiff 6 supports all of the above.
The 3GB Tiff document they talk about on their site was probably 3GB using the "uncompressed" setting. Apples and Oranges, as they say.
The world doesn't need any new de-facto "standards" when there are perfectly good present non-proprietory standards which can do the same.
FP
Re:Why would I use this? (Score:2)
If you download a whole book with text + pictures, then it would make a difference.
Today, scans of archives avalaible on the web are often ugly 1bits-per-pixels low-res scan embedded in PDFs. And that suck badly / is almost unreadable.
So, DjVu _is_ something interesting for reading non-copyrighted papers, research work, FOI publications, or public domains archives.
> but considering the format's not open
As many others have already pointed, the format is open.
Cheers,
--fred
Re:Actually quite an old product (Score:5)
Picture this: Start with a 15th century Flemish "Book of Hours", hand illuminated on vellum (goat skin). Scan it at 600dpi 24bit for archival purposes. Reduce your tiffs to 300dpi and you still have 1.06 GB of image data (not very downloadable). Using the DjVu compressor we achieved 205:1 compression so the final product totals 5.44MB. By separating the pages so they only download when called for the initial download is a mere 45.06KB (including all of the HTML and other images on the page) with an average download of subsequent pages only 21.34KB.
DjVu was developed by AT&T Research. It was then purchased by LizardTech last year.
Code commentary is like sex.
If it's good, it's VERY good.
Re:Smaller then PDF? (Score:2)
Code commentary is like sex.
If it's good, it's VERY good.
Browsers (Score:2)
It wil not replace a the "standards" we have now (Score:3)
Corporate digital asset collections
Real estate sites
Online catalogs/retail companies
Auction sites
Libraries
Medical sites
Geospatial imagery/government agencies
Corporations are storing everything digitally now: pictures, instructions, etc and need are searching for a way to manage all of this. This product is attempt to fill that void.
In a nutshell, this will be a specialized format that we will see for businesses that need to pass digital assets to the user.
Smaller then PDF? (Score:2)
Not a web image format (Score:3)
And, actually, there is Linux support, and source code available. Just Lizardtech aren't going out of the way to tell anybody about it - see my above post
Image format? No. Document format. Yes. (Score:2)
Now the claims on the document format bother me. First, they compare it against PDF which we all know is large and bloated to begin with. Sure, if I took any document and separated out the text and formatting and images, compressed it down I'd probably have a "new" revolutionary document format. Doesn't this just sound like HTML? I've written server side scripts and client applets that will compress HTML the same way, and I think my results would be about the same as this (and perhaps faster?). You'll still need their plug-in to view their documents. They also say that a 2.5gb TIFF is compressed down to 3mb. Wow. I can do that now if I convert the TIFF to JPEG with little loss of quality. I really don't see what the big deal is about.
I wish the /. reporters would do a little research before they go posting messages that send the readers into a frenzy of clicking and sending off emails to friends about the next wave sweeping the internet.
liB
Some facts off the top of my head... (Score:4)
The main attraction of DjVu is that your scanned documents are tiny (typically less than 50KB) which makes it feasible for putting them on the web. Just about every other format results in files too big for easy distribution on the web. Interestingly, you can convert a *.ps.gz file into a DjVu file, and see a dramatic improvement in file size while preserving almost all of the detail. I am not talking about simple pages here, by very complex ones with a mixture or real images / artwork, and text.
Apologies for any mistakes, but I think that I got most of it right.
-- GWF
Re:Actually quite an old product (Score:2)
The important thing is that they try to make a semantic interpretation of the input image and apply differing approaches depending on the content. My above post answered the question above as to why they are comparing themselves to pdf; they focus on compressing exactly one kind of information, so they shouldn't be compared to standard image compression.
So I guess I don't agree about that being redundant. whereas the fact that they use wavelets... well, that's nice, but hardly germane.
Re:Some facts off the top of my head... (Score:3)
Re:-1 redundant (Score:3)
Lossy / lossless image compression types. You cannot compare PNG tolossy schemes. PNG cannot beat a lossy method because the goals are different. Lossless: Compress as small as possible (but the exact original must be restoreable). Typically, the algorithms that throw more resources (CPU and memory) at it are better. Lossy: For a given file size, reach the best quality. You can easily beat PNG with a lossy scheme by simply choosing very bad quality.
Open source. There are a few programs out there. Try TIC [waikato.ac.nz]. It's GPL'd and beats JBIG-1 by about 40 percent on scanned images, according to the website.
Resources: Image Compression Resources [uni-rostock.de], The Data Compression Library [dogma.net].
I saw this working at Seybold (Score:3)
Yeah, but... (Score:3)
Yeah, but can it detect the difference between nude and naked?
Re:what DjVu may mean ? (Score:2)
Wait - I get it ;,)