Messages

1

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: August 12, 2020, 10:02:38 PM »

Good news is that some zoom lenses have bigger circle of confusion than usual when zoomed in, i have one where wide angle 4mm covers 16mm frame and when you zoom in to 12mm then it almost covers micro 4/3.I suspect a lot of zoom lenses work like this but not all of them, i have also krasnogorsk 3 lens but it works totally different and its hard to get focus because it needs to be exactly distanced from sensor or it wont work.

Which lens is that? Covering a 16mm frame at 4mm foals length would still make it a very wide lens on the 2.8k mode

2

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: August 12, 2020, 04:27:27 PM »

This is awesome!

Very much looking forward to properly try this out.

I did some crop factor calculations for different modes, to see how they compare relative to the width of a full frame sensor.

4.61x (1.6 * 2.88) in mv1080 x3crop 1800px wide
3.29x (1.6 * 2.06) in 2.5k @ 2.35:1
2.96x (1.6 * 1.85) in 2.8k @ 2.35:1

The 2.8k crop is a good match with lenses for Super16 sensors, since Super16 is 2.88x crop relative to full frame sensor width. This 2.8k mode comes really close to the Blackmagic Pocket Cinema Camera in terms of field of view.

EOS M sensor size: 22.3 x 14.9 mm
EOS M sensor width: 5184px

From my quick testing I conclude that the 2.8k mode has THE perfect crop factor for my Kiev 16U lenses! The Mir-11 12.5mm F2 (Kiev 16U lens) is used to it's max area without heavy vignetting, resulting in approximately a 43mm focal length relative to full frame.

3

Reverse Engineering / Re: UHS-I / SD cards investigation

« on: July 04, 2020, 05:03:25 PM »

SanDisk 64gb 170 MB/s Low Level Format @ 160mhz


SanDisk 64gb 170 MB/s Low Level Format @ 192mhz


SanDisk 64gb 170 MB/s Low Level Format @ 240mhz


SanDisk 64gb 170 MB/s Low Level Format @ Overclock Off


Interestingly the fastest speed I've seen was with 240mhz. Other than that, both of my cards (SanDisk 64gb 170 MB/s and SanDisk 256gb 95 MB/s) are responding the same to the overclock settings.

4

Reverse Engineering / Re: UHS-I / SD cards investigation

« on: July 04, 2020, 03:06:56 PM »

Awesome stuff! Did some benchmarks with my 95 MB/s card, but it works best with 192mhz. So 192mhz is not only for the 170MB/s cards.

SanDisk 256gb 95 MB/s Low Level Format @ 160mhz - Test 1


SanDisk 256gb 95 MB/s Low Level Format @ 160mhz - Test 2


SanDisk 256gb 95 MB/s Low Level Format @ 192mhz


SanDisk 256gb 95 MB/s Low Level Format @ 240mhz


SanDisk 256gb 95 MB/s Low Level Format @ Overclock Off


I've got a 64GB 170MB/s card too. Will report benchmarks from that one later.

5

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: September 23, 2019, 09:50:42 AM »

Could be added. But iso will stay at 100 until aperture is all the way open. So basically when you want to shoot at iso 100 outdoor you'll only be changing aperture when using the existing iso + aperture hot keys.

6

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: September 06, 2019, 10:41:31 AM »

Presets
These have already been introduced but I would suggest different (simple) names perhaps? Like:
- 1080 HD (16:9)
- 1080 HD 48fps...
- 1080 Wide (2:1)
- 2.5K ??
etc..

I think you have some good suggestions. One of the first things I did when working on the menu, is experiment with more universal preset names (what it does, instead of how it does it from a ML implementation perspective). I still think it could be nice, but after some talks with Danne I'm also fine with the names as they are right. At least now they're consistent across both preset sections.

And why is the "mv1080p MCM rewire" widescreen? Why does the "Mv1080 1736x976" have a ratio of 2.39:1? (though it doesn't show). Why are the start off presets different from the regular presets?..

The start off presets have their settings maximised while still allowing continuous recording. It's supposed to be an easy, no fuss way, of getting all the settings right (upper limit) for a specific recording mode (preset) without having to worry about which combinations of settings would still allow continuous recording. Therefore the "mv1080p MCM rewire" is widescreen and 14 bit. It can still record continuous at those settings. But in 2.5k or anamorphic 14 bit 16:9 won't get you much time at all, so it's defaults to lower bitrate and narrower ratio. Of course you can still drop the bitrate or make the ratio in "mv1080p MCM rewire" wider after applying the preset, but it's supposed to be a sensible default 'base'.

We're working on making the menu better, but I think we must embrace the fact that there'll always be questions, no matter how we make the menu. I don't think we should make different startup modes for Simple, Intermediate and Advanced usage. I think ML users are curious people. So if it defaults to a 'Simple' mode, people want to see what's possible in 'Intermediate' or 'Advanced' and will have questions. Also it will be a lot of work to make this, and I don't think it will result in more clarity and less questions.

What did help me a lot when just starting out with ML on EOS M are the video's from ZEEK! Even better than PDF documentation if you ask me

Veerle, you could if you like take a look at the Cine.lua script from Danne. It's actually very easy to make a couple of scripts with custom presets and naming like you suggest.

7

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: August 30, 2019, 08:00:05 AM »

Thanks Danne and Jip-Hop!

That Gain/Aperture adjustment is sweet!

Edit: just tried the Gain/Aperture adustment, when I press down I come into the Canon iso menu. What am I doing wrong?
Also when enabling AF, autofocus doesn't work that great anymore in mcmrewire mode.

Can you check if you have set the down button to ISO setting in Canon menu? I think that setting is in the yellow menu somewhere.

8

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: August 03, 2019, 04:45:13 PM »

I came across a black sun fix in DaVinci Resolve if I remember correctly. Maybe Google that?

9

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 18, 2019, 07:51:58 PM »

I was using vintage M42 lenses on Viltrox speedbooster. Sorry can't be of much help for the next two weeks. Don't have my camera with me either starting today.

10

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 18, 2019, 07:35:49 PM »

Tried latest build today. Can't do extensive testing from my vacation, also won't have access to computer for two weeks so only briefly played back some recordings in camera. Noticed some pink frames but not too many.

Noticed camera freezing quite a lot with 4k rewire preset and the 10x focus helper on half shutter press. Both standard and dark mode. Had to disable the feature. Seems to work much better in 2.5k mode.

Also had the camera get stuck on shutdown a few times. Would be stuck at sensor cleaning and only opening the battery door would actually shut it down.

11

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 17, 2019, 09:09:17 PM »

That's how it works I think! Lower shutter speed, lower fps. Not auto iso for sure 

By the way how do you post process auto iso recordings? I read that the transition looks smooth on screen while recording but isn't smooth when playing back in DaVinci Resolve.

12

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 17, 2019, 12:39:06 PM »

There's something else with eosm sharing trash can with pressing down. Not sure buttons are "longpress" sensitive.

I think you can find which keys are long press sensitive in the Lua api docs: https://builds.magiclantern.fm/lua_api/modules/constants.html#KEY

Keys that have the unpress state can be used for long press.

13

Scripting Q&A / Re: Double Press issues

« on: July 13, 2019, 10:39:59 AM »

Hi garry23,

I'm using flags already and I'm aware I shouldn't return false always, but for this simple example I return false for all keys just to be clear that no keys should be handled as normal (they should all be blocked). Makes it all the more obvious when a key slips through.

From Lua api docs: "Event handlers will not run if there's already a script or another event handler actively executing at the same time."

This is a big problem for what I'm trying to do. If I double press the play key, I call a function to switch raw video preset and refresh live view. This apparently keeps the camera busy (it's actively executing a script). Therefore the key press event handler won't run the third time I press play, and the default action isn't prevented. Now the camera tries to go into play mode while still switching raw video presets and refreshing live view. This causes conflicts and partially locks up the camera.

So with a double press and a few seconds of patience it works fine, but if I accidentally triple press I lock up the camera and need to reboot or switch modes.

Conclusion: Until there's a reliable way to prevent the default action of a key I can't make this work.

Still curious if using task.create with a high priority would make a difference. But I still haven't figured out how to specify the priority...

14

Scripting Q&A / Re: Double Press issues

« on: July 12, 2019, 04:48:32 PM »

I've now tried the approach from the calc.lua example.
Now I only have one event handler for the key presses and another infinite loop with task.yield(100).
Seems to work a lot better already, especially for opening the ML menu.
I've added a cooldown period too, but I can still get the camera to lock up by pressing keys quickly.

The camera no longer responds to any buttons on the back, the screen is either black or a frozen still.
But it still responds to switching to photo mode with the mode dial and back to video mode.
Then it works as normal again.
Also I can shutdown the camera with ON/OFF button still.

Code: [Select]

-- Double Press
-- Double Press works fine, but combined with the rest it may still cause issues

-- Simple test, doesn't lock up camera
first_press_time = nil
second_press_time = nil
cooldown_start_time = nil

event.keypress = function(k)

    -- Temporarily ignore PLAY keys during cooldown period
    if cooldown_start_time ~= nil and (dryos.ms_clock - cooldown_start_time) < 1000 then
        return false
    end

    if(first_press_time == nil) then
        first_press_time = dryos.ms_clock
    else
        second_press_time = dryos.ms_clock
    end

    -- Don't respond to any keys
    return false
end

function main_loop()

    while true do

        if lv.paused == true then
            lv.start()
        end

        if(first_press_time ~= nil) then
            -- If after 500ms no second key is pressed
            -- Don't wait and handle first key press
            if(dryos.ms_clock - first_press_time) > 500 then
                display.notify_box("Single")
                cooldown_start_time = dryos.ms_clock
                first_press_time = nil
                if menu.visible == false then
                    menu.open()
                end
            elseif (second_press_time ~= nil) then
                -- This is a double press
                cooldown_start_time = dryos.ms_clock
                first_press_time = nil
                second_press_time = nil
                display.notify_box("Double")
                lv.pause()
                -- lv.start()
            end           
        end

        task.yield(100)
    end
end

console.hide()
main_loop()

15

Scripting Q&A / Re: Double Press issues

« on: July 12, 2019, 03:31:07 PM »

Thanks garry23, that was great advice 
Though also this technique I'm not quite out of the woods yet.
With below example I get funky results when I keep basing the PLAY for a while.
E.g. if I press it quickly, maybe 40 times, the camera locks up for some time.
When it responds again it often shows me, in the playback mode, a photo I've taken.
Clearly the intention of the script is to not allow default action of the keys.
Yet still a key event slipped through.

While this may be extreme usage it shows it's not robust.

With my more complex script the issues and lockups are worse, also with less key pressing.

Code: [Select]

-- Double Press
-- Working kind of

first_press_time = nil
second_press_time = nil

event.shoot_task = function()

    if(first_press_time == nil) then
        return true
    end

    -- If after 500ms no second key is pressed
    -- Don't wait and handle first key press
    if(dryos.ms_clock - first_press_time) > 500 then
        display.notify_box("Single")
        first_press_time = nil
        return true
    end

    if(second_press_time ~= nil) then
        -- This is a double press
        first_press_time = nil
        second_press_time = nil
        display.notify_box("Double")
        lv.pause()
        lv.start()
    end

    return true
end

event.keypress = function(k)

    if(first_press_time == nil) then
        first_press_time = dryos.ms_clock
    else
        second_press_time = dryos.ms_clock
    end

    -- Don't respond to any keys
    return false
end

16

Scripting Q&A / Re: Double Press issues

« on: July 11, 2019, 11:22:43 PM »

I think I now have a working example, which uses event.shoot_task instead of task.create().
Honestly I don't know what event.shoot_task actually is, how often it refreshes etc.
And I'm still curious about the priority syntax for task.create().

This test blocks all keys, and no keys slip through.
Seems to reliably detect single and double press, which is what I wanted.

Doesn't this run into the multitasking limitations because it's all in one task?

Code: [Select]

-- Double Press
-- Working

first_press_time = nil
second_press_time = nil

event.shoot_task = function()

    if(first_press_time == nil) then
        return true
    end

    -- If after 500ms no second key is pressed
    -- Don't wait and handle first key press
    if(dryos.ms_clock - first_press_time) > 500 then
        display.notify_box("Single")
        first_press_time = nil
        return true
    end

    if(second_press_time ~= nil) then
        -- This is a double press
        first_press_time = nil
        second_press_time = nil
        display.notify_box("Double")
    end

    return true
end

event.keypress = function(k)

    if(first_press_time == nil) then
        first_press_time = dryos.ms_clock
    else
        second_press_time = dryos.ms_clock
    end

    -- Don't respond to any keys
    return false
end

17

Scripting Q&A / Re: Double Press issues

« on: July 11, 2019, 10:26:12 PM »

Ah yes good question.

18

Scripting Q&A / Re: Double Press issues

« on: July 11, 2019, 10:14:53 PM »

What I understand is that there's no easy fix for the Lua multitasking limitations.
But the config.lua issue I ran into is a separate matter and there's already a fix and pull request for those.

19

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 11, 2019, 10:05:35 PM »

Good stuff Danne! Briefly tried it out just now and autofocus in mv1080 MCM rewire is a lot nicer to use now that live view stays snappy. It's becoming more polished every time 

Also the 10x crop, working for all presets, is a nice way to check focus before recording with manual lenses. Well done!

But so many options mean there's a lot of different ways to configure. They're all in different places: Crop mode dropdown and Crop mode submenu, RAW video submenu. And once you've got all set up, e.g. how you like to shoot with mv1080, these settings will be gone once you setup how you like to shoot in 2.5K mode. Personally I'd like to shoot with 14-bit in mv1080 in 16:9, and use a lower bitrate, e.g. 10, and narrow aspect ratio for 4k.

For me that would be a great win for RAW recording: if I could just setup how I like to use each mode before a shoot, and quickly toggle between them during the shoot. Without a need to change many settings in different places, having to remember each and watch out for misconfigurations.

We now basically have global options, that apply always. Regardless of the selected preset in Crop mode. I think we could use a couple of global settings (maybe FPS and aspect ratio). But in addition to that for each preset I'd like to be able to set local settings, which don't apply to the other presets (bitrate, if I want to use x3 crop toggle or x10 crop toggle, or none, maybe even the option to override global settings such as FPS or aspect ratio).

Would love some feedback on the script I posted yesterday. However I'm away from my camera and computer for three weeks. Would have loved to make it usable, but at the moment it's incomplete.

If a bug it should go into lua branch. Do a pull request?

There should already be a pull request that fixes the Lua issue according to dfort.
https://bitbucket.org/hudson/magic-lantern/pull-requests/940/manual-lens-info-support-to-crop_rec_4k/diff#comment-108992157
https://bitbucket.org/hudson/magic-lantern/pull-requests/939/dynamic-length-elns-block/diff#chg-scripts/lib/config.lua

But fortunately I can just replace the config.lua with the fixed one myself and get the benefits without having to wait for a merge or compile ML myself 

20

Scripting Q&A / Re: Double Press issues

« on: July 11, 2019, 09:35:38 PM »

Do you have other scripts running?

Good question! Just tried on a fresh install of the newest build from Danne. Only Lua module loaded and this test script. But the issue remains.

Multitasking limitations, see https://builds.magiclantern.fm/lua_api/modules/task.html and https://www.magiclantern.fm/forum/index.php?topic=14828.msg179227#msg179227 .

No easy fix for this one

That's a bummer
Will need to use creative workarounds then.

As a side-note, how can I set priority when calling task.create()? I thought it would just be an integer but I can't seem to get the syntax right.

21

Scripting Q&A / Double Press issues

« on: July 11, 2019, 05:25:34 PM »

This script should disable all keys, and log if there was a single or double keypress within 3 seconds.
When you run this script, I'd expect you'd be unable to navigate out of the menu.
Single presses are ignored.
But when you double press, it responds as a single press...
How's that possible with return false on all key events?

Code: [Select]

-- Double Press
-- Not working

key_counter = 0
function check_double_press()
    sleep(3)
    if(key_counter == 2) then
        -- Double press
        display.notify_box(tostring(key_counter))
    elseif(key_counter == 1) then
        -- Single press
        display.notify_box(tostring(key_counter))
    end
    key_counter = 0
    return false
end

event.keypress = function(k)

    key_counter = key_counter + 1
    if(key_counter == 1) then
        task.create(function()
            check_double_press()
        end)
    end   

    -- Don't respond to any keys
    return false

end

22

Scripting Q&A / Re: Slow to close ML menu

« on: July 11, 2019, 04:40:06 PM »

I now open the menu with task.create().

Code: [Select]

    task.create(function()
        menu.open()
    end)
This way at least my script will open the menu reliably.

I tried to experiment a bit with the priority of the task.create() function.
But I don't understand how to specify the priority.
The docs say I should specify with an integer, but this doesn't work:

Code: [Select]

    task.create(function()
        menu.open()
    end, 31)
Also this doesn't work:

Code: [Select]

    task.create(function()
        menu.open()
    end, 0x1F)
My current problem is that the menu opens fine, but seems to capture keypresses in a strange way when it's opening.
See the minimal example below. When you run the script and press the PLAY button in Live View, it will open the ML menu.
If you wait for it to open and press PLAY again, it will close the menu.
But when you start in Live View and quickly tap PLAY twice, it will open ML menu en the submenu if the selected item in ML menu.
Seems like the key event doesn't even make it to my script in this scenario...

Code: [Select]

-- aa PLAY key test
-- Test

menu_opening = false

event.keypress = function(k)

    -- Check if PLAY key is pressed
    if k ~= KEY.PLAY then
        -- Pressed other key
        return true
    end
   
    -- Get out of ML menu
    if(menu_opening == true) then
        menu_opening = false
        task.create(function()
            menu.close()
        end)
        return false
    end

    -- Open the presets menu
    -- Camera glitches if not calling with task.create...
    menu_opening = true
    task.create(function()
        menu.open()
    end)
    return false
end

23

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 11, 2019, 01:41:03 AM »

Also according to aprofiti there's a bug in the config.lua library. And it seems like there's a fix for it.
Maybe a good idea to include the fixed config.lua library in the next build?

24

Scripting Q&A / Re: Script state at camera switch off

« on: July 11, 2019, 01:37:53 AM »

Thanks aprofiti!!

I need to take another look tomorrow, but a quick test with the config.lua from manual_lens_info you linked to solved another issue I was having.
In this script (proof of concept) I was calling config.create_from_menu multiple times.

Code: [Select]

config.create_from_menu(preset_menu_ratio)
config.create_from_menu(preset_menu_fps)
config.create_from_menu(preset_menu_a)
config.create_from_menu(preset_menu_b)
config.create_from_menu(preset_menu_c)
config.create_from_menu(preset_menu_d)And I couldn't figure out why everything was falling apart...

With the new config.lua at least this seems to be working

25

crop_rec and derived builds / Re: Danne's crop_rec_4k experiments for EOS M

« on: July 11, 2019, 01:28:23 AM »

Very nice ^^

I've been working on a script. Would be great if you could take a look.
Script should be set to autorun.

Then each time you press the PLAY key in Live View, a menu pops up.
From there you can choose one of the RAW recording presets (HD, HD crop, 2K and 4K).
Next time you press PLAY it will default to the previous preset.
So you can quickly toggle between two modes just by pressing PLAY a couple of times.

You'll always toggle between the two most recent presets.
The presets have some global options (FPS, ratio) but can also have individual settings (like bitrate).
I like to record in 14 bit for HD and 12 or 10 in 2k and 4k.

If you press PLAY and you want to go to the playback menu, it's only a couple of clicks away.

I tried before to use the INFO key, but that one has already a pretty complex toggle behaviour.
Also the PLAY button is commonly used in the ML menu so thought it would be a good fit to toggle stuff with.

Currently still many issues so it's a first proof of concept.
Hope you find it interesting.

P.S. make sure the resolution dropdown in the in "RAW video" submenu is set to the highest resolution.
All presets will then take the highest resolution possible.