Messages

12, 10, 8 bit Lossless!!!!!!!!!! Am I reading this correctly? Oh man. This is unreal!

Testing April 13 build. Much more stable for sure! Compression seems to be tricky still. I'm not the biggest fan of how slow settings (shutter ISO ect) appear to change when in Framing LV but I know it serves a purpose to get proper preview with low processing power.
If we can some how cap the data rate that would be insane. But then I guess it would be lossless at that point.

Higher detail low contrast scene, F1.6 1/125 (1/98) ISO 800
1920 2.35:1 14 Bit lossless 1920 48p preview auto - fairly long rec
16:9 Did not make estimated rec time

1920 2.35:1 14 Bit lossless 1920 60p preview auto - Did not make estimated rec time

3072 2.35:1 14 Bit lossless 3k 1:1 23.976 preview auto seamed good.
16:9 Did not make estimated rec time

On same scene I changed the shutter speed F1.6 1/50 (1/98) ISO 800 then none of the above modes made there estimated rec time.
It seems that if more detail is brought out of low exposure zone, less info gets tossed which means higher data rate.

No crashes/bad frame warnings until I lowered the shutter down to 1/30 in 3072 2.35:1 14 Bit lossless 3k 1:1 23.976 preview auto. Then it crashed/bad frame warning ML assert

ML ASSERT:
0
at mlv_lite.c:2120 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2120 (compress_task), task compress_task
lv:1 mode:3

Magic Lantern version : crop_rec_4k.2017Apr13.5D3113
Mercurial changeset   : cf07f797b9c3 (crop_rec_4k)
Built on 2017-04-13 10:34:53 UTC by jenkins@nightly.
Free Memory  : 163K + 3115K

Okay so I went in for a second test. Over all here is what I am finding

3k 2.35:1 14 Bit lossless Preview auto is very stable

1920x1080 48p, 14 Bit lossless, Preview auto, out of focus scene - not stable lots of crashes even when not Rec out of focus scene

1920 2.35:1 48p, 14 bit lossless, preview auto, out of focus scene - not stable lots of crashes even when not Rec

1920 2.35:1 60p, 14 bit lossless, preview auto - seemed more stable did not crash. Pressed half shutter and it crashed

1920 2.35:1 60p, 14 bit lossless, preview real time - seamed more stable no crash

1920 2.35:1 48p, 14 bit lossless, preview real time - seemed more stable

1920 2.35:1 48p, 14 bit lossless, preview - framing crashed

There were more rec attempts in there but that is all I can remember for now. Unfortunately Ill have to stop testing for a bit. Here are my asserts

ML ASSERT:
0
at mlv_lite.c:2111 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2111 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2118 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2118 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2118 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2118 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2118 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2111 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2111 (compress_task), task compress_task
lv:1 mode:3

ML ASSERT:
0
at mlv_lite.c:2111 (compress_task), task compress_task
lv:1 mode:3

Magic Lantern version : crop_rec_4k.2017Apr12.5D3113
Mercurial changeset   : dcdf7432df74 (crop_rec_4k) tip
Built on 2017-04-12 20:31:48 UTC by jenkins@nightly.
Free Memory  : 163K + 3116K

Wait..... what did I do wrong here. I couldn't even get one solid rec out of the April 12 build so far. I had to pull the battery every time.
@a1ex Im sending you a message to a zip of my card its peppered with ASSERT messages.

Going to update to new build and found this on card from April 10 Build
ML ASSERT:
RAW_IS_IDLE
at mlv_lite.c:584 (measure_compression_ratio), task shoot_task
lv:1 mode:3


Magic Lantern version : crop_rec_4k.2017Apr10.5D3113
Mercurial changeset   : 11f405b62b31 (crop_rec_4k) tip
Built on 2017-04-10 19:48:55 UTC by jenkins@nightly.
Free Memory  : 163K + 3118K

Not sure if this needs to be reported.
Testing April 12 build now

Some of the cases I've unbricked, with bad PROP_PIC_QUALITY values, were cameras that did not have ML before the crash. One of those cases was linked in the FAQ (but looks like the original discussion is no longer available...)

"were cameras that did not have ML before the crash" Does this mean the ML card wasn't in the camera at the time of the crash?

WOW!!!!! @a1ex this is amazing! Cant wait to test!

Nice, Premiere or DaVinci Resolve? The old DNG-files opeened right up in Premiere but these compressed ones does not.

DaVinci opened them just fine. I don't know premiere.
Its and extra step but you can always export from resolve. Resolve + DNG = incredible color options!

Ohhhhhhhhhh! I think I get it now. Sorry I had to read through it again. Hmmmm.
So there is not much that can be done about certain properties being saved unless you can mod the timer in which the MPU/CPU saves those properties after a change and mod the switch? ... Right?
If I still don't understand I am sorry for wasting forum space. This is why I am a user not a programmer.

Would it be safer if ML never touched those properties (e.g. 0x80000005 PROP_SHUTTER, 0x80000039 PROP_VIDEO_MODE, 0x8000002f PROP_PIC_QUALITY)?
Or is that not possible with some features?

Also I can confirm:
- used a pin to hold the battery cover switch; changed shutter speed, took battery out (quickly) => change not saved
- used a pin to hold the battery cover switch; changed shutter speed, waited a few seconds, took battery out => change saved

Just tried this just now. So the save timer and switch are working against you.

Ohhhhhhhhhhhh very interesting! So ML doesn't use the MPU (always saving settings)
Hmmm so then the issue is the little switch on the door. Does that have a timer? Or does it save as soon as it is activated?

Hmmm So is there a timer? Like if we open batt door and immediately pull batt it won't save? Or is there still a chance there is saving happening with a lightning fast pull?
Or is canon saving setting to ROM ever 2 seconds regardless of a batt pull.

GO @a1ex!!!!!!!

What kind of work flow are you guys using for the 1920x960 3x3 binning 14bit raw mode?

In camera? Or post processing?
For post I used the RAWFlow app and just replaced the MLV_DUMP with the newest version and it processed the 14Bit Lossless just as expected. Drag n Drop.
RAWFlow - http://www.magiclantern.fm/forum/index.php?topic=13338.0
MLV_DUMP Update - https://builds.magiclantern.fm/experiments.html

Yes, taking the battery out after a crash is what I always do.

Unfortunately, it doesn't appear to prevent Canon code from saving corrupted settings into the ROM. Still looking into it.

edit: opening the battery door seems to be interpreted as some sort of emergency shutdown, but a clean one - settings are saved into ROM, but ML shutdown hooks (e.g. saving ML config files) are not executed. But, if you somehow hold the battery door switch pressed, and just remove the battery, the ROM is not updated.

@a1ex Hmmmmm So if I mod the switch with say.... tape, I can pull battery with out afflicted ROM being saved?
Should I do this as a extra precaution when heavy testing?
Would this have adverse affects on Canon code being that its an "unsafe" battery pull at that point? 
So many questions sorry.
I suppose there is always a chance I might not even know that the ROM is affected and I could clean shutdown anyway. 

So I can use a little education here. Sorry Im behind. If I get the:
ML ASSERT:
RAW_IS_IDLE
at mlv_lite.c:584 (measure_compression_ratio), task shoot_task
lv:1 mode:3
where the text appears on the screen, is this a crash? I have been assuming it is and pulling the battery. Should I be doing this?

@beauchampy I got 1920 x 1080 48p 3x3 without tearing but rec time was inconsistent.
I also got 1920 2.35:1 @ 48p without tearing. That was on the very first build

However, on the 4-10-2017 build I took about 5 or 6 clips of 3072 x 1728 @ 23.976 last night and notice that 1 frame out of all the clips had a small horizontal row of pixels that seemed like it was offset from the rest. Ill upload if I get a chance.

I was using RAWFlow with an updated MLV_DUMP to convert 14 Bit lossless to DNGS.

Using April 10th build. Testing 3072 x 1728
Got
ML ASSERT:
RAW_IS_IDLE
at mlv_lite.c:584 (measure_compression_ratio), task shoot_task
lv:1 mode:3


Magic Lantern version : crop_rec_4k.2017Apr10.5D3113
Mercurial changeset   : 11f405b62b31 (crop_rec_4k) tip
Built on 2017-04-10 19:48:55 UTC by jenkins@nightly.
Free Memory  : 163K + 3118K

Pulled Battery then restarted and reloaded mods.
The only things that I don't like are the current gray scale that it jumps to when it records (I know its purpose is to reserve resources)
The inconsistency of clip length due to changing compression.
And I find I cant get over 4 seconds on average with a 128 GB Lexar 1066x 160MB/s card.
I know this is very experimental I am just reporting my findings so far.

Awesome!!!!! @a1ex!!!!!

@quentin  Do you remember what the record symbol looked like for any of the clips? Was it the Canon rec icon or did the cam beep then record like when it does for RAW. Also did you try processing the MLVs ? And did you test your Rom with the Python script?
You could also try recording again. Making sure that the mods are disabled for sure.
Remember that this build is bleeding edge.

I wanted to record h.264, my daughter with her new bicycle. No RAW, no anything.
Crop Mode and Raw Recording werent loaded.
The camera was recovered after a bad crash and removed the battery.
I never reset to ML defaults, or reload the modules as the usual procedure.

I shot 4 takes.
The two were MLVs.
I havent touched anything.
RAW recording enabled itself somehow

Was ML still in the camera?
After you pull the battery​, on the next power up the modules won't load. If you power down then power back up again, the modules will load again with your settings and all. Could this be what happened?

@A1ex Ran the Python test and my camera was not affected!!!!!

@A1ex is it only 5Diiis that used April 4 build or could it be in the April 3 build too?

@A1ex I got the nasty error explosion today using the April 6 build.
I think it was probably because I was using an odd resolution
3008x1280 or something like that. Pulled battery everything seem fine with the camera.
Tried again with 3072x what ever 2.35:1 is and it seemed to work ok.
Would you like me to report the bug.
Here is a link to what was on my card. Error codes and all.
https://www.dropbox.com/sh/8lmopv8z7p2i91f/AAA4saYTmLE7rFQ3t7nSUBCaa?dl=0

@nikki I added more info to description below video. Let me know if there's more I can add.

This looks incredible. I can't wait to try!