Canon 70D

[hacki]

Well... I think i'm a bit confused about the LUA implementation of magic lantern (i'm used to CHDK).

I read somewhere that ML executes all scripts it can find once on boot and therefore you shouldn't put any code that does something in a script "just like that", without calling it from someplace else.

But apparently thats not entirely true? A plain and simple

Code Select Expand


for i=1,50 do
   camera.shoot()
end


without any fluff works precisely like i'd expect it to.

So i'll stick with that.

I read the LUA API page on the docs. Its not clear to me what makes a script "simple" and what makes a script "complex"?

edit: Found it: http://davidmilligan.github.io/ml-lua/

Thats on the very top of some google search results for ml lua stuff.

If thats outdated, maybe it should be removed from github..

[andy kh]

[a1ex]

I read somewhere that ML executes all scripts it can find once on boot and therefore you shouldn't put any code that does something in a script "just like that", without calling it from someplace else.

But apparently thats not entirely true?

That was true for the early Lua implementation (still in main builds for most cameras except 70D and a few others). See also the call for testers - there are some 70D issues that are hard to diagnose without a camera in one's hands, so help is welcome - not just by running the unmodified scripts, but also by troubleshooting them).

I read the LUA API page on the docs. Its not clear to me what makes a script "simple" and what makes a script "complex"?

Main page -> Docs -> Lua API -> first page, first paragraph
Download page -> Lua API -> first page, first paragraph

(i'm used to CHDK)

I'm not; maybe you can provide some more details on that.

Hey 70D users.

There's a test that needs some 70D input [...]

Would appreciate if other 70D owners would run the test linked by dfort, and also try the lossless compression experiments and report the results in a way that's helpful for us (sorry andy kh).

[dfort]

70D users should be aware that your camera is almost working on the crop_rec_4k branch which means reduced bit depth and lossless compression which allows for greater resolution when recording raw video.

There are several pieces to the crop_rec_4k puzzle. One that we haven't even started on is the crop_rec module. I recently got it working on the EOSM2 so this is still fresh in my mind. This post explains what we need to find:

https://www.magiclantern.fm/forum/index.php?topic=15895.msg197884#msg197884

You will need the adtg_gui module. The current one on the downloads page doesn't support the 70D so I made a special build of the iso-research branch. You can find it on my downloads page.

• Activate the adtg_gui module (leave all other modules off)
• Set the Canon movie menu to 1280x720/60
• Go int the Debug menu and in the ADTG Registers look for ADTG2[800c] - if you don't see it record a short H.264 clip and look again.
• Override the ADTG2[800c] register from 0x4 to 0x2 -- the left/right buttons on most cameras will do this, search the forum if you need more information on how to work with the adtg_gui module.
• In the Debug menu check the memory patches and do a screen shot of the two memory patches, adtg_log and cmos_log.

[David_Hugh]

Like This -->







?

[dfort]

Excellent! Let's give this a try:

Code Select Expand

    else if (is_camera("70D", "1.1.2"))
    {
        CMOS_WRITE = 0x26B54;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x2684C;
        MEM_ADTG_WRITE = 0xE92D47F0;


Put up a test build on my downloads page. The way to test this is to first turn on only the crop_rec module. Put your camera in 1280x720/50 or 60 (depending if you're set up for PAL or NTSC) and try recording some H.264 video. The LiveView will probably look stretched vertically.

We know that mlv_lite isn't working yet because we need to figure out the lossless recording but maybe mlv_rec will work? You should be able to record video using 3x3 sampling at 60fps. Well, the card will limit how large of an image you can continuously record at that speed but it does give you another option to play with.

[David_Hugh]

No luck here either... I was able to record a h.264 file but from the looks of it its not what we are trying to achieve .
https://we.tl/lwKu0odHxN

[David_Hugh]

Is there a chance I somwhow messed up the atdg_gui test in the first place or do the values seem ok?

[dfort]

What the?



It looks like you did everything right--maybe I messed up? You didn't happen to turn on any other module like say dual_iso, did you?

Are you able to record regular mv720 H.264 video with this test build?

[EDIT] What I meant to say was if you turn off the crop_rec module can you record clean 720p H.264 video?

The vertical stretching in your image looks about right. For H.264 the crop_rec module acts as sort of an anamorphic squeeze that needs to be stretched out in post.

[David_Hugh]

Hey! I was able to record "regular" h.264 and the live view changed accordingly when I switched to the crop_rec mode, it looked exactly like the file I uploaded.

[a1ex]

The CMOS registers are likely different; one can fiddle with the values in adtg_gui and document what they do, and what their values are in different video modes. Some will change with ISO - try all full-stop values and write down which registers change. Others will change with column binning factor - try in 1:1 crop modes and compare to 1080p/720p. Simply writing the values to a log file (Advanced menu) in each video mode would be very helpful.

A list of the video modes can be found here:

70D.111A and 70D.111B can contribute following this guide:

http://www.magiclantern.fm/forum/index.php?topic=12375.0

and post in that thread (not in this thread) the vram dumps for 70D.111A and 70D.111B as instructed per above link.

(yes, that task from 2015 is still valid; nobody did it, to my knowledge)

[David_Hugh]

I did the test linked in the post (posted the files in the image dumping thread you linked). There's mostly none RAW video modes though. For further testing, should I repeat the ATG_GUI test (find register 800c and change it to 2) and then just make screenshots of different modes (and perhaps also ISOs as you suggested?)

[a1ex]

With adtg_gui, the interesting parts are:
- log default values in each video mode (without changing anything): Advanced -> Log Registers Now.
- change ADTG2[800c] in 720p50 (caveat: might lock up; try lowering the frame rate if it does)
- document CMOS registers for all ISOs (choose one video mode, such as 1080p24; optional 720p50 and some 1:1 crop)
- optionally try other ADTG registers (there are a lot of them; maybe start with something that changes when switching video modes, or the ones already documented for other models)

[David_Hugh]

Updated the Vram post with the 3xZoom modes.

Just to get this right the first time: 1:1 crop would be anything with the crop_rec activated right? or the 3xZoom from the menu as well?
Then I save a Log-registers file for every ISO in every one of those 3 modes, correct?

[a1ex]

1:1 crop modes are the x5 zoom (used for magnification), the 3x zoom (600D, 70D) the 640x480 crop (550D) and crop_rec 1:1 presets (5D3 only for now). So far, they appear to be quite similar regarding ISO, therefore covering just one of them should be quite good. Covering all others is unlikely to give different results.

Same for 1080p 24/25/30 (don't expect any differences regarding ISO). Same for 720p 50/60.

However, there may be differences between 1080p 24/25/30 on the ADTG registers.

[David_Hugh]

As always, I hope I did this the right way!
I saved the log file just like in the normal movie modes for every ISO in the 3 modes you suggested. However, all in h.264, a raw module was never loaded. I hope this was right.
https://we.tl/2lQ7AjIEDH

[a1ex]

Looks good at first sight, thanks.

CMOS[0]:
- ISO 100 and derived: 0x03 = 0b00000011
- ISO 200 and derived: 0x27 = 0b00100111
- ISO 400 and derived: 0x4B = 0b01001011
- ISO 800 and derived: 0x6F = 0b01101111
- ISO 1600 and derived: 0x93 = 0b10010011
- ISO 3200 and derived: 0xDB = 0b11011011

What happens if you set CMOS[0] to 0x83 = 0b10000011? (DNG silent pictures, please)

If that works, one may try using FRAME_CMOS_ISO_START = 0x404e749a in dual_iso.c; the other values from nikfreak are correct. His comments also mention CMOS[3], but that one is 0xC00 at all ISOs.

[David_Hugh]

live view behaves very weirdly when I do this. It gets all pink and in video mode flickery. Also, in this build (from the iso_research branch that dfort posted earlier in this thread) lossless dng is not available. thats why there's only normal silent DNGs. 

All I did was set CMOS

• from 93 to 83.
  https://we.tl/cii8hmbrK5

[a1ex]

The 5x and FRSP images look like valid Dual ISO files; you may try converting them.

The 1080p sample is very interesting: one line brighter (at higher ISO) and one line darker (at lower ISO). That's the first camera doing this! (it has no practical use, it's covered in dual_iso.pdf, but it's interesting for understanding how things work)

Try playing with the higher bits, e.g. 0x183, 0x283, 0x483, 0x883 (or, if you have the patience, try all the 16 possible values, from 083 to F83).

The 720p one is pure black; no idea how to fix, unfortunately.

[David_Hugh]

Is there any indication when or if I hit the nail on the head? Should the DNGs with the right combination open just like normal in Lightroom, or another processing app? Its just 64 Dngs, should be managable

[a1ex]

Yes, the pattern should be 2 lines bright and 2 lines dark (visible with Magic Zoom) and the image should look clean after conversion with cr2hdr (just like 5x and FRSP samples).

[David_Hugh]

91 and 92 seem to be the only other values where live view isnt broken, if that is any indicator. Im uploading all the dngs so you can have a look. Also, I ONLY changed the cmos 0 value, and left the 800c alone, thats what I was supposed to be doing and not changing them both, correct?

[dfort]

Nice testing @David_Hugh - do you have a development platform set up yet? It is easy to do and would really help.

Processed through cr2hdr:

FRSP


5x zoom


Wonder if that weirdness that's happening with the crop_rec module is related to the issues you're seeing with the 3x3 sampling modes, mv1080 and mv720. Kind of trippy depending on what app you use to open it, the is the Apple quick viewer.

[a1ex]

I ONLY changed the cmos 0 value, and left the 800c alone, thats what I was supposed to be doing and not changing them both, correct?

Correct, the 800c and the CMOS[0] are two different (unrelated) experiments. First is for 3x3 binning in 720p, second is for dual ISO.

The suggestion about higher bits comes from a quirk in 700D, EOSM and others, where these may result in 4 bright lines followed by 4 dark lines and so on. That weirdness mentioned by dfort looks fairly similar to that.

[David_Hugh]

Right, here are the other values then. It's always 720/1080/5x/FRSP

https://we.tl/fU1yNdv7Bz

dfort, I'm sure you are right about the testing environment, however, I am so far from working with code I dont even know how to use the command line (heck, I dont even know if that is easy or harder than setting up a testing environment  . )
Thats why for now I thought I'm more of a help taking relatively simple orders and trying to execute them correctly haha. But I will look into it.