Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kfprod

Pages: [1] 2
1
General Chat / Re: How many people would like to donate?
« on: October 17, 2019, 11:37:24 AM »
My 2 cents: isn't this one of the main things what the ML Bitcoin was set up for, so that development could continue even when lead developers needed pay? I say use that money to pay lead developers to continue the development and when that money runs out do another collection.

The vote now after 5 days on Twitter is 57% to develop "new" cams (1 day left on the voting). The Mark IV went on sale in September 2016, over 3 years now. I think this needs to happen or the project and forum will just slowly disappear as the features of the older models really isn't up to the task anymore.

5D Mark IV dynamic range score (Landscape 13.6 EV) offers nearly a 2-stop advantage over the 11.7 EV recorded on the 5D Mark III. 2 stops of dynamic range is massive. It's like comparing the Arri Alexa with the first RED camera released. One sensor is still around winning Oscars, the other isn't used anymore. Compressed RAW video with 13.6 EV and Canon Color Science (beats Black Magic and RED every time) would be an amazing boost to the project.

2
Raw Video Postprocessing / Re: DaVinci Resolve 12 and ML Raw
« on: November 23, 2016, 12:32:08 PM »
66dellwood: The EOS HD lut is much better than the Hunter LUT: http://www.eoshd.com/2013/11/introducing-eoshd-film-lut-5d-mark-iii-raw-resolve-10/

I'm also interested in the white balance plugin, it's so weird that Resolve still doesn't have a color picker!?

3
Raw Video Postprocessing / Re: DaVinci Resolve 12 and ML Raw
« on: November 22, 2016, 05:54:56 PM »
Hi,

There's an amazing amount of knowledge here but very hard to get an overview of the work you've done.

I work a lot with mixed footage from ML, Red and Alexa and I'm looking for a simple way to get my Magic Lantern footage to the Alexa Log-C colourspace (as it is now the industry standard).

The best way I've found of doing this so far is with the Cinelog DCP transformation Luts from http://www.cinelogdcp.com/ but it does seem a bit odd the transformations that happen there and I feel there must be an easier (better?) way...

Also your OpenFX plugins look amazing but I don't really know where to start, is there a site where you show how to use them and what they're for?

Best regards,
Karl

4
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: January 07, 2015, 02:35:57 PM »
I think that as Lars says the record function is the most important. If there's any way of playing back the latest clip on the Atomos that would be amazing too (but that's probably not part of this spec)...

Sorry but I don't have the 5d camera at the moment, it's used in production. Lars do you have yours available to test this? I'll get mine back later this month.

5
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: December 15, 2014, 01:24:14 PM »
Good to hear that more people are requesting this. Unfortunately I'm just a hacker and not a proper programmer so I can do some things but I haven't been able to get this to work- although I have tried all ways I could think of. If this could get some attention from the "real" programmers here that would be fantastic!

6
Modules Development / Re: Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo)
« on: September 27, 2014, 01:14:21 AM »
Regarding MLV large file support is there a reason you want to have all variables within mlv_rec.c? I'm thinking it would be better to set a global variable in bootflags.c where the system actually knows if it is an exFAT card- line 171 in bootflags.c ((p.type == 7) // ExFAT)

Right now mlv_rec.c just knows what camera models have support for exFAT but doesn't check.

Code: [Select]
    /* not all models support exFAT filesystem */
    uint32_t exFAT = 1;
    if(cam_5d2 || cam_50d || cam_7d)
    {
        exFAT = 0;
        large_file_support = 0;
    }
I've updated the long unique exFAT file names that I've been using and will upload it soon for you to consider. File name examples are: 20140927_102314_ n4yl.MLV and if you've enabled camera number and take number: 20140927_102314_cam1_take3_7pbi.MLV (The last 4 characters are just randomized "0123456789abcdefghijklmnopqrstuvwxyz"). I know some people are shooting multi camera and have problems when they get the same file name.

7
General Development / Help with coding exFAT check
« on: August 07, 2014, 01:12:46 PM »
I know that an autodetection for exFAT can be done with the low-level routines from bootflags.c but I can't work out how to do it as I'm not an expert programmer. Could someone please help me write a function to do this? It would improve mlv_rec and raw_rec. At the moment it's not correct the way it checks for exFAT and also it would help improve the naming convention I'm working on ( first submission is here: https://bitbucket.org/hudson/magic-lantern/pull-request/527/mlv_rec-exfat-naming-suggestion/diff )

Thanks,
Karl

8
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: August 07, 2014, 11:22:39 AM »
This may help: Atomos have released their HDMI START/STOP TRIGGER & TIMECODE standard as open source. The Atomos protocol for HDMI is available for free from www.atomos.com/hdmi-protocol

I received the PDF by just filling in the form. Unfortunately "Neither the whole nor any part of the information contained in, nor the product described in, this document may be adapted or reproduced in any material form except with the written permission..."

So sign up there if you want to have a look and you'll get it within 24hrs.

On another note the Atomos can trigger by just listening to if the camera outputs a REC RUN hdmi time code (not using the REC COMMAND) so if we could just make the camera output that instead that would also work...

Regarding the other part of what I've been testing, writing h264 to the SD card and RAW to the CF card, there is something that happens after 12 seconds and the camera crashes. Is that the processor that's overused? Perhaps someone could look into this. If you do just set

Code: [Select]
            case RAW_RECORDING:
                raw_start_stop(0,0);
                break; to

Code: [Select]
            case RAW_RECORDING:
                raw_start_stop(0,0);
                return 1;
and change the normal camera setting to write to the SD card but the RAW file to the CF card. This is the quickest way

Code: [Select]
        //if(card_spanning)
        //{
            filename[0] = 'A';
        //}
If we could get this to work this would also solve the Atomos recording as return 1 will let the normal camera h264 recorder get on with what it was doing with all the HDMI stuff as well.

9
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 30, 2014, 05:00:21 PM »
I did put in the PROP_HANDLER with a Notify Box, it was there all the time..

10
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 29, 2014, 04:15:48 PM »
Back from a job and doing some tests again. When I do

prop_request_change(0x80040057, &aux, 0);

I get a red box with PROP_LEN(80040057) and

ML ASSERT:
PROP_LEN(80040057) = 0
at ../../src/property.c:325 (prop_request_change), task GuiMainTask
lv:1 mode:3

This is not the same as earlier. Perhaps it's only the error handling code that has changed?

I'm still wondering if it would be worth it to try and do the same test with these values (converted to 0x800...) but I can't decompile ff1f18b4 -> 0x800...

ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

11
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 19, 2014, 01:26:34 AM »
So I've tried this with the recorder attached but as you say it doesn't trigger.

Code: [Select]
PROP_HANDLER(0x80040057)
{
    NotifyBox(1000, "%d ", buf[0]);
}

static void run_test()
{
    msleep(1000);
    uint32_t aux = 0;
    prop_request_change(0x80040057, &aux, 4);
    beep();
}
What about the others

ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

Could any of them be used? I don't have a decompiler set up unfortunately. Most of this is really over my head  :(

I tried a couple of other ways to do the raw to the CF card and h264 to the SD but it always crashes after a while.

12
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 19, 2014, 12:10:20 AM »
Thanks g3gg0 I checked now and that's a bit over my current skill. But I've put all the other changes I wanted into mlv_rec.c and the final names are in this style

20140618_232314_c1_t3_djhc.MLV

Added a menu item for "camera" 0-99. c1 and t1 is only added if you have camera and take enabled. The last 4 are just randomized "0123456789abcdefghijklmnopqrstuvwxyz".

It checks is_camera("5D3",  "1.2.3") || is_camera("5D3", "1.1.3") but doesn't check for exFAT.

Would you like to check the changes, should I make a pull request from web browser like this?
http://www.magiclantern.fm/forum/index.php?topic=7940.0

It would be great if you could have a look at this post too: a1ex thought maybe you knew the answer to something at Reply #34.
http://www.magiclantern.fm/forum/index.php?topic=12022
I have a shoot next week where it would be amazing if I could get the trigger talked about there to work along with the new file names... Thanks!

13
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 18, 2014, 04:19:21 PM »
DEVs: Is there a global variable that says if the file system is exFAT? Currently mlv_rec.c only checks that its not one of the cameras that doesn't have the option (cam_5d2, cam_50d, cam_7d). It doesn't actually check what file system the card is.

14
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 18, 2014, 09:38:54 AM »
It's not 10 bit but 8 bit, that is what the Canon camera HDMI outputs. It is however 422 instead of 420 and it has never been through an h264 codec so that's good.

But if someone does get the h264 simultaneous recording to work without problem I'd suggest buying the SmallHD dp7 instead of the Atomos though, it's a better monitor and you'll only use the h264 files as proxies anyway. Unless you do a lot of interviews where you can't shoot raw, then the benefits of the recorder will be worth it.

15
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 17, 2014, 09:40:05 AM »
I love that the firmware coming out of Japan has FLAME_RATE instead of FRAME_RATE  8) Lock and LoLL!!!

It would be good to hear from g3gg0 if he confirms a1ex's analysis that it should be safe to play around with and I'll do that.

A1ex is that going through and checking all the different states of PROP_TIMECODE_HDMI_REC_COMMAND? In prop_request_change(0x80040057, &aux, 4); would it make sense to step through &aux and 0-4 or does the test function do that?

Could also be that because you don't have anything connected to the hdmi port it just won't trigger, maybe just putting a cable in to a TV (or at least just putting a cable in) would do the job and give you that triggered NotifyBox?



16
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 16, 2014, 05:13:55 PM »
Something like:
prop_request_change(PROP_TIMECODE_HDMI_REC_COMMAND, &v, 1);

I'd love to give it a go... Only this comment scares me off.
/** Properties are persistent (saved in NVRAM) => a mistake can cause permanent damage. Undefine this for new ports. */
/** The 5D3 port is young, but... let's give it a try! **/
#define CONFIG_PROP_REQUEST_CHANGE

Please help!!


17
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 16, 2014, 04:31:11 PM »
I agree that would be a nice solution. That does mean another app before running the unpacking app or asking the MLV Mystic programmers to implement it though.

But keeping the file name the way it is now and extracting the advanced file name that ansius suggests in postproduction would work.

18
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 16, 2014, 04:14:26 PM »
Possible breakthrough:

I found this string
ff1936c8 PROP_TIMECODE_HDMI_REC_COMMAND (%d)

(Also:)
ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

In ROM1.BIN.strings converted from the ROM1.BIN of the 5d3.123 release.

Can someone please help me turn this into a function that I can trigger?

Thank you for the tutorial a1ex you should make it a sticky: http://www.magiclantern.fm/forum/index.php?topic=12177.0

19
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 16, 2014, 12:40:31 PM »
I can come up with hundreds of solutions for that for exFAT but with 8 characters it becomes difficult. What would you suggest?

A good solution for exFAT would be to have a user input that defaults to the last 3 digits of the serial number as you say but that you could also set to just 1, 2, 3 or whatever number you want to identify the camera. The file name then has the addition CAM1, CAM2, CAM3 (or CAM555 if you didn't change the field and the serial number ended with 555).

File name then could be 31DE2014-1003-CAM1-XXX.raw (or 31DE2014-1003-CAM555-XXX.raw).


20
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 16, 2014, 11:08:05 AM »
Interesting… Thought about this a bit now and can’t come up with an ideal solution. Basically it would be better for the clutter but worse for the user. Everytime you want to make sense of the name you'd have to have a base 36 parser. Checking the file name on your PC or camera wouldn't make sense on first sight. And they wouldn't end up in order unless you sort by date. Also reconnecting shots and knowing which was which would be hard after you've "unpacked" the name.

If we did abbreviations for the months like

JA
FE
MR
AP
MY
JN
JL
AU
SE
OC
NO
DE

An exFAT name would be
14DE2014-1003-XXX.raw (where XXX is base 36 to make it unique)

That wouldn’t work for the DOS name but the DOS name could be
DE14LIL0

(where LIL0 is base 36 for 1003860, ie 10:03.860 hour minute and 3 milisecond digits) - that should make it unique enough for almost everything while still giving some information about what’s there.

I used http://www.translatorscafe.com/cafe/EN/units-converter/numbers/c/

21
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 15, 2014, 12:58:41 PM »
The 5d3.123 release. I've made a file called "M14-2333-55-LONGFILENAMEHERE.RAW" without problem and it shows up in the raw playback also. Could it be a problem using longer file names even if it works?

If you could help me modify the RandomString function I wrote about earlier so it compiles I could set that up and then write a menu item in the style of

if (exFAT)
                .name = "Unique file names",
                .priv = &unique_name,
                .max = 1,
                .help = "Create unique file names",
                .advanced = 1,

22
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 15, 2014, 11:12:40 AM »
I'm on a 5d mk3.

23
Feature Requests / Re: Naming conventions for RAW and MLV clips
« on: June 14, 2014, 11:37:27 PM »
OK I'm able to use longer file names, must be because I'm using exFAT on all my cards. I found that's a nicer way to set it as you don't get split files but you can't format cards in the camera... Still it could be implemented but with a warning if you're on FAT and not exFAT.

24
Feature Requests / Naming conventions for RAW and MLV clips
« on: June 14, 2014, 09:41:31 PM »
It took me a while to understand why MLV Mystic and RAW Magic was crashing for me. It turned out to be when I had been running 2 cameras on the same minute, the names of the files were the same.

I'd like to suggest a naming convention scheme similar to what RED has implemented on their cameras.

"The aim is to both uniquely and unambiguously reference each clip/take which has ever been shot every day by each camera, as well as aiding during the online editing and post-production phases to discern which reel, camera and shooting date combinations that clip "belongs" to."

http://en.wikipedia.org/wiki/REDCODE
(under "Naming convention")

For the time being I've just added seconds to my module, I'm not a strong enough programmer to implement a system close to what RED has.

Code: [Select]
snprintf(filename, sizeof(filename), "%s/M%02d-%02d%02d-%02d.RAW", get_dcim_dir(), now.tm_mday, now.tm_hour, COERCE(now.tm_min + number, 0, 99), COERCE(now.tm_sec + number, 0, 99));
I found some stuff online that I'd like to put in but I can't compile it, again because I'm a noob but let me know what changes I'd need to make to get this to run in raw_rec.c and I could possibly put it together myself.

Code: [Select]
string RandomString(int len)
{
   srand(time(0));
   string str = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
   int pos;
   while(str.size() != len) {
    pos = ((rand() % (str.size() - 1)));
    str.erase (pos, 1);
   }
   return str;
}

string random_str = RandomString(4);

25
Raw Video / Re: REC COMMAND via the HDMI trigger - Atomos
« on: June 14, 2014, 08:57:37 PM »
Thank you,

So I actually managed to get the camera to write both RAW and H264 to different cards. Unfortunately the camera freezes after about 12 seconds when using these settings and I don't understand why. It's not about the screen size that gets put through the raw module: I tried both 640x360 and 1920x1080 but no matter the setting the camera freezes.

What I've tried is:

Code: [Select]
    if (rec_key_pressed)
    {
        switch(raw_recording_state)
        {
            case RAW_IDLE:
            case RAW_RECORDING:
    raw_start_stop(0,0);
    return 1; //Lets the camera carry on with what it was doing.
What could be the problem, not enough computing power?

I used
Code: [Select]
( filename[0] = 'A'; ) to make sure the RAW always goes to the CF Card and I'm setting the H264 to go to the SD through the normal Canon menu.

Still looking for either the solution to write the H264 to the SD card and the RAW to the CF or to find the HDMI REC trigger so the Atomos can auto start recording (and forget about the H264).

Also added seconds to the file name for my own module, that gives a smaller chance of same file names when shooting 2 cameras. Would be better to have a hex file name structure as RED has. When using MLV Mystic and RAW Magic the programs crash if the file names are the same. I'll write a separate post about that.

Pages: [1] 2