Canon EOS M

[masc]

The only two settings without bottom line are rewire=old and rewire=off-2+2. But in rewire=old I get stairs, hard focus pixels and more artifacts. So in this build I prefere rewire=Off, reg_skip_top=-2, reg_skip_bottom=+2.

You'll find a png with some marked areas in the frame where I looked at details and my receipt file.
https://www.dropbox.com/s/wddfxe3p7zmdsn1/RewireTestrun.zip?dl=0

[jacquaviva]

Thank you Dfort. I can get rid of focus pixels by using the debayer amaze in MLVapp, but can't use it by exporting to dng sequence. How to ?

[Danne]

Set chroma smooth to 3x3.

[Danne]

@masc
Settings right now if test_rewire is set to off:

Code: [Select]

        skip_top = 84;
        skip_right = 60;
    skip_bottom = 0;
Let´s apply your optimised setting "So in this build I prefere rewire=Off, reg_skip_top=-2, reg_skip_bottom=+2.":

Code: [Select]

        skip_top = 82;
        skip_right = 60;
    skip_bottom = 2;
Only one problem. The first commit after noticing the thin red line was exactly the setting above:
https://bitbucket.org/Dannephoto/magic-lantern/commits/5cb143d56c2dcb9a16f27c5094e4f8f1ee8fb52b

Your comment to that commit:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg212152#msg212152

So, I revert back to the first commit as long as we all agree this problem is not as easy as we first thought? Any other thoughts?

Also note that when test_rewire is set to old it´s the exact lines as with the build before any thin redline fixes were applied(same as february 15th).

[masc]

Very strange. Do we have a kind of sign error somewhere? Don't understand all this at all.

[Danne]

Placebo?
Anyway. Here´s a build with your proposed settings working best:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959

Here is the feb 15th build compiled exactly before the thin red line fix in commit tree(compiled today and renamed):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_2019Feb15.EOSM202.zip

[jacquaviva]

Thank you, chroma smoothing works with dng out.
Danne, is there a way to save crop mode activated when booting the camera. I always have to switch it on again. Thanks

[Danne]

Yes, you can enable it but I havn´t found a way to disable it when changing presets in crop rec once it´s enabled. In crop_rec.c put in this at the top:

Code: [Select]

#include "crop-mode-hack.h"
Then inside static int crop_rec_needs_lv_refresh(): in crop_rec.c put in following:

Code: [Select]

if (crop_preset == CROP_PRESET_mcm_mv1080_EOSM)
{
        movie_crop_hack_enable();
}
Compile.

[masc]

Placebo?
Anyway. Here´s a build with your proposed settings working best:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959

Here is the feb 15th build compiled exactly before the thin red line fix in commit tree(compiled today and renamed):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_2019Feb15.EOSM202.zip

No, don't think so. The "stairs" are very easy to identify at 45° edges, same for the red line. But what happened for your "rewire=old" preset? Why activates it the stairs, and -2+2 doesn't. And all this does not fit to yesterdays build. Something must be wrong.

Will test again the posted builds.

[jacquaviva]

Thanks Danne, I don't know to compile but I'll figure it out.
Thanks you again for this work !

One question about MLVapp, is there a way to set by default 3x3 chroma smoothing, I have to set it for each MLV file.

[masc]

@Danne:
I expect indeed a sign error somewhere. I again tested the first build after the red line (the one with the stairs). Reproduced all I saw yesterday. BUT: reg_skip_top=-4 and reg_skip_bottom=+4 looks perfect
What happens for:

Code: [Select]

        skip_top = 86;
        skip_right = 60;
    skip_bottom = -2;
@jacquaviva
Activate it once for one clip, Ctrl+C (maybe activate in mask chroma smoothing only), Ctrl+A, Ctrl+V.

[Danne]

-4, +4, link or name of build used?
What's a "sign error"?

[masc]

Build used is: crop_rec_4k_mlv_snd_isogain_1x3_presets_2019Feb17.EOSM202
-4+4 looks perfect. Registers have 82 and 2 by default, you wrote

Build before:
-2+2 looked perfect. Registers were 84 and 0 by default.

So I think the math behind is not default+offset, it is default-offset. The algebraic sign (+ instead of -) should be wrong - or I am... confusing... 

So I would try 86 and -2 next.

[Danne]

Build used is: crop_rec_4k_mlv_snd_isogain_1x3_presets_2019Feb17.EOSM202
-4+4 looks perfect. Registers have 82 and 2 by default, you wrote

-4+4 equals:

Code: [Select]

        skip_top = 78;
        skip_right = 60;
    skip_bottom = 6;
86 and -2 as suggested would become

Code: [Select]

        skip_top = 86;
        skip_right = 60;
    skip_bottom = -2;And then we have a fat white border at the bottom.

We need to shave at minimum 2 at the bottom to get rid of the bottom pixels:

Code: [Select]

    skip_bottom = 2;Since default skip_top is 72 we can safely add back what´s shaved at the bottom since we here start at:

Code: [Select]

    skip_top = 84; so decreasing to 82 will keep us at 1736x976(16:9):

Code: [Select]

        skip_top = 82;
        skip_right = 60;
    skip_bottom = 2;
I cannot reproduce the issue described so I really suggest you download my branch and get right into crop_rec.c and compile crop_rec.mo with any optimised settings you come up with. It´s easy with Compiler.app. Just get into the modules area and find this menu:

[masc]

-4+4 equals:

Code: [Select]

        skip_top = 78;
        skip_right = 60;
    skip_bottom = 6;

...if the register screen does what we think it does...

86 and -2 as suggested would become

Code: [Select]

        skip_top = 86;
        skip_right = 60;
    skip_bottom = -2;And then we have a fat white border at the bottom.

Have you tried out? Oh man... I really don't understand what happens here.

I cannot reproduce the issue described so I really suggest you download my branch and get right into crop_rec.c and compile crop_rec.mo with any optimised settings you come up with. It´s easy with Compiler.app.

What a shame it seems I am the only one getting this. Unfortunately I am here with OSX 10.9, which is not supported by your compiler app (or by brew).

[Danne]

Yes, tested.
It is not evident what to look for to me. But general tests on static scenes I cannot see anything significant and judging from that we can get different results from same builds and commits it suggests it´s a problem somewhere else.

Why isn´t compiler.app working? Can you try double clicking the main.command inside Compiler.app/Contents/?

You might wanna give the command admin rights:

Code: [Select]

chmod u=rwx main.command

[masc]

Brew isn't supported on OSX 10.9 (or the packages needed). So no chance for your app. It won't install anything.

[Danne]

Ok, reproduced. Wtf! Some alignment issue:


82, 0


-4, +4



82, 0


-4, +4



Brew for 10.9?
https://coolestguidesontheplanet.com/setting-up-os-x-mavericks-and-homebrew/


EDIT:
Tested again and cannot reproduce it now. Crazy. Can´t make sense of it.

[masc]

Yes, that looks like what I see here. Best use a wideangle lens where a lot is in focus. Then search trees and hard contrast edges at 45°. Very easy to reproduce this way.

[Danne]

I did a slight change and it seemed to be enough. Is this version working for your wide angle lens?
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_2019Feb17.EOSM202.zip

Code: [Select]

        skip_top = 81;
        skip_right = 60;
    skip_bottom = 3;

[DeafEyeJedi]

Tying to reproduce this w both 10mm 2.8 & 11-20mm 2.8 lenses to no avail. I don’t blame you guys for this strangeness though. I’m pointing at a white wall w a fan (to show /aliasing/moire effects) and will try again w the latest build from 50 mins ago.

[masc]

I think, first of all, we need a simple strategy to reproduce. I loaded the ISO 12233 test chart, printed with a laser printer... not perfect, but should be enough. I took EF-M 18-55 STM @ 55mm, fully open. And now you might see which picture is which setting:


I think the pics look very different... see the focus pixels and the amount of moiree.

[Danne]

How does the last build perform?

[a1ex]

Best guess: this must be 3x3 readout with line *and* column skipping!

Here's a test on the resolution chart (roughly this, but updated for movie crop mode, where IIRC you can't just toggle between x1 and x5 zoom freely). This test will take 2 images, one in the tested video mode and another in x5 zoom, with no absolutely camera or subject motion between them. That will reveal the exact pixel binning mode. Tested on 5D3 (iso-research branch, but should work on any recent experimental build).

Code: [Select]

-- Pixel binning test
-- Save this file as bintest.lua or similar.

--[[
Requirements:
- lua.mo (of course)
- silent.mo
- test subject: resolution chart, perfectly focused and with good light
- camera standing still (important) on a flat surface
- absolutely NO camera or subject movement during the test (important!)
--]]

menu.close()
sleep(1)
display.notify_box("Preparing...")
sleep(1)
assert(camera.mode == MODE.MOVIE)
assert(lv.running)
menu.set("Silent Picture", "Silent Mode", "Simple")
menu.set("Shoot", "Silent Picture", "Simple, DNG")
menu.set("Movie", "RAW video", "OFF")       -- just in case (no need to load mlv_rec or mlv_lite)
menu.set("Movie", "RAW video (MLV)", "OFF") -- but if you do, let's turn them off
sleep(5)

-- first test image in 1080p 3x3 (derived from Canon's crop mode)
display.notify_box("First test image...")
menu.set("Movie", "Movie crop mode", "ON")
menu.set("Movie", "Crop mode", "mv1080p MCM rewire 16:9")
sleep(1)

-- refresh LiveView
camera.gui.menu = true
sleep(1)
assert(not lv.running)
camera.gui.menu = false
sleep(1)
assert(lv.running)
sleep(2)

-- take a silent picture
key.press(KEY.HALFSHUTTER)
sleep(1)
key.press(KEY.UNPRESS_HALFSHUTTER)
sleep(5)

-- now turn off crop mode and enter x5 zoom
display.notify_box("Second test image...")
menu.set("Movie", "Crop mode", "OFF")
menu.set("Movie", "Movie crop mode", "OFF")
sleep(1)

-- refresh LiveView once again, just in case
camera.gui.menu = true
sleep(1)
assert(not lv.running)
camera.gui.menu = false
sleep(1)
assert(lv.running)


lv.zoom = 5
sleep(20) -- large delay to "fix" vertical stripes

key.press(KEY.HALFSHUTTER)
sleep(1)
key.press(KEY.UNPRESS_HALFSHUTTER)
sleep(5)

-- cleanup
menu.set("Shoot", "Silent Picture", "OFF")
lv.zoom = 1
display.notify_box("Finished.")

edit: after writing and testing this script, I've just realized it would be enough to take one test picture with our crop mode enabled (i.e. 1080p 3x3 derived from it), and another one with our crop mode disabled (i.e. 1:1 readout). In both cases, Canon's movie crop mode would be active.

BTW - if my hypothesis is true, the fix is somewhere in the CMOS registers. You are lucky - the search space is very small

Tweaking skip offsets will do absolutely nothing to fix the image aliasing. These offsets will specify how to interpret the raw data in post (i.e. how many border pixels to throw away). The effect of that would be only in the alignment of focus pixel maps, but that won't help with the aliasing issue in any way.

[masc]

How does the last build perform?

I would say even worse... the moiree is so extreme, that you can see it in liveview already.