Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
GH2 - MJPEG resolution findings and Myth Busting
  • Tackling MJPEG for 2fps timelapses, I drew some conclusions that are less than obvious, and that I feel that should be shared with the rest of the community.

    For this I filmed a resolution chart on my computer screen from a distance, using Quantum 50-100 settings which use quality settings that are already over the line for 2fps be it AVCHD or MJPEG. I loaded the MOV files into AVIDemux and extracted 100% lossless snapshots to compare the various modes. Shot on M Movie Mode, aperture and shutter speed were both fixed.

    Note: I'm only showing the relevant 100% screen captures but all the files generated in this test (and I tested both HD and VGA modes) weight in at 38.5MB and can be d/l here: http://www.mediafire.com/?u2h8ycc2c6vmj0a

    Unless marked as AVCHD all other files are MJPEG.

    Myth 1 - MJPEG 1080p is MJPEG 720p up-scaled.

    Result: Plausible.

    It's too close to call, really! Even though there is evidence of a very very small resolution advantage to 1080p, it is hardly noticeable and it could be a consequence of the input-output workflow of 720 being done in a smaller resolution.

    Evidence: (look at the second image, I can't delete the first which is similar)

    720p vs 1080p.png
    1920 x 1080 - 1M
    720p vs 1080p.png
    1912 x 602 - 1M
  • 54 Replies sorted by
  • Myth 2 - MJPEG the bigger the better!

    Result: Busted.

    The best resolution all along is neither the biggest vertical resolution nor the biggest horizontal, but instead the "magical" 2048x864. The sharpness in this particular MJPEG mode is something that trashes all other resolutions that I've seen, in fact the image is so acute, that you'll have to watch out for moiré problems in textures in real life footage. This result extends from HD to VGA mode where 2048x864 is also the best resolution.

    Evidence:

    1920x1080 vs 2048x864 vs 2160x810.png
    1915 x 647 - 1M
  • Myth 3 - In Full HD, AVCHD is better than MJPEG!

    Result: Confirmed.

    Not much to say here really, the AVCHD codec has a very small resolution advantage horizontally but extracts noticeably more vertically.

    Evidence:

    Full HD - AVCHD vs MJPEG.png
    1912 x 707 - 1M
  • Myth 4 - AVCHD is always better than MJPEG!

    Result: Busted.

    It all comes down to taste, the AVCHD codec has noticeably more vertical resolution and shows virtually no moiré but MJPEG 2048x864 on the horizontal has a superior resolution (even though extinct) but the main difference is that it has a superior acuteness that is impossible to ignore and might suit some people better.

    Evidence:

    AVCHD vs MJPEG 2048x810.png
    1891 x 595 - 1M
  • Get a timelapse controller, if you switch you GH2 into multiframe/burst mode for stills, it'll use the electric shutter, not the physical shutter iirc, though you wont be able to shoot raw (I never liked shooting timelapses in RAW on my dSLR pre video dSLR days.. such a pain to manage), but 5K jpegs @ least compression (then pulled down in res to 1080p) is still amazing.

    Anyway, MJPEG mode 2048 x 1152 (dont have a anamorphic lens) then down sized to 1080p simply does not cut the mustard.

    AVCHD is quite a bitter better, you can see takumar is resolved and readable, and a big difference in many things, such as the cameras texture.

    AVCHD however still gets blown away by a still (full res from 16:9 mode on the GH2) down sized to 1080p in Photoshop using the standard bicubic filter.

    Both MJPEG (compression levels from Q9b) and AVCHD present significant problems once balanced and levelled in Photoshop, some colour haloing/edge problems around the bottle and camera for instance, shot it like that on purpose so I could try that out, the MJPEG in particular has rotten colour speckling all over the place.

    When I down scaled a frame from the MJPEG shot to 720p, and back up to 1080p, and overlayed it on the 2K MJPEG image downscaled to 1080p, viewed at 200%, I could see a reasonable difference in some areas, lines and text are better resolved, I do not think MJPEG @ 1080p is upscaled 720p for this reason. Though there is very little point, since AVCHD is better again (I certainly wouldn't want to do a shoot and need to much colour transformation/altering in post with MJPEG, it's quite nasty by comparison with the splotches).

    I will try the 'magic numbers' next.

    MJPEG:

    image

    AVCHD (1080p/24 fps, Quantum v9b 'slightly adjusted' ver):

    image

    Still image:

    image

    MJPEG 2K (16:9) -> 720p -> 1080p -> 400%

    image

    MJPEG 2K (16:9) -> 1080p -> 400%

    image

    edit: Did another test with MJPEG @ 2048x864 scaled to 1920x1080 vs AVCHD, MJPEG now does appear a little bit better (though I should confirm this but shooting 1080p, 2K, and 2048x864 while only changing cards to change firmware to test.., but still doesn't match with AVCHD).

    Above tests were on sharpness @ 0, MJPEG @ 2048x864 @ sharpness of 2, still doesn't match near AVCHD @ 0.

    It appears to me to be the sub sampling that's dragging all of them down away from closer results to the still shot, sony released a 4:4:4 upgrade via firmware for their FS100 (though that 4:4:4 HDMI is not out yet.. this year I think though).

  • 5K multi burst may be nice, I'm sure it blows any video mode out of the water while still keeping your shutter life, but I imagine it's a workflow nightmare because:

    a) You are limited to 1/40 shutter speed.

    b) You need to stack the frames manually.

    c) You need to wait for a buffer flush before taking another burst.

    d) You are seriously limited in card space.

    Don't get me wrong, I'm not taking it down, it's got it's uses and particular advantages, but it goes more in the line of timelapse photography, and my interest at the moment is more on timelapse video (where you capture all the motion flow without interruption). For the reasons I presented (and because MJPEG won't get you very far at 2GB per file), I'm trying to tackle an exclusively AVCHD 2fps patch, but since we're talking very low bitrates here, I've been trying to gather intel on getting a truly VBR approach from the latest patch sets from @balazer, @driftwood and @LPowell before I do it.

  • I mean the multi-burst mode to make use of the electronic shutter.

    You won't need to wait for a buffer with a timelapse controller ($40) - you specify the length between each shot taken. Though most of us wouldn't use the physical shutter much anyway, so the timelapse controller gives you any speed + bulb (which you set the speed on the controller itself, and how long to wait between shots etc).

    In any case, if you use 1/2th shutter speed on AVCHD for timelapse, have you tried using a high bit rate with a long GOP? Eg; GOP12.. equates to half a second in 24 fps. And in 1/2th shutter speed, every 12 frames would be the same and make an effective use of the GOP, with each new frame (every half a second) a new I frame?

    Edit: I've got MJPEG running @ 2400 x 1350 2fps, AVCHD still beating it. Increasing the size from 720p improves the image, but it doesn't match up to AVCHD.

    So it improves image quality, but cannot match AVCHD still (when both are optimised fairly well). Perhaps it defaults to down sizing/getting 1080p then to whats needed depending upon what filming mode on the camera is selected.. though that'd be wasted processing power perhaps, and then we should not have a significant difference with AVCHD.. esp when set to over 1080p.

    If it 4:2:0 sub-sampling was being performed then down sizing to the set size, I should exceed AVCHD with 2400 x 1350.

    It's illogical to resize twice, but perhaps we're getting a 720p image, but perhaps we're getting 4:2:0 sub-sampling on 1080p, if it's taking place after 720p->1080p, that would be better.. but I'm not sure we should be getting that much of a difference in resolving power above due to better chroma resolution, it looks like better luma resolution.

    Need to compare 720p MJPEG vs 1080 MJPEG I'm guessing for more clues..

  • @Athiril:

    Are you saying that using a timelapse controller I replicate 2fps video? Have you tried it and managed to get a shutter speed lower than 1/40s? Without interval between shots? If so then a) and c) are solved and d) wouldn't be as bad...

    As you mentioned, GOP12 is the natural and de facto GOP standard for timelapse patches because you'll end up with an equivalent Full Intra after you trash all "null" P/B frames in-between.

    The main points to be solved are managing to starve P/B frame bitrates while striking a good balance for I frames bitrate (which should work well bellow factory settings) with the clear objective of getting monster recording lengths. If all goes well, I also plan to make an alternative patch with ultra long GOP that would rely also on P-frames to encode the small differences that tripod made shots are likely to have, and possibly gain a little more recording time.

  • @duatrix:

    On a timelapse controller, you set the duration the shutter is held down (GH2 in bulb mode, though also useable in shutter speed setting on GH2 up to 60 seconds), the effective frame rate (duration between each 'press' of the shutter), and how long you want the timer to go on for.

    If you're okay with using the physical shutter for timelapses, then you can shoot in 5K JPEGs (or even RAW if you feel inclined that way). Many programs will sequence JPEGs for you into a timeline, you can down sample them in post, or even shoot 1080p stills mode, which is going to be a darn site better than AVCHD as above.

    I also just edited above with some other thoughts again.

  • I don't wish to use the physical shutter, so my direct question is: did you managed to get a shutter speed lower than 1/40s with the timelapse controller AND the electronic shutter?

    About your MJPEG resolution experiments and conclusions: did you miss this? http://www.personal-view.com/talks/discussion/comment/38242#Comment_38242 2048x864 is "the stuff" on MJPEG!!! I'm not saying there isn't another magical resolution, but ATM this is the best I know of.

  • I saw that, but I disagree. I tried 2048x864, AVCHD is still well ahead for real pictures, MJPEG looks terrible by comparison with less legible detail (can't read fine writing is a good one for example).

    I've managed to record some 3840x2160 @ 2fps. Haven't looked yet but am sure luma resolution is still going to be a fair bit better on AVCHD, given the other tests at even 3K.

    What I want to look at if there is a U and V resolution difference at this vs recording straight to 1080p in MJPEG.

    I also looked at the colour channels (RGB) in MJPEG with the current 'best' compression settings, it's blocky. No matter what settings you apply, MJPEG is still subpar to AVCHD in detail and compression artefacts.

    edit: To answer your question, no you have to use the physical shutter for that, perhaps the electronic shutter can be unlocked in a future hack, or slow shutter speeds in high burst mode to get them on the electronic shutter.

    edit 2:

    Just examined a 1080p MJPEG clip with a 2160p (3840x2160) MJPEG clip scaled down to 1080p in Photoshop, I extracted them to their YUV channels... Y on both is indentical, U and V are both much smoother and appear to be much more highly detailed.

    I should work on making a high spatial frequency chroma/colour line pairs chart to test this.

  • Interesting... I'll await your findings and try some real pictures of my own.

  • Did a MJPEG 720p test, Y on 1080p MJPEG is a little bit better but not by much.

    I just made up alternating lines of red and green at a 1 pixel level (hurts the eyes to look at).

    My screen is a 1920x1080 screen, so if I frame the screen so it's 'cropped' in a bit, I should be able to resolve it with a bit less than 1080p worth of resolution. Since the image is 4:2:0, than U and V should not resolve, but if sub-sampling is occurring after, than 3840x2160 U part should resolve anything L can.

    Though since it's not up at 1080p resolution, I might need to frame a little bit closer again, basically if I can get U actually resolving more, not just being smoother, I can prove (at least part of) sub-sampling takes place after this part in the chain in the software, meaning it should be modifiable, and lead us possibly to getting less sub-sampling for HDMI and AVCHD one day.

    Though whether it is handled in the encoder or a separate function for either MJPEG or AVCHD.. the encoder may need to be modified, encoder may need to be modified as there's no saying that it's a complete H.264 or MJPEG encoder.. hopefully not the case, as that would be a legendary quest probably.

    If I can show it's merely being smoothed out, then it's also a clue to where sub-sampling is taking place, and also the fact that smoothing can be done to a better extent in post (like with 5DtoRGB for example).

    Edit: I do seem to have better resolved U and V in 2160p vs 1080p, but it is hard to tell, as the lines are the same size, and it appears I was at about the magnification for the threshold of resolution in MJPEG mode.. so I need varying lines to see where the resolution drops off.. that will be way more definitive.

    If I just copy the ISO test chart and colourise it, that should do the trick.

  • Tested again MJPEG 2048x864 vs AVCHD 1080p, this time with some real pictures and some textures.

    I believe you are on to something and this might be related to color sampling. Even though I have no doubt that MJPEG 2048x864 is the best MJPEG yet, after retesting it it comes clear that it looks a lot more acute because it's much more contrasty. Pushing both pictures I can see that MJPEG has crushed a lot of shadows that won't respond to grading while in the AVCHD I'm still able to push them.

    I take rounds and rounds and I keep coming back to this: http://sonnati.wordpress.com/2010/10/19/h-264-for-image-compression/ JPEG is almost 20 years old, and even though it flies at high bitrates it's no match for AVCHD Intra.

  • I tested a chart... but its very difficult shooting off a monitor.. luma testing is easy.. colour is hard because of the interference pattern/shimmer you get over it.

    In any case, it does appear U and V improve @ 2160p over 1080p, but still do not match up to what Y is @ 1080p.

    I need a real high frequency colour target. Perhaps I could print a section large, and frame it far enough away, dont need to test the entire frame, just a small section.

    You can get excellent image quality out of JPEG. Given the file size per frame (hacked bitrate), and what you can get with JPEG at similar file sizes @ 1080p size, or even say 720p size, the performance of the MJPEG codec on the GH2 is exceptionally lousy.

    I think the luma detail is being limited elsewhere, there's got to be upsizing going on, given that I can't even match AVCHD @ 3840x2160, nor even improve upon (luma detail) from 1080p MJPEG.. it must be upsized 720p (or perhaps some other arbitrary number less than 1080p), the detail increase from raising the dimensions perhaps means luma detail is being lost along the way, and increasing the size prevents that.

  • @duartix Really enjoying this thread. Have you looked at using jpegsnoop to look at quality, chroma, luma?

  • (edit)

    There was (and still is) a color transformation error in my screen grabbing workflow, so please fully disregard the following original text:

    "There is something I forget to say in my last post: even though AVCHD responds much better to color grading, MJPEG 2048x864 is neck to neck where it comes to resolution. It's got a bit less vertical but it compensates with horizontal. When I resize one to the size of the other, resolutions are virtually indistinguishable."

    (/edit)

    Framing the chart at a distance was what I did when I saw that I needed higher frequencies. We're not testing lenses, we're testing codecs so that should do as the sensor resolution doesn't vary to the corners.

    As for the resolutions you are trying, I think you are chasing ghosts, the GH2 does video at top quality because it bins pixels before they reach the pipeline. This has all kinds of advantages, better IQ, resistance to moiré and above all faster readout speed! My take is that you won't get more detail simply because the pixels are binned at readout time, but feel free to experiment.

  • Quick crop from the v component of a normal picture @ 300%

    1080p MJPEG:

    image

    2160p MJPEG (down scaled to 1080p):

    image

  • @driftwood: Downloading! Thanks.

    @Athiril: can you please try the same for 2048?

  • 2048x1152, or 2048x864?

  • @duartix I use jpegsnoop all the time for my mjpeg tests, helps get good mjpeg settings as used in highest mjpeg res Quantum patches.

  • @driftwood: It does work, but I need to losslessly transform the MOV files into AVI with AVIDemux.

    It does give out a lot of information but I really don't know what to make of it. I'm also not sure if the issue is with compression but here goes (the interesting bits):

    Precision=8 bits

    Destination ID=0 (Luminance)

    DQT, Row #0:   4   4   4   4  11   8  19  19 
    
    DQT, Row #1:   4   4   4   4   8  15  19  19 
    
    DQT, Row #2:   4   4   8   8   8  15  26  23 
    
    DQT, Row #3:   4   8   8  11  19  23  34  34 
    
    DQT, Row #4:   4   8  11  19  23  26  19  38 
    
    DQT, Row #5:  15  11  19  23  26  34  26  34 
    
    DQT, Row #6:   8  23  30  26  34  38  34  30 
    
    DQT, Row #7:  23  26  30  30  38  38  34  34 
    
    Approx quality factor = 83.44 (scaling=33.13 variance=68.50)
    

    Precision=8 bits

    Destination ID=1 (Chrominance)

    DQT, Row #0:   8   4   8   8  34  34  34  34 
    
    DQT, Row #1:   8   8  15  19  34  34  34  34 
    
    DQT, Row #2:   8  15  23  34  34  34  34  34 
    
    DQT, Row #3:   8  34  34  34  34  34  34  34 
    
    DQT, Row #4:  23  34  34  34  34  34  34  34 
    
    DQT, Row #5:  34  34  34  34  34  34  34  34 
    
    DQT, Row #6:  34  34  34  34  34  34  34  34 
    
    DQT, Row #7:  34  34  34  34  34  34  34  34 
    
    Approx quality factor = 82.58 (scaling=34.84 variance=40.56)
    

    *** Marker: SOF0 (Baseline DCT) (xFFC0) ***

    OFFSET: 0x000021E4

    Frame header length = 17

    Precision = 8

    Number of Lines = 864

    Samples per Line = 2048

    Image Size = 2048 x 864

    Raw Image Orientation = Landscape

    Number of Img components = 3

    Component[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
    
    Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cb)
    
    Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cr)
    

    So, do all those 4's in the luma quantization table mean it's less agressive than the chroma table that is full of 8's?

    And the color subsampling is it 4:1:1? Would that would explain the differences that @Athiril has noticed vs 4:2:0 on AVCHD?

  • 2048 x 864, if you don't mind!

  • JPEGSnoop's Alt+6/7/8 has given me a heart attack!

    I'm appalled at how much color subsampling is being done and I still see a recognizable image when it's all put together again. I guess this is how state of the art compression works (well at least it was state of the art in 1992). :)

    And now back to work on VBR + AVCHD + 2fps. ;)

  • Try Copy Video in AviDemux to use the same MJPEG codec rather than output to uncompressesd (if thats what you're doing).

    Just did all the tests on a colour on colour real life target.. hopefully I got the distance/enlargement about right to show off differences between them all.