Slashdot Mirror

← Back to Domains

Domain: datacompression.info

Stories and comments across the archive that link to datacompression.info.

Comments · 7

  1. "Exhaustive" by streepje · · Score: 1 · on Exhaustive Data Compressor Comparison

    Poor article. Even the Wikipedia article is more "exhaustive." http://en.wikipedia.org/wiki/Data_compression

    Even two minutes googling for "data compression" will get you more useful and better "compressed" information.

    http://www.ics.uci.edu/~dan/pubs/DataCompression.h tml

    http://datacompression.info/

    http://www.maximumcompression.com/

    http://www.compression-links.info/Link/248_Markov_ Predictive_Coders_PPMZ.htm

  2. Re:simple backups with rar by evolveit · · Score: 1 · on It's 2006 and Backups For Home User Still Tricky?

    If you want to compress in a non-proprietary format, use *.bzip2 format or *.gzip. There are two windows programs you can get:

    For Gzip: http://www.gzip.org/

    For BZip2: http://www.bzip.org/

    This application below will compress into Bzip2 format is more user friendly, has a GUI and will split files for you:
    http://www.7-zip.org/

    Either one will give you compression that can be opened on ANY operating system including
    Linux, Mac OS, windows, Unix.

    here is a general reference page for MANY comrpession tools. Personally, I like the non-commercial ones myself. ;-)

    http://datacompression.info/Zip.shtml

    Hope this is useful for all..

  3. JPEG-LS Vs JPEG by eldavojohn · · Score: 2, Informative · on MS Proposes JPEG Alternative

    I think you're confusing JPEG with JPEG-LS. Yes, they are both "JPEG"s but I don't think many applications natively support JPEG-LS. In fact, I wanted to use it in Photoshop and had to go get a plug-in. Whether or not JPEG-LS is as efficient as the new proposed MS format, I do not know. I think that JPEG-LS was slow to catch on because people just didn't care about upgrading their software to use it. I would wager that Microsoft will force third party software to support their new filetype.

    I'm not even sure if my browser supports JPEG-LS and I know that programming with JPEG-LS can be a pain if you're looking for libraries to read/write lossless compression image files.

  4. Re:Moderation gone mad!! by Anonymous Coward · · Score: 0 · on Solutions for Small Business VoIP?

    Troll? No. Clever? Thanks, yes I know, but don't let that frighten you.
    As an AC I don't get any real chance to defend my side but I can
    promise you that I have built at least three _working_ systems.
    Jitter can be solved many ways, simple reordering, windowed backbuffering,
    lots of fancy stuff - or for a budget DIY system just don't bother about
    it too much, it's not like the OP asked for a fully commercial system is it?
    Here's a few obvious links to help. I'm guessing you are enraged by my suggestion
    because you work for a commercial VoIP provider. What can I say? Please grow up.
    I also guess you have never actually built such such a system either, try it, go on,
    fire up that C compiler and amaze yourself at how easy it is. Really, you don't need a load of fancy stuff, VoIP hardly even needs a processor, man you could get a 4MHz Z80 to
    do most of what is required.

    here
    here
    here
    here
    here
    and here

  5. Re:Good news! by wtrmute · · Score: 1 · on New Virus Attacks Via RAR Files

    According to the author(s) of BZIP2, the "best available techniques" are a family of statistical compressors called PPM. Unfortunately, they're real resource hogs, so caveat emptor...

  6. Re:Fractal image format by wjr · · Score: 3, Informative · on Breakthrough In JPEG Compression
    Actually, it's not hard to improve on Huffman coding. Arithmetic coding has been around for a long time, and can do much better on most kinds of data. In fact, I'd suspect that this is how they're doing this trick: undo the Huffman coding and redo it with arithmetic coding. In fact, it's possible (though unlikely) that all they're doing is recoding a Huffman-coded JPEG file to an arithmetic-coded JPEG file - that's right, the original JPEG standard has variants that use arithmetic coding. You'll never see these in the wild because they're not part of "baseline JPEG" which is what everyone uses. Arithmetic coding is part of the standard, but nobody uses it. Arithmetic coding takes more CPU than Huffman coding, and at the time JPEG came out even Huffman-coded JPEG files took a long time to encode/decode. Also, the patent situation for arithmetic coding is a lot muddier than for Huffman coding.

    This page has a lot of information on arithmetic coding. Very briefly, it's a way of using fractional bits to encode symbols - Huffman coding encodes each symbol to some integral number of bits (more bits for infrequent symbols, fewer bits for common symbols); arithmetic coding does the same, but each symbol can map to a non-integral number of bits; you save a fraction of a bit per symbol, which can really add up. It's not easy at first to see how this works, but the math works out.

    Arithmetic coding has another advantage over Huffman coding: with Huffman coding, you first collect symbol frequency information, then you build your coding table based on that frequency information. You then have to somehow encode the coding table in your bitstream (so the decoder knows how to decode the symbols). The coding table is based on an average over (often) the whole file, so it can't adapt to changes in the symbol frequencies: if one part of the file contains just numbers, and the other part contains just letters, their statistics get mixed together so you end up with a Huffman coding table that's not optimal for either part. Adaptive Huffman coding (changing the codewords as you encode the file, based on changing statistics) is possible but painful. On the other hand, adaptive arithmetic coding is very very easy.

  7. Re:Statistical encoders by Adam+J.+Richter · · Score: 1 · on FEAD Compressing Compressed Files by 50-75%?
    I agree. Although the claims attributed to FEAD still sound much too good to be true on average, data compression has improved in the past decade or so with techniques like Prediction by Partial Match with unbuonded length, made more practical by Esko Ukkonen's algorithm (published in the early 90's) for constructing suffix trees in linear time and linear space, making it much easier to find repeating substrings, and the Burrows-Wheeler transformation (discovered in the 80's, published in the early 90's).

    I'm not an algorithms expert, so I'll not try to explain the jargon in the preceding paragraph. Instead, I'll just cop out and say that now you know what terms feed a search engine. I will, however, provide this link to bwtzip an experimental compressor covered by the GNU General Public License that uses the Burrows-Wheeler transformation, and this link page, mostly about suffix trees.

    I wish I could find it, but I recently read a paper that showed a pretty impressive comparison between some compressor that used a Prediction by Partial Match variant and arithmetic coding (probably not truely free, due to software patents on arithmetic coding) versus gzip and some other compressors.