Danne's crop_rec_4k experiments for EOS M

Started by Danne, December 03, 2018, 06:10:17 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Danne

No code, no plan. It's up to bilal when/if he gets ready.

Mattia

Bilal, do you have any plan about releasing that code? :)

Danne

I think he explained pretty clear in his post what his plans were?

Mattia

I beg your forgiveness! I repent for my inconvenient question!

Danne

This thread is about eos m. There's a proper thread which Bilal started around your topic. If you want more info I suggest you ask there.

Mattia

But I'm interested in the Eos M, that's why I was asking here. Anyway, I'll wait for the next Bilal move, thanks.

gabriielangel

Build 2023Feb10
All files recorded with stock build.
Only change to the presets is 2.39:1 ratio and 14/12bits when required.

First, you can have a look at the files contained here (Small Download): http://bit.ly/3E2bhdc

You will see the real power of Dual ISO. This is as challenging as it gets for a scene. Lots of dark and very bright areas. There are 3 files, one at ISO 100, the same ISO 100 brightened and the same scene recorded at Dual ISO 100/3200 with same brightness settings applied (exposure -1.71 and Lighten 93) .
No noise reduction was used. As you will see, the gain in shadows quality is phenomenal.
I salute the amount of work and tweaking put into that build to reach such a result.

Now, as I briefly outlined in a previous post, the way the image is exposed is of paramount importance.

For example here is a reference image recorded at ISO 100, -1.0 EV


Here is the same scene recorded at Dual Iso 100/800, exposed -1.0 EV for ISO 100:

By looking at the waveform monitor, you can see that although there is still headroom left, the flat line indicates that some Limiting / Clipping is taking place in camera.

Same Scene with Dual ISO Processing Applied:

In this example, iimage looks  fine. But the amount of clipping will dictate how the file will look when played. Sometimes it will be fine, sometimes you will get pink highlights and  sometimes the quality of the file will be seriously diminished and flickering will be introduced.
I included several example MLV files at the end of the post, so you can all judge for yourselves.

Same Scene recorded at Dual ISO 100/800, but exposed at -1.0 EV for ISO 800 before Dual ISO Processing:

As you can see on the waveform, there is far less Limiting / Clipping happening, as you don't see a total flatline in the red at the top, from left to right.

Same scene as above, with Dual ISO processing applied:

As you can see, the scene is a lot darker. When exposing this way, there won't be any visible Dual ISO artifacts nor flicker under normal circumstances. But once you brighten up the scene, you will gain some level of noise in the midtones.

So in order to find the proper exposure point, we would need to know what happens in camera regarding the exposure of both ISO's and how limiting is applied. Otherwise the results will be too unpredictable, depending on the overall brightness of the scene, the presence of reflective objects, etc. If we underexpose to the max just to play safe, we lose some of the benefits gained by using Dual ISO in the first place.

It is also unclear where MlvApp sets the pivot points between Swadows, Midtones and Highlights. Ideally, the Midtones should not be touched by the Dual ISO processing.
A happy balance has to be reached.

For the MLV files I included, pay attention to those areas of interest when evaluating:

Those are the areas where artifacts are most likely to occur.

I recorded the files on 2 different days. One day was sunny and the other had an overcast sky. The effects of brightness on the image will be obvious.

I included 2520x1054 23.976p files, and also 1736x2178 20p files, as the latter emphasize the effects of brightness, binning and scan rate on the image.

p.s. There is some vignetting in some of the examples, because I forgot to bring a large ND filter to put on the wide lens.

Link To the MLV Files (Large 3GB Download): http://bit.ly/3RT9RXW   (will erase in 1 week)

Finally, when testing, one has to do at least 4-5 recordings per setting. The timestamps on the files will show that two recordings in a row may give two different results. So some problems may be hard to pinpoint, reproduce or observe when only recording once or twice.





hastings

Hi, new here...  ^_^
Both in the 3 Feb and 10 Feb builds I noticed that ML crashes after recording in 5k anamorphic frtp if the sound is disabled?

Danne

Good catch. Some race condition interfering with other hacks making auto focus work. Hacked again and works better.
New build is out.

bern047

Thanks Danne and hastings for reporting the bug, solved my problem me thinking it was my card or settings, all good now : )

hastings

Just tested latest build and can confirm the fix! Thanks! Doing tests for a project with 5k anamorphic in 4:3  :)

gabriielangel

Tested Build 2023Feb14

2.5k Centered 1:1 preset is not centered anymore. It records the same sensor area as the default 2.5k preset. This behavior was present in the last build also.

Tested the build's default 16:9 Ratio this time, using the same procedure described here: https://www.magiclantern.fm/forum/index.php?topic=25781.msg242204#msg242204
Clean Install, stock settings, AF+MF enabled in Canon menu.

Tested presets 5k frtp, 2k, 2.5k, 2.5k 1:1 Centered, 2.8k, 3k (This preset  requires to record from the preview state to get enough record time at 12bits. The 2.8k/12bits  preset would be better suited for Dual ISO use, if 2.5k is not enough)

-Dual ISO behavior is on par with the previous 2.39:1 test. All metadata shows properly and dual ISO clips all record from frame 1 as expected.

-The new "State Change" routine, for lack of a better term, solved most of the issues related to crop modes getting stuck on the preview / zoom state. This problem occurred only once, while switching from the 5k frtp preset to the 2.5k preset.
Because the 5k frtp preset runs in real-time preview mode by default, it occasionally passes that state to the next preset being loaded. The preset then starts in cropped preview mode. Sometimes pressing info goes back to framing preview, but sometimes a restart is required. It happened only once out of 54 clips recorded.
So this is a big improvement.
This also seems to have fixed the problem where a low res preview state was sometimes getting recorded. More testing will be required to be sure.

-The responsiveness of the wheel and up/down buttons is significantly slower than before. As long as one is aware that  a little pause is required between each press, it doesn't affect usage too much.
All the key presses and wheel turns are registered, but the display just takes a while to update.

Not Exclusive to this build:
For autofocus to work properly, it should be set to Flexizone Square (As opposed to Flexizone() )
Commit 281bc80 made Autofocus more accurate for 5k ana frtp and 2.5k.
For 2.8k, and 3k to a lesser extent, there seems to be too big of an offset between the framing and the preview area alignment. The focus box is now perfectly centered, but it looks as if it doesn't know that the sensor area being scanned is offset to the left.

EDIT: I also tested 2.35:1 ratio, which behaves like 16:9 and 2.39:1
For this batch, I set exposure then turned off the histogram and restarted the camera. This should remove any doubts that the Histogram may have something to do with it.
Note that none of the artifacts showed when recording the test chart. So, recording a scene with enough details (and possibly handheld) is necessary.

Some MLV clips to look at the 2.35:1 artifacts: http://bit.ly/3Idlpku

aiyik

Hi,

I would just like to report an issue with the latest build regarding the area of the sensor that is being displayed/recorded. It appears that this area has shifted horizontally since the previous build and is now way off center, causing some mechanical vignetting on lenses intended for smaller sensors.

Below are two examples, shot with the same lens (COSMICAR PENTAX 16mm 1.4 with C-mount adapter) in 3K mode 3032*1436px (x5 crop).

TEST 1

First shot taken on previous build has no visible vignetting.

(crop_rec_4k_mlv_snd_raw_only_2023Jan08.EOSM202)

Second shot now displays mechanical vignetting on the right hand side.

(current crop_rec_4k_mlv_snd_raw_only_2023Feb14.EOSM202)

TEST 2

A second test with another, wider lens (COSMICAR 8.5mm 1.5 with the same C-mount adapter) and the same settings as above.

The shorter focal reveals that the offset crop issue was already present on the previous JAN23 build and has just been made more visible with the latest FEB23 one.

(crop_rec_4k_mlv_snd_raw_only_2023Jan08.EOSM202)


(current crop_rec_4k_mlv_snd_raw_only_2023Feb14.EOSM202)


If time allows it I will do other tests with older builds, following the same procedure and trying to pinpoint one whose scan/sensor area was not skewed left/right.

Hope this helps!

Danne

I changed some presets CMOS 5 regs due to issues when using af.

aiyik

Quote from: Danne on February 24, 2023, 08:26:17 PM
I changed some presets CMOS 5 regs due to issues when using af.
Hi Danne, not sure you were responding to my post but could you perhaps point me to a build that does not include those CMOS registry changes in order to get a more centered crop?

Thank you. And also thanks for your wonderful work so far, this got me buying an EOS-M and into videography a couple of months ago and I've had a lot of fun with it.

Danne

You can check commits in source code. But it's around where you point out somewhere.

GrantB

I am having the same issue with the offset crop and lenses with small image circle.  Is there a repository for older builds?  Is it possible to build an older version from source somehow?

Danne


bern047

GrantB, yes all open source so fully possible as this is still experimental go for it and share on here : )

gabriielangel

Quote from: GrantB on February 28, 2023, 10:01:48 AM
I am having the same issue with the offset crop and lenses with small image circle.  Is there a repository for older builds?  Is it possible to build an older version from source somehow?

You can join the "MLV RAW ON EOS M" facebook group. Do a search for eosm builds, there is a repository with the older builds there.

GrantB

Quote from: gabriielangel on March 01, 2023, 01:20:49 AM
You can join the "MLV RAW ON EOS M" facebook group. Do a search for eosm builds, there is a repository with the older builds there.
Thanks for the helpful comment, that's just what I was looking for.  I'm not going to join that site though, so I suppose I will have to learn how to build ML.

Danne

Commit from 2023-01-11 is when cmos 5 was changed in this commit:
https://bitbucket.org/Dannephoto/magic-lantern_jip_hop_git/commits/b43a94ca7373e3ff8a76e5f7dfdac743f2f43e52

     if ((CROP_PRESET_MENU == CROP_PRESET_3K_EOSM || CROP_PRESET_MENU == CROP_PRESET_28K_EOSM || CROP_PRESET_MENU == CROP_PRESET_4K_EOSM || CROP_PRESET_MENU == CROP_PRESET_2K_EOSM || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM_frtp || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM_hdmi) && is_movie_mode() && get_halfshutter_pressed() && !RECORDING)

     {

-        return 0;

+       if (zoomaid) return 0;

     }



     //sticky push feature

     if (zoomaid == 0x2 && lv_dispsize == 10 && !get_halfshutter_pressed() && (CROP_PRESET_MENU == CROP_PRESET_3K_EOSM || CROP_PRESET_MENU == CROP_PRESET_28K_EOSM || CROP_PRESET_MENU == CROP_PRESET_4K_EOSM || CROP_PRESET_MENU == CROP_PRESET_2K_EOSM || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM_frtp || CROP_PRESET_MENU == CROP_PRESET_CENTER_Z_EOSM_hdmi) && is_movie_mode())

     {

-        return 0;

+        if (zoomaid) return 0;

     }



     //To be able taking photos while in movie mode. Will not work with isoauto or sticky push

                // {

                  //   return;

                // }

-                cmos_new[5] = 0x280;             /* vertical (first|last) */

+                cmos_new[5] = 0x300;             /* vertical (first|last) */

                 cmos_new[7] = 0xaa9;            /* horizontal offset (mask 0xFF0) */

                 if (ratios == 0x3)

                 {

-                    cmos_new[5] = 0x200;            /* vertical (first|last) */

+                    cmos_new[5] = 0x300;            /* vertical (first|last) */

                     cmos_new[7] = 0xf20;

                 }

                 break;


This was the old one:
cmos_new[5] = 0x200;            /* vertical (first|last) */
If you set cmos 5 in camera to 0x200, is it working better?

GrantB

Quote from: Danne on March 01, 2023, 07:48:00 AM
If you set cmos 5 in camera to 0x200, is it working better?
I tested this with Cosmicar 8.5mm f1.5, my smallest image circle lens.
2.8k 1:1 at 2.39:1

with CMOS 5 : 0x200 the image circle was offset by approximately the same amount as default, but to the other side

with CMOS 5 : 0x280 the image circle is approximately centered with even vignette in the corners (horizontally anyway, maybe the vertical can be tweaked with CMOS?).  All my other C mount lenses show no vignette with this setting.

https://imgur.com/a/7OH77Oq

At 0x280 I was able to record a video normally, but taking a photo while recording video did not work properly.  The video recording stopped and the CR2 was mostly black with a pink & white static bar.

Personally, I would love to have the option to disable photo during recording in favor of centered crops.  Even if a lens doesn't vignette, it is not performing at it's best when the crop is not centered. I'm happy to try poking some other registers to get a better vertical center if someone can point me in the right direction.

Edit: I just noticed that a previous poster had an issue with 3k.  The value I posted centers the display in 2.8k but it is not centered in 3k.  More experimenting... (0x240 works for 3k)

Danne

The problem is below 0x300 if af is enabled we have issues.

GrantB

Quote from: Danne on March 02, 2023, 08:19:12 AM
The problem is below 0x300 if af is enabled we have issues.
Well it's fortunate that C mount lenses don't have af then ;)
I see your point.  Should I test values between 0x300 and 0x3ff then?