ADTG and CMOS registers

Started by a1ex, June 25, 2013, 11:01:20 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Andy600

I've found an interesting one on 50D (I think) but it's difficult to explain properly  ???

ADTG3[1000]  0x6 ->0x1205 - you need to zoom then return to unzoomed state for it to take effect. I changed values with 256 (x <<8 )

The image is vertically stretched a bit but also has a realtime ghost image from a different area of sensor that changes with focusing (which is strange because I use manual lenses) plus it goes green when panning over lighter areas - It's recordable too. I can send devs a PM with a link to some video.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Audionut

These are all ADTG2 (5D3).

809f - Reduces WL, increases stdev, regains highlight detail, works both ways, Canon adjusted, appears to be blue/red channel

80a0 - same as above.  possibly in different color channels.  See screenshot 1 below (interesting noise pattern).

80a4   - increases stdev both ways

80cc   - lower values increase stdev, Canon adjusted    0x100 screenshot 2

80d8   - lower values increase stdev, increases stdev significantly at 0x1,0x2 and 0x3, canon adjusted

8108- lower values increase stdev, banding in highlights

813a   - default 0x110, below 0x100 reduces WL to 2070 and reduces stdev.

82f0   - default 0x401, slightly lower values produce black image,  0x3a9 (and other lower values) does something to the green channel in the shadows

fe - default 0x4, lower values reduce stdev, higher values increase stdev

Screenshot 1


Screenshot 2

waza57

Hi and thank you so much for all that work.

Dual iso video works on my 5d2 but .......only when i'm playing with ADTG_gui

Like this:

1. load atdg_gui module.
2. Play with cmos[0] with movie mode on.
3. found  at iso 100 dual iso video working for CMOS[0] 0x301  -> 0x305        ( addr= 0x404B490, value 0x301, nrzi=513(0x201).

Im not  a developper, Just a player and i don't know how to implement this in dual_iso.c .

I tried to do something like this but i just got an "ISOless LV err(2)":

is_5d2 = 1;
        FRAME_CMOS_ISO_START = 0x404b4590; // CMOS register 0000 - for LiveView, ISO 100 (check in movie mode, not photo!)
        FRAME_CMOS_ISO_COUNT =          5; // from ISO 100 to 25600
        FRAME_CMOS_ISO_SIZE  =         30; // distance between ISO 100 and ISO 200 addresses, in bytes
       
        PHOTO_CMOS_ISO_START = 0x404b3b5c; // CMOS register 0000 - for photo mode, ISO 100
        PHOTO_CMOS_ISO_COUNT =          5; // from ISO 100 to 1600
        PHOTO_CMOS_ISO_SIZE  =         14; // distance between ISO 100 and ISO 200 addresses, in bytes

        CMOS_ISO_BITS = 3;
        CMOS_FLAG_BITS = 2;
        CMOS_EXPECTED_FLAG = 3;


If someone has an idea ?  ;)

P.S. Sorry for my bad english

a1ex

You have to find a way to override that value, preferably without using code hooks. If you find a way to patch some RAM values that are not changed by Canon code, that method is easiest and should be pretty reliable (that's how it's implemented on the other cameras).

Unfortunately, the value at the address used in 5D2 is modified by Canon code (when you switch to another ISO, and maybe also continuously, don't remember). So, one has to find the address (or the logic) where this value comes from, and overwrite that one.

Using code hooks may work, but it's a little more error prone. This library should help a bit:
https://bitbucket.org/hudson/magic-lantern/pull-requests/687/patch-manager-wip/diff

However, I'm not sure it's worth the effort, because of the heavy aliasing in this mode.

waza57

I'm not sure to have the required level for all that.
I will try, however.
whatever happens, thank you very much.

reddeercity

QuoteDual iso video works on my 5d2 but .......only when i'm playing with ADTG_gui
@waza57 that sound great !
So you used latest Nightly Build & the atdg_gui module on the 5D2 ?
Did you have to compile the atdg_gui module for the 5D2 ?

Well anyways if there something I can do to help I would be glad do what I can.
As a 5D2  user I would like to see this come to full light. Or the very least I would like to test it out
to see if the video is  usable .
if you like to can PM me

QuoteHowever, I'm not sure it's worth the effort, because of the heavy aliasing in this mode
@a1ex , is that reason way to didn't implement dual iso video for the 5d2 .

mothaibaphoto

Quote from: waza57 on March 01, 2016, 12:38:11 PM
Dual iso video works on my 5d2 but .......only when i'm playing with ADTG_gui
Whats funny, dual iso video stops working for me when  i'm playing with ADTG_gui on 5D3 :)

waza57

@reddeercity
QuoteSo you used latest Nightly Build & the atdg_gui module on the 5D2 ?
No, but with several versions like this one for example:

Magic Lantern v2.3.NEXT.2016Feb29.5D2212
Mercurial changeset: 63b2f145cb3b+ (unified).

I think it' works for the most of  Nightly Build's .

QuoteDid you have to compile the atdg_gui module for the 5D2 ?
Yes i did. I don't know if there is a precompiled one.

QuoteWell anyways if there something I can do to help I would be glad do what I can.
As a 5D2  user I would like to see this come to full light. Or the very least I would like to test it out
to see if the video is  usable .
if you like to can PM me
OK, thanks . You can also pm me. My first problem is to understand the code of dual-iso.c.
I could post a video later if you're interested but it is wobbly since it is with adtg_gui.mo and I don't know really the values of effectives 2 iso.
actually I trying  the alex's idea with memory patches. It's very difficult for me.



reddeercity

@waza57 Sounds great sure , My coding skill are limited but I'm willing to learn what I don't understand  ;D
I'll have a look at the code in  dual iso.c first to get a understanding what going .
Going to need to do some reading  , I think  we should start a video dual iso thread for 5D2 and continue there.
So the whole ML community can contribute if there like .
Yea can you post some video samples , I'm mostly interested in the aliasing factor .

I will not have much time this week to work on this , (just finishing up a work project)
next week I'll be able to spend time on this .



nikfreak

[size=8pt]70D.112 & 100D.101[/size]

Levas

Just wondering how ADTG detects registers.
Once I enable ADTG module, I think it only shows registers it detects. This detecting is done by seeing the registers being changed by Canon firmware I guess ?
Could it be the case that there are registers available that don't show up in ADTG module, because these registers are never being changed by Canon firmware ?

a1ex

Quote from: Levas on September 19, 2018, 05:20:28 PM
Once I enable ADTG module, I think it only shows registers it detects. This detecting is done by seeing the registers being changed by Canon firmware I guess ?

That's exactly how it works - all of the ADTG register writes are generally*) done with the same routine (we call it adtg_write). So, we place a hooking function over that routine, that's going to see its arguments, i.e. a list of ADTG registers to be updated. Each camera may use its own set of registers, so they are not known in advance; they are discovered when Canon firmware changes them.

If you just enable adtg_gui in LiveView, it's going to see only the registers that are refreshed continuously, at every single frame.

Once you exit LiveView and get back, adtg_gui is going to see those registers that were changed by Canon firmware during the initialization phase, too. To update them, until recently you also had to get out of LiveView and back, as the override operates when Canon firmware writes to them. Recent adtg_gui has a trick that allows updating these registers on the fly, although I'm not 100% happy with it - sometimes it just locks up.

*) on some recent models, such as 100D, EOSM2 and most D6/7 models, there's also ADTGDMA, that's not handled by adtg_gui yet.


Quote from: Levas on September 19, 2018, 05:20:28 PM
Could it be the case that there are registers available that don't show up in ADTG module, because these registers are never being changed by Canon firmware ?

Quite possible, although I didn't try to find out. Brute forcing the entire register address space (16-bit) should work. A script would be required to try a couple of values for every register, and check the results against the reference image (before the change). Need to make sure any change made to an ADTG register can be undone, e.g. by getting out of LiveView and back. Worst case, that would require a reboot (so the script would have to be prepared for lockups by saving its state in a config file). Lua is not exactly ready for that (no image analysis functions).

Levas

Does firmware have to set all possible registers at startup ?
And is it possible to somehow log this, or is this impossible because ML is loaded at startup by the canon firmware so maybe registers are already set before ML is even loaded ?

a1ex

No, some devices are initialized on demand. Some cameras do some sort of bad pixel calibration at startup, but from what I could tell, that doesn't trigger any image capture; maybe it's just loading saved correction data into the image processor, or something like that. But image capture is powered on when entering LiveView or when taking a photo, and powered off when finished. Complete configuration happens after powering on, i.e. it's visible in adtg_gui.

However, some registers are configured with different values at different stages; for example, before capturing a photo, most cameras also capture a partial dark frame, apparently for figuring out the vertical stripe pattern. The 500D and 1100D don't do this, but most other cameras do. The calibration frame has different vertical size, so FPS timer B is set to different values. Currently, adtg_gui doesn't handle this very well, so it's hard to override values just at one stage of the image capture sequence; by default, it overrides a register in all places where it's modified by Canon code.

Look at this screenshot:

Quote from: a1ex on July 14, 2014, 11:32:29 PM


FPS register B was set a couple of times during the image capture process, to different values. By default, adtg_gui shows just the last value for each register. If you change the "unique key" option (caveat: you need to do that before enabling the main ADTG menu entry!), you can see, to some extent, the different values as long as they were changed from different parts of Canon code. You can't just see the entire sequence in the menu yet; that's a bit more difficult to solve, especially if you will want to override things.

You can log the complete communication between the ARM CPU and its peripherals - remember these thousands of registers?

You should find every single register read/write in those huge logs.

You can see everything the firmware does, before ML is loaded, in QEMU (-d io). It's not touching the image capture stuff.

Danne

Quote from: a1ex on September 19, 2018, 07:55:34 PM
before capturing a photo, most cameras also capture a partial dark frame, apparently for figuring out the vertical stripe pattern.
Interesting. How did you find out? Is this done before every single photo?

a1ex

Yes, before every single photo; look up "scsDummyReadoutDone".

700D:

cat "700D.115/cr2 capture 1_50.LOG" | grep 'SW2\|scs\|Readout\|C0F06' |grep -v 0x00000000

2.248.468    EventMgr:ff227544:8d:03: emDeliverMulticastEvent : SW2ON
2.248.618  ShootCaptu:ff14beec:93:03: scsReleaseOn
2.248.656  ShootCaptu:ff148058:93:03: scsReleaseStart
2.273.205  ShootCaptu:ff2c2d14:MMIO : [0xC0F06800] <- 0x00030010
2.273.207  ShootCaptu:ff2c2d14:MMIO : [0xC0F06804] <- 0x0DCC0538
2.273.208  ShootCaptu:ff2c2d14:MMIO : [0xC0F06808] <- 0xFFFFFFFF
2.273.210  ShootCaptu:ff2c2d14:MMIO : [0xC0F0680C] <- 0xFFFFFFFF
2.273.211  ShootCaptu:ff2c2d14:MMIO : [0xC0F06810] <- 0xFFFFFFFF
2.273.213  ShootCaptu:ff2c2d14:MMIO : [0xC0F06814] <- 0xFFFFFFFF
2.273.216  ShootCaptu:ff2c2d14:MMIO : [0xC0F06824] <- 0x0000056A
2.273.217  ShootCaptu:ff2c2d14:MMIO : [0xC0F06828] <- 0x0000056A
2.273.219  ShootCaptu:ff2c2d14:MMIO : [0xC0F0682C] <- 0x0000056A
2.273.220  ShootCaptu:ff2c2d14:MMIO : [0xC0F06830] <- 0x0000056A
2.273.226  ShootCaptu:ff2c2d14:MMIO : [0xC0F06008] <- 0x056B056B
2.273.228  ShootCaptu:ff2c2d14:MMIO : [0xC0F0600C] <- 0x056B056B
2.273.229  ShootCaptu:ff2c2d14:MMIO : [0xC0F06010] <- 0x0000056B
2.273.290  ShootCaptu:ff2c2d14:MMIO : [0xC0F060D0] <- 0x00000001
2.273.301  ShootCaptu:ff2c2d14:MMIO : [0xC0F06018] <- 0x00000020
2.273.302  ShootCaptu:ff2c2d14:MMIO : [0xC0F06020] <- 0x00000002
2.276.526  ShootCaptu:ff1488ac:93:03: scsReleaseData
2.282.642  ShootCaptu:ff148e94:93:03: NormalCapture(scsReleaseData)             <-- calibration frame starts
2.283.855  ShootCaptu:ff2c2d14:MMIO : [0xC0F06800] <- 0x00030010
2.283.857  ShootCaptu:ff2c2d14:MMIO : [0xC0F06804] <- 0x0DCC0538                <-- capture resolution: (0x538-0x10)*4 x (0xdcc-3) = 5280x3529
2.283.858  ShootCaptu:ff2c2d14:MMIO : [0xC0F06808] <- 0xFFFFFFFF
2.283.860  ShootCaptu:ff2c2d14:MMIO : [0xC0F0680C] <- 0xFFFFFFFF
2.283.861  ShootCaptu:ff2c2d14:MMIO : [0xC0F06810] <- 0xFFFFFFFF
2.283.863  ShootCaptu:ff2c2d14:MMIO : [0xC0F06814] <- 0xFFFFFFFF
2.283.866  ShootCaptu:ff2c2d14:MMIO : [0xC0F06824] <- 0x0000056A
2.283.867  ShootCaptu:ff2c2d14:MMIO : [0xC0F06828] <- 0x0000056A
2.283.869  ShootCaptu:ff2c2d14:MMIO : [0xC0F0682C] <- 0x0000056A
2.283.870  ShootCaptu:ff2c2d14:MMIO : [0xC0F06830] <- 0x0000056A
2.283.876  ShootCaptu:ff2c2d14:MMIO : [0xC0F06008] <- 0x056B056B
2.283.878  ShootCaptu:ff2c2d14:MMIO : [0xC0F0600C] <- 0x056B056B
2.283.879  ShootCaptu:ff2c2d14:MMIO : [0xC0F06010] <- 0x0000056B
2.283.940  ShootCaptu:ff2c2d14:MMIO : [0xC0F060D0] <- 0x00000001
2.283.951  ShootCaptu:ff2c2d14:MMIO : [0xC0F06018] <- 0x00000020
2.283.953  ShootCaptu:ff2c2d14:MMIO : [0xC0F06020] <- 0x00000002
2.284.192  ShootCaptu:ff2c2d14:MMIO : [0xC0F06014] <- 0x0000020F                <--- capturing just ~ 528 lines?!
2.284.193  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.284.949  ShootCaptu:ff2c2d14:MMIO : [0xC0F06014] <- 0x0000138B                <--- ???
2.284.951  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.290.801  ShootCaptu:ff14bcec:93:03: scsProperty ID=0x80030012(0x16)
2.307.318  **INT-6Ah*:ff148168:93:03: Dummy ReadoutDone(1085)
2.307.403  ShootCaptu:ff149798:93:03: scsPreCapReadyReadoutDone                 <-- calibration frame captured, took 22.9 ms = 528e3/(32e6/0x56c)
2.307.870  ShootCaptu:ff2c2d14:MMIO : [0xC0F06014] <- 0x000002C9                <--- ???
2.307.872  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.314.267  ShootCaptu:ff149d44:93:03: scsCapReady
2.314.289  ShootCaptu:ff149d9c:93:03: scsCapReady
2.331.825  ShootCaptu:ff2c2d14:MMIO : [0xC0F06004] <- 0x00000001
2.331.827  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.336.084  ShootCaptu:ff2c2d14:MMIO : [0xC0F06014] <- 0x00000DCB                <-- actual image capture starts here
2.336.085  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.345.476  ShootCaptu:ff14a0bc:93:03: scsCapEnd
2.345.614  ShootCaptu:ff2c2d14:MMIO : [0xC0F06000] <- 0x00000001
2.365.449    EventMgr:ff0d12b4:93:03: scsAFPINTParamCBR(JobID=1085)
2.365.961    EventMgr:ff0d1220:93:03: scsIMAGEParamCBR(JobID=1085)
2.366.998    EventMgr:ff0d17c8:93:03: scsAfterReleaseDataCBR(1085)
2.432.586    EventMgr:ff2276f0:8d:03: emDeliverMulticastEvent : SW2OFF
2.432.979  ShootCaptu:ff14ad74:93:03: scsReleaseEnd
2.433.014  ShootCaptu:ff14bf2c:93:03: scsReleaseOff
2.442.875  ShootCaptu:ff14a294:93:03: scsSAFAreaStart
2.478.005     CtrlSrv:ff39dc40:83:03: IDLEHandler PRESS_SW2_BUTTON              <-- what's this doing here?! SW2 was pressed a long time ago
2.498.579  **INT-6Ah*:ff14a038:93:03: ReadoutDone(1085)
2.498.792  ShootCaptu:ff14a328:93:03: scsFinalReadoutDone
2.499.022  ShootCaptu:ff14a34c:93:03: End Mem1 Crosstalk scsFinalReadoutDone    <-- Crosstalk? AF pixels related?
2.503.772  ShootCaptu:ff14a810:93:03: scsFinalReadoutDone (2121)
2.505.425  ShootCaptu:ff14bcec:93:03: scsProperty ID=0x80030012(0x14)
2.554.713     CtrlSrv:ff39dc40:83:03: IDLEHandler UNPRESS_SW2_BUTTON
2.555.880    Fstorage:ff1d07e8:9e:03: fssSW2On
2.555.912    Fstorage:ff1d0918:9e:03: fssSW2Off (ID = 1085)
2.906.650  ShootCaptu:ff14bcec:93:03: scsProperty ID=0x80030012(0x10)
2.906.702  ShootCaptu:ff14bc8c:93:03: scsDevDone[1]
3.604.399  ShootCaptu:ff14bcec:93:03: scsProperty ID=0x80030012(0x0)
3.604.451  ShootCaptu:ff14bc8c:93:03: scsDevDone[0]

Postprocessing happens in other tasks: ShootPreDevelop, ShootSsDevelop, YMMV on other models.

Levas

Interesting stuff, didn't know that that much was going on, with every single photo capture.

Quote from: a1ex on September 19, 2018, 07:55:34 PM
You can see everything the firmware does, before ML is loaded, in QEMU (-d io). It's not touching the image capture stuff.

But this, this probably says it all for me, all intersting stuff, movie/photo modes, are seen by adtg module.

reddeercity

Trying to find the "PowerSaveTiming" Reg's  for d4 5D2 & 50D , I did find something close in the 5d2 rom disassembly

ffccf734: STRING:  'EnablePowerSave'
ffccf744: STRING:  'DisablePowerSave'

below is what was in the dm-0003_Photo_Liveview_reviewing_cr2.log
0BE05>    Startup:ff871ad4:00:01: [PM] DisablePowerSave (Counter = 2)
0BE43>    Startup:ff871b44:00:01: [PM] EnablePowerSave (Counter = 1)
0BE82> **INT-50h*:ff871ad4:00:01: [PM] DisablePowerSave (Counter = 2)
0BEBA> **INT-50h*:ff871b44:00:01: [PM] EnablePowerSave (Counter = 1)
0C03C> **INT-50h*:ff871ad4:00:01: [PM] DisablePowerSave (Counter = 2)
0C094> **INT-50h*:ff871b44:00:01: [PM] EnablePowerSave (Counter = 1)


So is "EnablePowerSave" & "DisablePowerSave" the same as "PowerSaveTiming On" & "PowerSaveTiming Off" on d5 5d3 ?

Whr

https://www.magiclantern.fm/forum/index.php?topic=25839
I'm having some problems trying to compile the firmware for Canon 500D. Maybe there's something wrong with the code. I don't know how to solve it.

500D 1.1.1 & X-T3