Motion JPEG 2000

[mdw]

I have just brought in a stack of Hi8 videotapes to digitize (family archive) and I am thinking about what format to use for archivation. Huffyuv is out of the question, so I thought of Motion JPEG. But then I've found about Motion JPEG 2000, which looks like it might be the ultimate archival format.

The question therefore is what is the state of Motion JPEG 2000 software support? Is there some freely available or cheap encoder and decoder?

-mdw

[smok3]

Dont know about free ones, but:
http://www.morgan-multimedia.com/M-JPEG2000/
http://www.pegasusimaging.com/picvideo.htm

[mdw]

Dont know about free ones, but:
http://www.morgan-multimedia.com/M-JPEG2000/
http://www.pegasusimaging.com/picvideo.htm

That Morgan stuff looks like it might work. Unfortunately the trial is already expired and documentation is non existent (or at least not available on their web).

-mdw

[Blue_MiSfit]

Why exactly is HuffYUV out of the question? Is it because of the lossless filesizes?

If so, then MPEG-2 is a good archival format IMO.

[mdw]

Why exactly is HuffYUV out of the question? Is it because of the lossless filesizes?

Yes, too much data for my purposes.

If so, then MPEG-2 is a good archival format IMO.

That seems bit too much lossy for archiving...

-mdw

[smok3]

mdw, how about just using DV? (this seems simple enough based on the input quality...)

[*.mp4 guy]

Aa good Mjpeg codec can perform better then DV, some lossless codecs can even outcompress dv (most of the time). Mjpeg2k is better then mpeg2 as an archival format, because at around 8-12 (iirc) mbps it has better quality then you can get with mpeg2 at any bitrate, and is intra frame only, which is good for editing.

[smok3]

*.mp4 guy, i agree somehow, but from a simplicity point of view..., anyway what lossless codecs will outcompress dv?

[scharfis_brain]

around 8 to 12 mbps it will be easy for MPEG-2 to beat any intraframe-only codec quality wise.

I also suggest MPEG-2 for archival purposes if the amount of data is concerned.

If you use MPEG-2 with YUV-4-2-2 subsampling and a constant datarate of 25mbps (like DV) you'll achieve MUCH better quality than DV, MJPEG or MJPEG2000 at the same bitrate.

Also please note: I think that JPEG2000 is less efficient than JPEG. I've done some tests with it and found it far too blurry in comparison to plain JPEG. Also JPEG2000 isn't widely accepted jet. So you could get into trouble reading your JPEG2000 stuff in the future. MPEG-2 is much more widespread.

[kolak]

Try Cineform or Canopus HQ. Really good quality with 30Mbits.
Unfortunatelly not for free:)

[akupenguin]

@smok3
ffv1 and h264@q0 can often outcompress dv, and those aren't even the best lossless codecs.

@kolak
30 Mbits? Again, at that rate you should be comparing it against lossless codecs, so "really good quality" starts to sound not so good in comparison.

[CruNcher]

I made a small intermediate test with x264 last year trying to find out how effective H.264 Intra is vs Canopus HQ (Wavelet) also over more generations (10).

http://cruncher.mufflastig.com/hdtv/hdv/intermediate/avc-intra/
http://cruncher.mufflastig.com/hdtv/hdv/intermediate/wavelet/

it's not 100% scientific but i think nevertheless interesting :)

Canopus HQ was faster @ playback compared vs libavcodec @ that time (October 2006) only CoreAVC could reach the same speeds @ decoding back then. (Cineform wasn't tested (at that time) because it didn't survive a pre test vs Canopus HQ)

[stegre]

... Also please note: I think that JPEG2000 is less efficient than JPEG. I've done some tests with it and found it far too blurry in comparison to plain JPEG....

Well, definitely far from true, at least for low bitrates - the screenshots to prove it start here at point #2 (http://forum.doom9.org/showthread.php?p=1003122#post1003122), in an unrelated thread that coincidentally turned into a discussion about motion JPEG-2K.

If you don't want to read the whole thread, which is mostly unrelated, the short story is that forum member Eastermeyer asked why his VC-1 encodes looked worse than his MPEG-2 encodes of the same bitrate.

So I discovered and pointed out that he had inadvertently forced the VC-1 encoder to use all keyframes. With the bitrate, framesize and framerate he was using he was forcing the VC-1 encoder to individually encode each 1280 x 720 picture with only 17KB, a difficult task. Yet he was comparing it to a "normal" MPEG-2 file (with and average GOP length of 15), so the bits the MPEG saved on the interframes allowed it to encode keyframes with sizes more like 48K, as shown.

To emphasize the difficulty of getting a nice 1280 x 720 in only 17KB - and that VC-1 did a pretty decent job of the task, I demonstrated by doing experiments (and posted screenshot excerpts) that "normal" JPEG couldn't even come close to doing the as well as the VC-1 keyframe algorithm on a single image, given the same size limitation.

But to my surprise, I found that JPEG-2000 did a fantastic job. It's 17KB rendition is nearly indistinguishable from the 48K MPEG frame it was made from (and might even look better if it was made from the original) and, to my surprise, was also much better than same size 17KB VC-1 keyframe - even with the latter's advantage of one less generation of re-encoding in my screenshots.

This led me to the surprising realization - though it was starting to get off-topic in that thread - that "if one wanted all keyframes, motion JPEG-2K outperforms VC-1". And I still stand by that statement for the situation that was being discussed.

However: In a subsequent post (http://forum.doom9.org/showthread.php?p=1003242#post1003242), foxyshadis pointed out that the wavelet based JPEG-2K algorithms "are designed to do much better at the bottom of the quality scale, but are only marginally better or worse as you raise it..". That statement would appear to support, or at least could explain, scharfis_brain's quote above. foxyshadis also discussed complexity issues, as did akupenguin in an even later post (http://forum.doom9.org/showthread.php?p=1008223#post1008223) in the thread (though complexity & speed would be less of an issue when discussing "archival encoding").

In any event, if foxyshadis' point is correct, and I assume it is, and if this thread is specifically about the high-end of bitrates vs. low-end, then all of the above is not particularly relevant. Nonetheless, since we just happened to be talking about the exact subject, I just thought I'd reference that series of posts as a matter of interest.

[smok3]

@smok3
ffv1 and h264@q0 can often outcompress dv, and those aren't even the best lossless codecs.

@kolak
30 Mbits? Again, at that rate you should be comparing it against lossless codecs, so "really good quality" starts to sound not so good in comparison.

But we are talking about grainy, weird analog hi-8 sources, it took me quite some time to get a decent x264 preset even for dv backups btw, it had to be crf-19.... (gets anything from 5000 to 9000 mbits), also i-frame formats should be easier to edit and at the end they should be better for transcoding to delta codecs for delivery..., or am'i completely wrong? (will do some testing with x264 lossless btw, and maybe i can throw in some lagarith as well...)

[akupenguin]

If you absolutely have to transcode from one lossy format to another, then to maximize the final quality the first format should be similar to the second. If two codecs discard different kinds of information, then the final encode will have lost both kinds. If two codecs discard the same kind of information, then you lose much less (just requantization). So no, intra codecs don't make for better transcoding.

[foxyshadis]

High bitrate is still relative, though, and often MJPEG isn't particularly "high" when you look at the quantizers used, unless the size is close to half of a lossless; it's still well within the range where visible blocks show up and J2K can look better. Leadtools also has an mj2k codec if you'd like to investigate it, since Morgan's can be a little funky.

It's also possible to optimize for speed without losing all the benefits of multiscale wavelets: Take Leadtools' MCMW (http://www.leadcodecs.com/codecs/LEAD-MCMW.htm), which gets most of the quality of j2k at about twice the speed.

[*.mp4 guy]

I have a program (AIC) that can automatically compare all quality levels of H.264 intra, Jpeg and Jpeg 2000 and output a PSNR graph.

The front-end application (AIC.exe) uses the IJG JPEG library and the JasPer JPEG-2000 library for reading and writing files in JPEG and JPEG-2000 format.

graph (http://img259.imageshack.us/img259/8343/aicj2kjpgas6.png)

Most Jpeg encoders do not significantly outperform the IJG library, but almost all Jpeg 2K encoders significantly outperform the Jasper J2k encoder.

The source Image I used was a 752*500 high quality 24 bpp bitmap made from a reduction of an Image from a Nikon D70 DSLR camera.

[akupenguin]

AIC != H.264 intra. AIC uses only 8x8 transform not adaptive, and no deblocker. (Granted JPEG would benefit just as much from deblocking, but it is relevant when comparing to JPEG2k)
And I'm not sure how the comparison works, but if it compares directly to your source image: AIC works only in YCbCr, while JPEG2k allows RGB (and apparently that was enabled since the JPEG2k line went up to lossless). This matters at high rates, since colorspace conversion could cause more damage than the compression itself.

(Just stuff that was immediately obvious from the website. I haven't actually tried AIC.)

[*.mp4 guy]

I downloaded it a long time ago, I didn't realise I had forgotton that much about it. The J2k line actually doesn't go all the way to lossless, it goes to 96.7 db PSNR, lossless is infinite PSNR, so the j2k compressor probably gets put through the colorspace conversion aswell.

[akupenguin]

96.7 db = 16 lsb errors in the whole image. Far too small to be the result of any transform. I get on the order of 53 db from rgb24->yuv4:4:4->rgb24.

[*.mp4 guy]

How do you know how many lsb errors correspond to which PSNR?

[akupenguin]

255*255*752*500*3*10^(96.7/-10) = 15.7

[pest]

96.7 db = 16 lsb errors in the whole image. Far too small to be the result of any transform. I get on the order of 53 db from rgb24->yuv4:4:4->rgb24.

You could do this chain lossless or near lossless if you save some fractional bits too. But this is pointless in any practical image compression.
Do you really get 53db? I'm only reaching ~52.

[akupenguin]

The exact amount of quality loss will depend on the image content, and also on which of the yuv colorspaces you use (bt601, bt709, tvscale, pcscale).

[jakor]

Hello guys, I developed a J2K codec and have some lines to drop.
1) If you want to archive your data you have to decide what compression you need - J2K can do lossless compression,
but much more you can get from lossy 9/7 encoding mode.
This mode has been taken by Hollywood to store their high quality content.
2) speed is now not a question, even high bitrate movie will play smoothly on any Core 2 Duo CPU, this is true for D1 resolution.
3) regarding Morgan J2K SDK they lose quality a lot, in general pictures it is not noticeable much, but some special tests with small details, bright lines etc show a big loss.

[foxyshadis]

Most Jpeg encoders do not significantly outperform the IJG library, but almost all Jpeg 2K encoders significantly outperform the Jasper J2k encoder.

That's not true! Jasper is actually on par with the other best that I've tested, LeadTools and Lurawave. Leadtools tends to be slightly sharper and noisier, while the other two are a bit softer but avoid most of the cloudy noise, though you only notice if you compress an enormous amount. Morgan (via its toolbox) is noticeably worse than the others in both noise and softness at high compression. I have no way of evaluating Mainconcept's, although it'd be nice for completeness' sake.

[*.mp4 guy]

I was only refering to PSNR scores, I don't have much experience with how it stacks up visually, but according to this comparison (http://www.compression.ru/video/codec_comparison/jpeg2000_codecs_comparison_en.html) it doesn't have very good psnr compared to other jpeg 2K implementations.

[mdw]

What a nice, informative thread, guys. Thank you a lot.

I have one more question. When I get a MJ2K codec (like LeadTools), will it integrate with VfW framwork so that I will be able to use VirtualDub? What container formats are able to hold MJ2K stream? What audio can be muxed with it? LeadTools mention Ogg Multiplexer, which should mean that I will be able to convert audio into Vorbis and mux it into OGM, right?

-mdw

[foxyshadis]

Anything that can hold fourcc vfw codecs, which include avi, asf, ogm, and mkv, so yes. (Some of theirs are dshow only codecs, but I think all the mj2k ones are vfw.)

[mdw]

Anything that can hold fourcc vfw codecs, which include avi, asf, ogm, and mkv, so yes. (Some of theirs are dshow only codecs, but I think all the mj2k ones are vfw.)

Hmm, it seems that all LeadTools codecs are DirectShow only... how can I encode using DirectShow codec?

Borek

[Inventive Software]

GraphEdit. I know of no other at the moment. VirtualDub is proposed to handle DirectShow encoding codecs at version 2, but that's A LONG WAY OFF! :D

[mdw]

GraphEdit. I know of no other at the moment. VirtualDub is proposed to handle DirectShow encoding codecs at version 2, but that's A LONG WAY OFF! :D

I tried GraphEdit and it seems workable. I'll see whether I will go that way.

-BorekL

[kolak]

I made a small intermediate test with x264 last year trying to find out how effective H.264 Intra is vs Canopus HQ (Wavelet) also over more generations (10).

Canopus HQ is DCT not Wavelet codec, but the quality and speed are good.

Try new version of Cineform.