Canon 70D

[dfort]

Well if you can copy and paste you can set up a development environment--don't fear the command line!

Ok--lots of files. A cr2hdr trick I learned a while back is that since it saves files with an uppercase ".DNG" extension, if you rename everything in lowercase, only the files cr2hdr could processes will be in uppercase.

Code Select Expand

13130000.dng
13130001.dng
13130002.dng
13130003.dng
13130004.dng
13130005.dng
13130006.DNG
13130007.DNG
13130008.dng
13130009.dng
13130010.DNG
13130011.DNG
13130012.dng
13130013.dng
13130014.DNG
13130015.DNG
13130016.dng
13130017.dng
13130018.dng
13130019.dng
13130020.dng
13130021.dng
13130022.DNG
13130023.DNG
13130024.dng
13130025.dng
13130026.DNG
13130027.DNG
13130028.dng
13130029.dng
13130030.dng
13130031.DNG
13130032.DNG
13130033.dng
13130034.dng
13130035.dng
13130036.dng
13130037.dng
13130038.dng
13130039.DNG
13130040.DNG
13130041.dng
13130042.dng
13130043.DNG
13130044.DNG
13130045.dng
13130046.dng
13130047.DNG
13130048.DNG
13130049.dng
13130050.dng
13130051.dng
13130052.dng
13130053.dng
13130054.dng
13130055.dng
13130056.dng
13130057.dng
13130058.dng
13130059.dng
13130060.dng


[a1ex]

Something I don't get: 083 worked before, but the first x5 picture in the set (assumed to be with 083) is black. Actually, all the 8.6MB pictures in groups #0, #4, #8 and #12 are black. Furthermore, pictures in the group #13 and #14 are not dual iso, and some of the pictures from the set have different ISO ratios.

#0 (13130002) => black
#1 (13130006) => 3.0EV, noise levels 5.99 14.93 14.86 5.82
#2 (13130010) => 3.0EV, noise levels 6.08 14.70 15.23 5.78
#3 (13130014) => 3.0EV, noise levels 6.21 14.74 15.15 5.83
#4 (13130018) => black
#5 (13130022) => 2.0EV, noise levels 7.10 14.95 15.26 6.94 => lower ISO increased from previous set
#6 (13130026) => 2.0EV, noise levels 7.07 14.96 14.95 6.96
#7 (13130031) => 2.0EV, noise levels 7.04 14.88 14.95 6.94
#8 (13130035) => black
#9 (13130039) => 0.99EV, noise levels 9.53 14.45 15.12 9.49 => lower ISO increased even more
#10 (13130043) => 1.0EV, noise levels 9.70 14.51 14.97 9.55
#11 (13130047) => 1.0EV, noise levels 9.67 14.76 15.31 9.49
#12 (13130051) => black
#13 (13130055) => 0.0EV, noise levels 9.82 14.77 15.20 9.57 (octave; image looks normal, cr2hdr refuses it)
#14 (13130059) => 0.0EV, noise levels 14.95 14.6 15.22 15.10 (octave; image looks like before, maybe with more hot pixels)
#15 (missing) => 0.0EV (predicted)

Previous sample:
13130002 => predicted 100/1600, got 4EV OK, noise levels 5.62 14.89 15.23 5.43

Image must be black if the two least significant bits are 0, unaffected otherwise.

Were the values in this sequence 0x083, 0x183 ... 0xE83, and was 0xF83 the missing one? If so, I'm unable to explain the results.
Were they 0x080, 0x081 ... 0x08E, and was 0x08F the missing one? If so, I can only explain the black frames and some of the ISO variations.

0x80      = 0b10000000 (predicted: black OK)
0x81/2/3  = 0b10000001/10/11 (predicted: 100/1600; got 3EV, expected 4)
0x84      = 0b10000100 (predicted: black OK)
0x85/6/7  = 0b10000101/10/11 (predicted: 200/1600; got 2EV, expected 3)
0x88      = 0b10001000 (predicted: black OK)
0x89/A/B  = 0b10001001/10/11 (predicted: 400/1600; got 1EV, expected 2)
0x8C      = 0b10001100 (predicted: black OK)
0x8D/E/F? = 0b10001101/10/11 (predicted: 400/1600; got 0EV, expected 1)

Assuming 0x60-0x6F to match the last two images, the predictions would be: 100/800 (3EV), 200/800 (2EV), 400/800 (1EV) and 800/800 (0EV). That seems to match, but why would you have chosen these values?

=> detective work failed; no idea what values you have set for this sequence. The sequence I've expected is 0x083, 0x183 ... 0xF83.

The FRSP images follow the same pattern (no surprises here).

[David_Hugh]

Ok, I see, too little input from my side. What I did was change the CMOS 0 value from 83 (which I didnt repeat because it was the first set of 4 I uploaded, hence the confusion probably...) to every other step in between 83 and 93.

However, the next value I can achieve by just right clicking the arrow buttons is 84. So the values were as follows:

x84
x85
x86
x87
x88
x89
x8a
x8b
x8c
x8d
x8e
x8f
x90
x91
x92


15 values times 4 DNGs equals the 60 Dngs i submitted. Feel free to now tell me I totally misunderstood the task  haha

[David_Hugh]

Ark! Found out myself. Read your previous post carefully and I somehow misread what I should be testing. I thought it was between 83 and 93 but you want me to test all combinations that end with 83, right? I quickly clicked through them and live view is broken in all of them. Is that a bad sign or something we are not concerned with yet? I will redo the test if broken liveview is a non-issue atm!

[a1ex]

At least 083 should be fine (since you have already posted valid Dual ISO samples from it).

[David_Hugh]

As reported, liveview also flickers weirdly pink in x83 setting (720&1080). (does that not constitute "broken"?) Turns to black&white in 5xzoom and stays pink (no flicker) in photo mode.

[a1ex]

Right, as long as the image moves as you move the camera, it's not broken (flicker is not a problem right now - that's just a resized version of an image with dark and bright lines).

You can see it better with Magic Zoom. The pattern might be stationary or "crawling" - on 5D3, this changes with FPS settings. I don't expect CMOS[0] to change this behavior, but if it does, please write it down.

[David_Hugh]

ok, then it seems none of the settings with 83 break live view and I redo the test!

[David_Hugh]

Here we go again. Tested the registers x83-x983 that ended on 83 . This is all I had time for today, the remaining ones will come tomorrow. Interesting to note: I installed cr2hdr for lightroom plugin, in all of the registers but the last one (so x983) only the 5xZoom and the FRSP were valid Dual Iso pics (Will try to confirm this tomorrow). In x983, only the 720 does NOT reigster as dual iso. However, they seem a lot more corrupted than lower registers. Full uploaded in case I'm missing something:

https://we.tl/kvdiIomvQJ

[a1ex]

It gets close, but the image after conversion is not good (at least here).

Can you also log the register values in photo mode, outside LiveView, at each ISO?

[David_Hugh]

Here are the register logs in Photo mode, outside live view. Just a minor note in case this is important. Right after startup, there are no registers visible. Since it says "log visible registers" in the menu, I switched to video mode, then back to photo mode before I did the first log, in order to make them visible. I'm guessing thats not relevant, wanted to mention it anyway!

https://we.tl/5KOkgmenc2

[a1ex]

It is relevant - it just adds noise to the dataset. Actually, the entire log contains only registers from LiveView.

No registers visible after enabling ADTG Registers, followed by taking a picture?

edit: yeah, forgot to mention - the registers are only updated when some Canon code changes them. In LiveView, that happens when entering LV, when switching video modes, and - for some registers - when changing settings such as ISO or shutter speed. In photo mode, the registers are only touched by Canon code when taking a picture.

So, you have to:
0) enable ADTG Registers
1) set ISO from Canon menu
2) take a picture
3) log register values (for that ISO)
4) repeat from step 1 for the next ISO

[David_Hugh]

Ok! So much to learn  !

https://we.tl/ls4TML6XNN

Better?

[a1ex]

Better, but for some reason, none of the registers changed with ISO. Did you take a picture before each log? The registers are *only* updated when Canon code changes them (when you actually take the picture, not when you change the setting from menu).

The module is not smart enough to detect whether you took a new picture or not.

[David_Hugh]

Ok! so a picture before every log. got it^^.

[David_Hugh]

In the meantime: Here's the completed test from yesterday. BUT. Something weird happened. I took the remaining test at ISO 400 instead of 800 because I wanted to keep the exposure similar, although I also included the x83 setting as a reference anyway.

This changed the register from x6f ----> to x4b ----> !

I also wanted to include x983 because of yesterday's observations. Here's where the weird bit starts. I wasnt able to take a FRSP at x983.

RAW error.

I wasnt able to save FRSPs up until setting xe83, which let me save one again, xf83 too.

So I thought, well, then repeat the FRSPs at ISO 800. Said and done, Register was at x6f ----> again. But I STILL couldnt save a FRSP. I swear to god I saved one with these settings yesterday and I dindt change anything in the process??

https://we.tl/MJvNGN744B

[David_Hugh]

Oh yeah, the DNG sequence is:

x83
x983
xa83
..... and so on

[David_Hugh]

Aaaand here's the log again... gg.

https://we.tl/8JktLBi1AD

[David_Hugh]

In the higher values The 1080 mode seems to at least be registered as a Dual Iso, but they are just as corrupted looking as the one I posted yesterday. Are there other values I should/could try?

[karakorum]

Hallo, In my new PC i have downloaded tools to convert MLV 2 DNG  , but they dont install. As i double click them, they just pop out , appear for 1/2 second and leave. Need help. Any suggestions Please.... !!!

[ShootMeAlready]

Wanted to know what folks on Windows 10 are having success with dual ISO for 70D.
I tried one recently and it left me with pink hues and lots of lines across.  I tried to proces the Cr2 file.

[David_Hugh]

Hey! I just wanted to try and revive the interest into getting the 70D closer to the crop_rec4k branch.
First of all I wanted to konw if something useful became of the ISO logs I posted a while ago.
Secondly, with regard to the dual_iso experiment I noticed something. In your analysis you said ISO for 3200 and derived is 0xDB, but I just looked at the values and 3200 is 0xb7 for me. Its probably nothing but I thought Id mention it anyway.
Also, are there more line skipping experiments that I can do to try and get the crop_rec modules working?

[a1ex]

IIRC we've got valid Dual ISO images in x5 zoom mode without any trickery, so that one is worth including in the builds.

From the last dataset, none of the 1080p samples were impressive; they were just interesting because they alternate one bright and one dark line, except for 13130038.DNG, which doesn't look very good after conversion. 13130039.DNG and 13130040.DNG are alternating 4 bright and 4 dark lines (a quirk also present on 650D, 700D and 100D in default configuration).

BTW, if anyone wants any of the above files, I can re-host them.

There is an experiment that might increase LiveView resolution, but it's considerably more difficult, as it's no longer a fixed recipe; besides, the pre-built adtg_gui from dfort requires two more stubs (just uncomment and recompile).

[dfort]

...the pre-built adtg_gui from dfort requires two more stubs (just uncomment and recompile).

...define ENGIO_WRITE_FUNC and ENG_DRV_OUT_FUNC in adtg_gui.c...

This is what I've got in adtg_gui for the 70D:

Code Select Expand

    else if (is_camera("70D", "1.1.2"))
    {
        ADTG_WRITE_FUNC = 0x2684c; //"[REG] @@@@@@@@@@@@ Start ADTG[CS:%lx]"
        CMOS_WRITE_FUNC = 0x26B54; //"[REG] ############ Start CMOS"
        ENGIO_WRITE_FUNC = 0xFF2BC6C4;  // from stubs
        ENG_DRV_OUT_FUNC = 0xFF2BC3AC;
    }


[a1ex]

Oops, compiler optimization tricked me (I've looked at it with the disassembler, as the diff appeared too big). Okay, then it's fine.