crop_rec on steroids: 3K, 4K, 1080p48, full-resolution LiveView

[D_Odell]

You who uses crop_rec a lot, which option do you use most? I often tend to use center crop. All because of lens characteristics, better performance in the glas etc. But I would have loved higher vertical resolution in this option. Since I only shot 1.85:1 or 1.78:1 and never 2.35:1 there is not so high resolution, since it ebbs out at 1340 or such. But time will tell.

How about you?

[Kharak]

How are you shooting 1920x1080 48p ?

What exact canon settings etc.

I keep having Corrupted frames, when I shoot 1080 48p. 45p is close to continues and all frames are whole, but 48p gives corrupted frames no matter what.

I am on fir 123.

[a1ex]

Settings from first post, starting from Canon and ML defaults.

There's no more 1920x1080 48p in recent builds, guess why. If you still have problems at 1920x1040 48p, try decreasing the vertical resolution in the crop_rec submenu. How far do you have to decrease it?

Last time I've checked, all crop_rec modes were centered (maybe off by a few pixels, give or take). Is this no longer true?

Cache lockdown issue already answered.

[D_Odell]

Settings from first post, starting from Canon and ML defaults.

There's no more 1920x1080 48p in recent builds, guess whyLast time I've checked, all crop_rec modes were centered (maybe off by a few pixels, give or take). Is this no longer true?

Last time i tried there were substantial more than a few pixels when compared center crop to 3K crop rec. But it’s not a complaint only wonder what everyone uses

Cache lockdown issue already answered.

Thanks for that!

[Kanakori]

I can't find the option to decrease vertical resolution on the crop rec submenu and  have the most recent build I believe. How do I opt between the two?

 

Also, I have a doubt that I looked around and still couldn't figure out maybe because it is too basic. Here it goes: does crop rec mean zooming x5 in liveview while actually capturing the equivalent of x3? I struggle with this question because last week I'm pretty sure I recorded in 1080p48 continuous without zooming in.

[D_Odell]

I can't find the option to decrease vertical resolution on the crop rec submenu and  have the most recent build I believe. How do I opt between the two?

Also, I have a doubt that I looked around to find the answer but couldn't because I think it is too basic. Here it goes: does crop rec only work zooming in x5? I initially thought it would capture the whole frame, but then I read it is 5x zoom in liveview and actually capturing the equivalent of x3.

Crop rec is determined by resolution, do you want less vertical you change aspect ratio, for example 2.60:1. Higher vertical 1.78:1 etc..

[Kanakori]

Ok thanks, very kind of you! So the closest i can get to 1040 is 1:85:1 (gives me 1038). Is that it?

[D_Odell]

Correct! It’s dependent of aspect ratio..
Otherwise you need crop lines and make the rest in post.

[Kanakori]

Ok, ok but now when I play around with the camera the image moves like jelly on liveview. Is that normal?

[D_Odell]

In crop_rec mode slow shutter and low frame rate is normal if you want proper framing.

[OlRivrRat]

      @Kanakori & Whomever

   Especially on Non Camera Specific Threads it would be very helpful to include info on

what Camera & Firmware You are discussing.

                     ORR ~ DeanB

[Sganzerla]

I've found that 10bit lossless mlv_lite converted to .dng is giving me different colors than 14bit, 10bit and 14bit lossless, all of which are looking the same - ISO 3200 recording.
I tought this black level issue was solved earlier but looks like I was wrong.

Is there anything that I have to add to mlv_dump code to compensate this?

[a1ex]

Right - the black level adjustment is not implemented for 8..12-bit lossless in mlv_dump (only for uncompressed).

Have some sample files I could look at, where the black level issue is obvious? (no camera with me right now)

[Sganzerla]

Thansk a1ex!

Here you can download my .mlv files: https://we.tl/sFVu3jnWSM
(the clips are very short so you can download faster - dozen frames only each)

I forgot to add that I'm using 5D MKIII with 1.2.3 firmware.

[a1ex]

Changing black level to 2048 ("exiftool *.dng -BlackLevel=2048" or "mlv_dump --black-fix=2048") appears to do the trick.

Oddly enough, the 10-bit DNG with black level set to 2048 looks cleaner than the 14-bit one, to me. Can you confirm?

14-bit, 10-bit lossless black=2048, 10-bit lossless black=2047; rendered with dcraw -a -b 8:


Do you mind capturing the same scene at 12-bit and 8-bit?

[Sganzerla]

I got to record everything again because it is dawn here and there is day light coming from the window. Looks like there is an issue with 12bit lossless too:

https://we.tl/OUs5E7lZeq
(14/12/10bit + 14/12/8bit lossless)

EDIT: I can say to you that the 10bit lossless .dng file with black level at 2048 in ACR (Photoshop) looks different - it may appear cleaner because it has less banding and for sure looks brighter to me than the 14bit equivalent! This may be very good because my main use for 10bit lossless will be recording documentary style videos at night with some interviews.


Take a look at those attached files - exposure levels raised a bit:

10bit



14bit



I hope this 'find' is good news for all of us!

[a1ex]

Confirmed - the 10-bit DNG looks a little brighter as well. Actually, this applies to any lossless preset from 8...12-bit - these use a different raw type to reduce the bit depth using digital gain.

Interesting - the 8-bit DNG looks best with black level set to 2049; however, the 10-bit DNG from previous set looks bad at 2049. Why?!

The scaling factor between the two is about 1.2 (0.26 stops). Linear regression on x14bit vs x8bit-lossless (one frame) gives [1.1971   1.2035   1.1934   1.2467] (corrections for R,G1,G2,B). The same method, on 14bit vs 10bit-lossless, gives [1.1864   1.1828   1.1842   1.1966]. After averaging all frames in the MLVs, linear regression gives [1.1878   1.1952   1.1854   1.2060] and [1.1799   1.1764   1.1793   1.1718].

Uncompressed: 14, 12, 10-bit


Lossless: 14/2047, 12/2049, 8-bit/2049


Lossless: 14/2047, 12/2049 adjusted by -0.26 EV, 8-bit/2049 adjusted by -0.26 EV:


Lossless 8-bit: 2047, 2048, 2049, 2050


Lossless 10-bit: 2047, 2048, 2049, 2050 (from previous set):



Lossless 12-bit: 2047, 2048, 2049, 2050:


The above are 100% crops; click for full images.

Makefile used for rendering.


Averaged MLVs (first set, 14-bit vs 10-bit 2048 -0.26 EV):



Averaged MLVs (second set, 14-bit vs 8-bit 2048/2049 -0.26 EV):


edit: mlv_dump averages at the same bit depth as the input (not ideal); here's the same 14-bit vs 8-bit test, but averaged after 14->16 conversion:


=> there's a 0.5 LSB roundoff error with mlv_dump -a.

[paulrossjones]

hi, sorry if this has been asked in the past- I find the forum very hard to search for answers.

Can I crop a 4:3 ratio (for anamorphic) out of the 5D's full frame and get 1080p resolution at 50/60fps? If not, what would be the highest frame rate with the fastest cards?

cheers paul

[smasry]

Hi,

I've just bumped into a problem I don't remember anyone reporting on the crop_rec or lossless branch - I don't know exactly where this issue belongs, so could be posting to the wrong place.

Since it came out in April, I've been using the 4k losless branch, and have never come across this before: coloured vertical pinstripes across the right-hand side of the frame.




jpg to img


I'm using the crop_rec_4k.2017Oct28.5D3123 release, and was shoting in 3.5k crop_rec mode, with a resolution of 3584x1320 at 1 fps. This is shot on a pinhole lens, with a raised exposure of 1/30, ISO 800. It's shot in 14bpp lossless.

The MLV processing was done in the latest version of Switch, using its mlv_dump option, which I imagine is the latest.

The vertical stripes persist for nearly the first 700 frames, towards the end of this range getting more sparse and faint. Around frame 700, they are no longer visible, and the footage appears normal and artefact-free.

The MLV file is 8.4 Gb, and even if I cut it down to only contain the first 800 frames, it will still be very large to upload, though probably small enough to send by WeTransfer, if looking at it helps?

Thanks,

Sacha

[a1ex]

This artifact is visible on the main screen when zooming to 10x; does it help if you only zoom to 5x? You can disable the 10x zoom in the Prefs menu.

Unfortunately I don't have an easy fix for this one, though I have some ideas where to start looking. The image must be centered before Canon code captures the first LiveView image (which, to my understanding, is a dark frame); currently, the centering takes place a bit later.

I don't need the MLV, as I've seen this defect before (though it was only on x10 LiveView, not on x5 footage).

[Sganzerla]

I've made new tests comparing files at 14/10bit and 14/10bit lossless with different ISO values. In daylight it doesn't look like the 10bit lossless files are better at banding than 14bit ones as in the previous set I've uploaded with tungsten light at ISO 3200 (post #1315). Another interesting thing is it looks to me (I may be wrong here) that 14bit lossless looks a little bit better than 14/10bit files.

All 4 pictures for each ISO have the same adjustments in ACR (Photoshop) - WB values were used clicking on the second gray patch in the color target:

Always 14bit > 14bit lossless > 10bit > 10bitlossless

ISO 1600














ISO 3200 (last one 10bit lossless Black Level at 2048)














ISO 6400 (last one 9bit lossless Black Level at 2048)














ISO 12800 (last one 8bit lossless Black Level at 2049)













As you can see, every 10/9/8bit lossless file does have a colour shift in my real world use, and I can see some small pink and green dots in the conversion too. Unfortunately while I appreciate the smaller size and the potential better dynamic range and better banding handling in the images (as seen in my first comparison #1315), I think for now I'll still going to use 14bit lossless for my low light work. In my workflow it is impossible to get different ISO takes to match each other while at 10bit lossless. Until ISO 1600 this is somewhat a small problem, but above it (my need), it turns to a big one.

I think I don't know what 'average' mean in the .dng conversion yet, hope my test is not flawed because of this.

[smasry]

Hi a1ex,

I already had a conversation with you about vertical stripes - through the full width - in the liveview, and you explained that you know about it, that it's harmless, and that you'd need to work hard at removing it.

This report isn't about that, it's actually in the MLV file recorded in the 3.5k mode (with 5x magnification); the vertical stripes are recorded in the first 700 frames, only appear in the right half of the image's width, each of different colour and with random spacing. And, the only other similarity to the live view is that they fade towards the end of the 700 frames, visually disappearing from all further frames.

The reason I reported it is that: I've never experienced it before; I haven't read about it anywhere in the forums since you introduced the 4k_compressed branch; and as you're still treating the 4k_compressed branch as experimental and not stable, I thought you may want to know about edge pathological cases. Though, to be fair, since I don't know what would reproduce the behaviour, that does limit the usefulness of the report. 

[a1ex]

@Sganzerla: nice test; may I have the MLVs? (same as before, a few frames at each setting).

BTW - 14-bit and 14-bit lossless are identical. You are seeing two different noise samples - that's all.

@smasry: yes, I know how this defect looks in x10 zoom. I didn't know it can also end up in the recorded MLV, so your report is definitely useful. I'm not able to reproduce it though... (I only get the stripes in x10 zoom, but they go away in x5).

[Sganzerla]

@a1ex
Here it is: https://we.tl/IdWVFsg91b
(I didn't use 12bit options because it is of no interest to me)

[smasry]

Hi @a1ex,

Yeah, reproducibility is the problem here. If it helps to 'read' the MLV file, all you need to do is ask.

But, that's not the end of troubles, sorry. I've just had time to process another MLV from the same batch, this time a full-resolution crop_rec mode MLV, at 5784x3248, 1 fps. The problem here is quite a bit worse; the usable image is only in the lower half of each DNG, with travelling colourful aberrations and horizontal lines in the top half (maybe top 60% of the image).





Another MLV from the entire batch fails to process completely, in Switch, mlv_dump and MLV App, but let's not even go there.

The only thing that I did between these shots was to change resolution and/or bit depth including from 14-bit lossless to 14-bit. Nothing 'seemed' out of the ordinary, apart from the [usual and expected] slow-down in Magic Lantern responsiveness, which is correlated to the selected fps.

One thing was annoying and unexpected, but not insurmountable: trying to get back into the Magic Lantern menu often failed, and pressing the 'bin' button would (two thirds of the time) instead of drawing the ML menu, bring up Canon's own LiveView HUD picture style selector. Waiting longer and trying again would sometimes work properly, other times it would leave the LiveView on, drawing only the bottom two-three menu items on top, without any of the rest of the ML menu.

Again, I've only experienced this now, and only through playing with different fps values. It never happens in non crop_rec mode or at the expected 23.976 or higher, (or lower, down to 4) fps.

So, this shoot - while only a test - went wrong in three different ways.

If you'd like to see any MLVs, just ask.

Thanks