lossless codec alternative

[stanwebber]

is there any commercial lossless codec with better overall, or specific source type, compression than huffyuv(speed/performance is irrelevant to me)? my understanding is the mjpeg codecs labeled as lossless do not output exactly bit-for-bit with the original

[Mooney]

There are a codec called Microcosm that is lossless, but it's for the Quicktime format instead of AVI. It can also compress better than HuffYUV, but it's terribly slow on the PC. You can check it out at:

http://www.theoryllc.com/

[KoalaBear]

That's a very tricky question.

Virtually all codecs involve color space conversion to YCbCr format from some other format such as RGB or YUY2. Thus, even a "lossless" codec isn't going to be bit-by-bit identical with the source even if the coded picture is identical to the original.

YCbCr (aka YUV, but this is actually a misnomer) is considerably more compact than RGB, but still large enough to be unwieldy. To achieve further reduction a codec that operates on YUV-encoded data is necessary.

HuffYUV is a statistical compression algorithm that maps input blocks to bit strings such that the most commonly occurring patterns are coded using the fewest number of bits.

Lossless MJPEG is a block-based compression algorithm that performs a DC transformation of the input, reducing each block of pixels into a short series of coefficients that can be reproduced without error.

Lossy MJPEG works as above, but the coefficients are then scaled according to a quantization matrix which disposes of the bits you're not likely to see. The degree of quantization is variable which permits a dramatic degree of reduction, however, beyond a certain point so many bits are thrown away that the picture is severely degraded.

HuffYUV and lossless MJPEG deliver similar results, they just achieve those results differently. So the question of which is "better" from a quality standpoint is meaningless.

[ironwood321]

MPJEG is lossy codec as well a using Huffyuv Huffman tables to find the commonest sequences and group them together it uses DCT Discrete cosine transform which is when you look at the equation, looks very similar to the formula TV uses to split into YUV and superimpose this onto video as colour difference signals.

Quantisation can occur and this depending on the level looks at it neighbours colour and see how close to a threshold it is and converts the surrounding colours to this hence losing information. This means basically that this black looks like this other peice of black perhaps I can turn it into the same.

So with mjpeg depending on the compression level and various JPG parameters set you do lose some/most of the original video information the more compression applied.

This is generally showed by a loss of sharpness the higher the compression level and an increase in compression artefacts or fringes round objects.

Huffyuv just uses the Huffman table from MJPEG to store frequent used blocks in a group. Colour conversion from RGB to YUV might loose some accuracy but not precision and most capture chips i.e. Fusion878A capture in YUV and up sample to RGB if you need this type of output.

Essentially you loose no information from the original with huffyuv but you might loose a tiny percentage if you are converting between colour spaces.

MPEG and DV codec's use a complete different system to compress thier information so results look different.

[KoalaBear]

Ironwood321: what?

Huffman and DCT are as different from one another as night and day. They both produce a desired output (a file smaller in size than the original) but the modus operandi is entirely different.

If you want to know more about Huffman encoding, the book Algorithms or the update Algorithms in C both contain a rich, illuminative description of the Huffman algorithm that will occupy every spare moment of your waking consciousness in its glory.

DCT by comparison is a little more abstruse, and there aren't any good books on the subject that I know of, so your best strategy is to learn what you can from the Web and lean on your mathematician friends to fill the gaps in your understanding. Math is what they live for and there aren't many people willing to discuss it on a social basis, so believe me, they'll eat that question up. :)

[ironwood321]

I never said that they where the same. But huffman tables are used in JPEG to store values.

The JPEG spec defines two different "back end" modules for the final output
of compressed data: either Huffman coding or arithmetic coding is allowed.
The choice has no impact on image quality, but arithmetic coding usually
produces a smaller compressed file. On typical images, arithmetic coding
produces a file 5 to 10 percent smaller than Huffman coding. (All the
file-size numbers previously cited are for Huffman coding.)

[KoalaBear]

No, they aren't.

JPEG relies on DCT for reduction, and quantization for compression after that. DCT is lossless, quantization is not. Huffman is inherently lossless because it's a simple substitution as opposed to a transformation.

Don't go there, girlfriend. *snap* *snap* Mmmm-Hmmm?

[ironwood321]

The JPEG spec defines two different "back end" modules for the final output
of compressed data: either Huffman coding or arithmetic coding is allowed.
The choice has no impact on image quality, but arithmetic coding usually
produces a smaller compressed file. On typical images, arithmetic coding
produces a file 5 to 10 percent smaller than Huffman coding

you will frequently see references to "motion JPEG" or "M-JPEG" for video.
*There is no such standard*. Various vendors have applied JPEG to
individual frames of a video sequence, and have called the result "M-JPEG".
Unfortunately, in the absence of any recognized standard, they've each done
it differently. The resulting files are usually not compatible across
different vendors.


This is from the same FAQ you quoted from
http://www.faqs.org/faqs/jpeg-faq/part1/preamble.html

[KoalaBear]

Thank you, Ironwood321, for the reference. :)

I didn't know my answer was FAQ-quality, but if you're telling me the only way I could be wrong is in light of some niggling difference between the MJPEG implementation between one codec vendor and another, it's another feather in the cap to the theory that I actually know what I'm talking about versus making stuff up because I know alot of big words and that makes everything I talk about seem more authoritative.

... isn't that right, Homerpez?

[ironwood321]

Hmm I can smell something can't you it appears to be coming from your general direction!!

[Mooney]

Seems to me that two wisecracks are at war