3K/UHD 5D2 Raw development and Other Digic IV Cams

Started by reddeercity, April 06, 2017, 12:22:27 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

dariSSight

@reddeercity I've been watch your God like devotion to further improving 5D2 Thanks a million. This looks promising so when can we mere mortals get to test it?
Canon 5D Mark II

DeafEyeJedi

5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

Greg

Quote from: reddeercity on April 24, 2017, 05:15:56 AM
In 1:1 a surprising 2040x1268  and in 3x crop (5x Zoom) 2312x1128 , Really !
I was under the impression that full Liveview was only 1880x1250  and 3x crop was 2152x1078.

This is probably a resolution with black borders.

raw.c
#ifdef CONFIG_5D2
skip_top        = zoom ?   52 : 18;
skip_left       = 160;
#endif

PressureFM


reddeercity

@PressureFM  thanks , the more the merrier .
Currently the issue is the customs Raw LV buffer , I've been trying to spy the memory to find the LV raw buffer
and looking thought my 5d2 decompiled rom dump for addresses , a1ex gave me some clues at the links
http://www.magiclantern.fm/forum/index.php?topic=19336.msg183374#msg183374
http://www.magiclantern.fm/forum/index.php?topic=19336.msg183382#msg183382

I found the registers needed to modify frame size with adtg_gui but the problem is the LV buffer
I did have some success with my  RAW_LV_BUFFER_ALLOC_SIZE (2040*1267) as per post #27
The reason I used that was it was the largest buffer on the edmac & it didn't change when switch to Photo Liveveiw see post #49
Edmac#5 buffer size is what I used , now I think there's I little dilemma here , when I updated to "new-lv-buffer-detections" branch and complied
I ended up with the older core "Magic Lantern v2.3.NEXT" , reason I mention this edmac#5 is Green (active) where in the nightly builds compiles
on newer code edmac Channel #5 is Yellow , which I think is a error  or all this could mean nothing , just thought I would mention it .
So Yea LV raw buffer needs to be solved & I thing that will also help to get 10 & 12bit problem in 1:1 solved also

Link to my bitbucket downloads for those memspy builds I talked about .
magiclantern-Nightly.memspy.lv.raw.buffer.extended.resoultion.2017Apr24.5D2212.zip
magiclantern-v2.3.NEXT.Memspy.2017Apr23.5D2212.zip
You may just want to compile your own copy of adtg_gui from the ISO-research branch or you can download a copy from my bitbucket download.
So any suggestion are very welcome  :D

reddeercity


ff036750 lv_rshd_raw
ff0365f4 lv_raw_dump
ff036704 lv_save_raw
ff036724 lv_continous_frame
ff036760 lv_rec
ff03676c lv_output_device
ff036604 lv_continous_frame_save
ff036784 lv_hd

some lv raw stuff from my decompiled rom dump , I think the ff036750 lv_rshd_raw is what I'm after
FF036520: e59f1224  ldr r1, [pc, #548] ; 0xff03674c: pointer to 0xff8347f8 ⬁
FF036524: e28f0f89  add r0, pc, #548 ; *'lv_rshd_raw'


dropbox link to FF036524.htm where I found the raw liveview from the decompiled rom

DeafEyeJedi

This is all nothing short of spectacular and wonderful progress so far. Just confirmed w my co-worker to bring his 5D2 to work tmw for me to test out the memspy build.

Thanks @reddeercity just for being you, as always!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dariSSight

Quote from: reddeercity on April 25, 2017, 05:09:21 AM
@PressureFM  thanks , the more the merrier .
Currently the issue is the customs Raw LV buffer , I've been trying to spy the memory to find the LV raw buffer
and looking thought my 5d2 decompiled rom dump for addresses , a1ex gave me some clues at the links
http://www.magiclantern.fm/forum/index.php?topic=19336.msg183374#msg183374
http://www.magiclantern.fm/forum/index.php?topic=19336.msg183382#msg183382

I found the registers needed to modify frame size with adtg_gui but the problem is the LV buffer
I did have some success with my  RAW_LV_BUFFER_ALLOC_SIZE (2040*1267) as per post #27
The reason I used that was it was the largest buffer on the edmac & it didn't change when switch to Photo Liveveiw see post #49
Edmac#5 buffer size is what I used , now I think there's I little dilemma here , when I updated to "new-lv-buffer-detections" branch and complied
I ended up with the older core "Magic Lantern v2.3.NEXT" , reason I mention this edmac#5 is Green (active) where in the nightly builds compiles
on newer code edmac Channel #5 is Yellow , which I think is a error  or all this could mean nothing , just thought I would mention it .
So Yea LV raw buffer needs to be solved & I thing that will also help to get 10 & 12bit problem in 1:1 solved also

Link to my bitbucket downloads for those memspy builds I talked about .
magiclantern-Nightly.memspy.lv.raw.buffer.extended.resoultion.2017Apr24.5D2212.zip
magiclantern-v2.3.NEXT.Memspy.2017Apr23.5D2212.zip
You may just want to compile your own copy of adtg_gui from the ISO-research branch or you can download a copy from my bitbucket download.
So any suggestion are very welcome  :D

Forgive me for my ignorance but what do I do with the downloads to us this build?
Canon 5D Mark II

reddeercity

From the live view log , from DeafEyeJedi
Some very interesting information about liveveiw specially the "tomSetRawJpgMode (Type = 0x4)"
Thou I don't understand it all give more info to work from that I don't have before
thanks to a1ex  ;)

line 1760 --- 51BF1>      TOMgr:ffa21790:41:05:  tomSetRawJpgMode (Type = 0x4)
line 2163 --- 6A4E4>    Startup:ff8e5f88:98:03: GetImageTrimming X(2976)=0(2414, 2416), Y(1928)=0(1552, 1548)


line 2293 --- 72089> LiveViewMg:ff8e6108:98:02: Origin2 X=911, Y=518 W:1122 C:2976

line 2294 --- 721BA> LiveViewMg:ff8de8e0:9b:03: PROP_MOVIE_PARAM 0 1

line 2295 --- 722B0> LiveViewMg:ff8dd52c:9b:16: PROP_LIVE_VIEW_VIEWTYPE_SELECT 0->2

line 2296 --- 722F3> LiveViewMg:ff8dcdb0:9b:03: ViewType:2

line 4927 --- 38AAA>    Startup:ff867658:82:03: InitializeDisplayDeviceController (PUB)

start at line 4975

3BA12> GuiMainTas:ff892834:85:03: AllocateVramCBR pAddress=43f80000
3BA90> GuiMainTas:ff86503c:00:03: [BmpDDev] CreatePhysicalVram (PUB)
3C401> GuiMainTas:ff864db0:00:03: [BmpDDev] DisplayPhysicalScreen (PUB) 0x43F00008
3C49C> GuiMainTas:ff9a77d0:00:01: [CLKSAVER] ��ClockSave In��
3C4D9> GuiMainTas:ff864be8:82:02:  SelectParameterToBmp (PRI)
3C502> GuiMainTas:ff864a40:82:02:  SetParameterToBitmapDisplayDevice (PRI)
3C526> GuiMainTas:ff864d3c:82:02: EnableBitmapVBufferForPlayBackAndWaiting (PUB)



3D012> GuiMainTas:ff83f068:36:05:  RegisterAdapterStatusCallback
3DB69> GuiMainTas:ffa84814:04:02: Partial memcpy start (x,y,w,h)=( 0, 0, 960, 540 )


4039D> GuiMainTas:ffa84844:04:02: Partial memcpy end
403D0> GuiMainTas:ff9c17ac:83:03: GuiStartGraphics (PUB)
404CE> GuiMainTas:ff82ebd4:80:03: SRM_AllocateMemoryResourceForImgVram 131 3
40582>     RscMgr:ff8b6ea8:80:03: srmAllocateImgVram 131 3
405BD>     RscMgr:ff8b6ec8:80:03: ImgVram Before -1 -1 -1
405F8>     RscMgr:ff8b6fa4:80:03: ImgVram After 131 131 131
4067A> GuiMainTas:ffa41e6c:18:03: (PUB) StartImagePlayer(mode=0) 1203
406BE> GuiMainTas:ffa42000:18:01: mode:0 dec:0x0 rot:0x0 2nd:0x0
406E6> GuiMainTas:ffa4532c:18:03: (PUB) SetVisibleImageVramOffset 4064
40712> GuiMainTas:ffa42304:18:03: (PUB) SetCopyVramMode(mode=0) 1411
4073B> GuiMainTas:ff9c15b0:83:03: GuiGraphicsNormalMode (PUB)


40760> GuiMainTas:ffa4522c:18:03: (PUB) SetImageWorkMemory 1:0x40d00000, 2:0x41700000
40799> GuiMainTas:ffa45274:18:03: (PUB) SetImageWorkMaxPixel W:2200,H:1872,0x5e4340
407CD> GuiMainTas:ffa44db8:18:03: (PUB) SetEffectiveSizeOfJpeg(w:7488 h:4992) 2995
407F8> GuiMainTas:ffa44dd0:18:01: SetEffectiveSizeOfJpeg w:7488 h:4992
40824> GuiMainTas:ffa423f8:18:03: (PUB) SetYuvColorParameter 1447
4089A> GuiMainTas:ff9dc868:83:03: IDLEHandler INITIALIZE_CONTROLLER
408CD> GuiMainTas:ff9dd028:83:03: IDLEHandler GOT_TOP_OF_CONTROL
408F1> GuiMainTas:ff9c3ffc:83:03: GuiClearImage
40914> GuiMainTas:ffa420fc:18:03: (PUB) SetVramInformation(w:1920 h:1080)
4094C> GuiMainTas:ffa421cc:18:03: 1920x1080 BaseVram:1920, VramYuv:1
40977> GuiMainTas:ffa421cc:18:03: 1920x1080 BaseVram:1920, VramYuv:1
409A0> GuiMainTas:ffa42210:18:01: fLcd 0


409C8> GuiMainTas:ffa423b8:18:03: SetImageVramParameter x:0 y:0 w:1920 h:1080/* Aspect:0*/
409FE> GuiMainTas:ffa44c3c:18:03: (PUB) SyncroAllClearImagePlayWorkVramWithoutEngine 2953
40A27> GuiMainTas:ffa4161c:18:03: GetVramNumber 619
40A4B> GuiMainTas:ffa4161c:18:03: GetVramNumber 619
416A5> **INT-0Ah*:00095c38:00:00: >>> INT-Ah Timer ff81027c(0)
416E5> **INT-0Ah*:0000057c:00:00: <<< INT-Ah done
43DB3> **INT-0Ah*:00095c38:00:00: >>> INT-Ah Timer ff81027c(0)
43DDC> **INT-0Ah*:0000057c:00:00: <<< INT-Ah done
45389> GuiMainTas:ffa420fc:18:03: (PUB) SetVramInformation(w:720 h:480)
453B5> GuiMainTas:ffa421cc:18:03: 720x480 BaseVram:720, VramYuv:1
453DD> GuiMainTas:ffa421cc:18:03: 720x480 BaseVram:720, VramYuv:1
45406> GuiMainTas:ffa42210:18:01: fLcd 0


4542B> GuiMainTas:ffa423b8:18:03: SetImageVramParameter x:0 y:0 w:720 h:480/* Aspect:0*/
45459> GuiMainTas:ffa4161c:18:03: GetVramNumber 619
45483> GuiMainTas:ff863840:82:02: GetVramSize (PUB)
454BD> GuiMainTas:ff86413c:82:03: EnableImagePhysicalScreenParameter
4556B> GuiMainTas:ff9a77d0:00:01: [CLKSAVER] ��ClockSave In��
455AC> GuiMainTas:ff8638c4:82:01: ImgDDev SelectParameter DispType=0
455D1> GuiMainTas:ff863840:82:02: GetVramSize (PUB)
455FC> GuiMainTas:ff8640d4:82:02: EnableImageVBufferForPlayBackAndWait (PUB)
45688> GuiMainTas:ffa4161c:18:03: GetVramNumber 619
456BD> GuiMainTas:ffa4161c:18:03: GetVramNumber 619

ItsMeLenny

Can somebody explain in laymans terms what needs to happen to get this to 550D.
And also what exactly is this. Is this for the different bit depths, or for the compressed raw, or for 1:1 pixels.
I'm never entirely sure.
In addition to that, is it compressed raw being referred to as "lossless".

reddeercity

Quote from: ItsMeLenny on May 14, 2017, 04:17:36 AM
Can somebody explain in laymans terms what needs to happen to get this to 550D.

Quote from: a1ex on April 18, 2017, 11:55:34 PM
The custom buffer is required, as ML redirects it only while recording.
In the crop_rec_4k branch I've used a SRM buffer (which can accommodate a full-res 14-bit picture).
This needs to be passed to SetEDmac as the first argument (instead of Canon's default buffer).
The buffer redirection without CONFIG_EDMAC_RAW_SLURP is fragile:
it relies on lucky timing. It's best refactored somehow, but cache patching is also ugly...
Quote from: ItsMeLenny on May 14, 2017, 04:17:36 AM
.... is it compressed raw being referred to as "lossless".
Yes
------------------------------------------------------------------------------------------------------------------------

I keep running in to walls .

What needed now is someone with advanced knowledge of digic4 Liveview buffers , that would be a main developer like a1ex
this is getting above my knowledge level right now.

dfort

Ha ha. That's how I feel too. Been trying this on a couple of Digic V cameras but keep running into walls too.

Maybe put it aside and try something else for a while.


Sent from my iPad using Tapatalk


a1ex

For 550D, the interesting parts are:
- for video: the lossless compression
- for timelapse: the full-res LiveView

The first one was covered in detail in "the two in two out discussion", with partial success on 500D (only working outside LiveView, and output not decoded yet). Until the first issue (which wasn't present on 5D3) is solved, porting it probably doesn't make much sense, as the two models are very similar, and you'll likely run into the same problem. Newer models (60D and newer) are probably much easier to port, as their LiveView implementation is a lot closer to 5D3's.

The second one (full-res LiveView) requires adtg_gui (iso-research branch), but to explain in detail how it works, I need to try it myself on an old-gen camera, to have an idea of similarities and differences. The most promising attempts, at the time of writing, are on 700D and 5D2 (this thread).

However, increasing the resolution beyond what you get in regular LiveView requires allocating a new buffer. On recent cameras, it's easy (just enable some definitions and tell how much you need - see how it's done on 1100D and 5D3). On old generation cameras, it's hard and probably requires patching Canon code.

Other than that, it's just a matter of patching some registers (see the crop_rec source code for the various presets).

Quote from: reddeercity on May 15, 2017, 04:48:33 AM
What needed now is someone with advanced knowledge of digic4 Liveview buffers

Unfortunately, my level of understanding is not there yet, but I've made some small progress emulating the LiveView in QEMU. On 500D, it appears to work for a few frames before locking up, so it's not yet published :D

However, both the 550D and 5D2 (and other models) now have the GUI emulation working (you can navigate Canon menu in the emulator), so the first step for LiveView is to get a set of MPU spells that covers... entering LiveView. This is easy - use the dm-spy-experiments branch (or the startup-log builds), enter LiveView while the LED is blinking (that is, while debug messages are recorded) and then run the extract_init_spells.py script on the log file. This alone is enough for some LiveView bitmap overlays on 500D (Greg's screenshot - didn't try on other models). Progressing from there is much harder. I can share the current patch if there is interest, but it's "too much of a hack" at this stage. I recommend starting with easier things instead.

Currently, adtg_gui and the QEMU LV trick are low-hanging fruits. Creating debugmsg.gdb files for camera models that don't have one, or adding more entries to an existing one, is also very easy (as they mostly contain stubs).

Porting the FRSP emulation to QEMU ranges from extremely easy to hard, depending on model. For some models, you only need to supply a reference full-res DNG and to add the camera model to the test suite - in other words, confirming it's working. Others may require some minor fiddling, others may require a deeper level of understanding. To get started, look up FRSP or FA_CaptureTestImage on the QEMU test suite (logs, screenshots). At the time of writing, this is working on 60D, 1200D, and also 5D3 1.1.3 (where my test image has a hot pixel in the OB area, which is the reason for not passing the test). Models with GUI emulation are probably easier to adapt (just a guess, as I didn't try).

Playing with custom logging on the dm-spy branch is also easy once you get some courage, and can be done on both a real camera or QEMU. Understanding the logs is harder. LiveView is *very* complex, so it makes sense understanding smaller bits first (such as logging task names as they are started, or following a button event).

Debugging the lossless compression routine in QEMU should also be accessible. You'll need to run both Canon's original routine and your modified one with "-d io" and compare the JPCORE and related I/O activity - see Greg's examples.

Emulating a CR2 picture taking (until getting a valid CR2 on the SD/CF card image) should be also doable, and a whole lot easier than emulating LiveView. Maybe I should try that first.

ilia3101

Quote from: a1ex on May 15, 2017, 11:36:13 AM
use the dm-spy-experiments branch (or the startup-log builds), enter LiveView while the LED is blinking (that is, while debug messages are recorded) and then run the extract_init_spells.py script on the log file.
Does this still need to be done for 5D2?
just in case: https://www.dropbox.com/s/84hknim2jrhd5ww/copypasta.txt?dl=0
The script needed some changes tho, this didn't work:

cam_dir = [d for d in os.listdir(ml_dir)
             if d.split(".")[0] == camera_model
             and os.path.isfile(os.path.join(ml_dir, d, "gui.h"))
          ][0]

just manually set it to "5D2.212", also default ML directory was wrong in my case.
^^ Maybe that helps anyone else doing it.

a1ex

Right now, none of the spells from the repository include LiveView activity (it was easier to understand how it works without it). I've only tried the LiveView trick on 500D (which I find easier to understand). So, if you want to play around, you can give it a try; however, once you get past the initial GUI (or maybe earlier), you *will* "run into walls". I'm currently in the middle of one such wall :P

An initial goal would be to get both the menu navigation and the LiveView trick in the same set of spells - that didn't work in my experiment, but it's probably easy to fix. Either perform both menu navigation, play mode switch and LiveView in the same logging session to re-create the spell set from scratch, or figure out which bits are specific to LiveView and add them to current spell set.

BTW, the script is meant to be run from the QEMU installation directory (outside the ML tree). That's probably the reason you've got the path error.

reddeercity

Thanks a1ex , I was hoping for something like this  :D gives me more meat to chew on.
Quote from: a1ex on May 15, 2017, 11:36:13 AM
This alone is enough for some LiveView bitmap overlays on 500D (Greg's screenshot - didn't try on other models).
Progressing from there is much harder. I can share the current patch if there is interest
I would be interested in at least looking at the code .
Great there's still a change this can be ported  8)

ItsMeLenny

Any progress on this? Seems to have stopped still for a month.
Has the way to crop record been discovered yet?

reddeercity

Quote from: ItsMeLenny on June 12, 2017, 02:17:53 PM
Any progress on this? Seems to have stopped still for a month.
No.
Reason , there is no interest in any Digic IV (4) development The forum is being driven by Digic V (5) and up cameras , in particular 5D3.
If you think I'm kidding just look at all the posts over the last mouth . In fact even 10 or 12bit development is dead for Digic IV cam's
other then the experimental builds I have on my bitbucket download  , no one else really care and that a trouble shame ! :(
As I don't see anyone else participating here , I can no longer justify developing this thread .

Quote from: ItsMeLenny on June 12, 2017, 02:17:53 PM
Has the way to crop record been discovered yet?
It's very close , the only issue is having a custom image buffer with the right address .
I already know which registers that need to modified but with out the correct buffer/memory address it stop there .

Even thou I would really like to see this for the 5d2 , I want this for all digic 4 cams ( Wishful thinking)
In the near future if I see activity here then I my continue further , until such time I'll just make improvement's for myself .
Sorry

ItsMeLenny

I'm very keen for it for 550D. Hopefully to have something that can record 1080p 10bit.
Yeah the discussions on the forums do seem to be around 5d3, but I still think there's interest for Digic IV, they're just not very talkative.
And I think it's also partly due to it working on Digic 5, so people are using it. Where as it doesnt work on 4.
I can imagine Digic 4s becoming popular in discussion if there were things like 2K/4K 10bit and all that hoohar.

Let me know if I can do anything.

Ottoga

+1 here with a 7D. Can't code but can test.

I'm sure that there are plenty of lurkers waiting for something exciting to happen that they can assist with.
EOS 7D.203, EFS 55-250mm, EF 75-300 III, Tamron 16-300 DiII VC PZD Macro, SpeedLite 580EX II.

loknar

@reddeercity
It's not like we wouldn't like new builds, but most of us are not programmers, so we do some test, and that's it. I for one would love 10-bit RAW working on 550D, but I have same problems as others, all frames are corrupted 1/3 of screen is shifted and frozen. Since this has been reported, i'm afraid that's all I can do.

(I was also hoping in mv1080 on EOS M, but all my questions in appropriate threads have been ignored, so i kinda gave up)

dfort

Quote from: loknar on June 19, 2017, 08:54:30 PM
(I was also hoping in mv1080 on EOS M, but all my questions in appropriate threads have been ignored, so i kinda gave up)

What do you mean? EOS M can do mv1080 if you turn on H.264 proxy. It is rather buggy and experimental but hey.

http://www.magiclantern.fm/forum/index.php?topic=16608.msg179969#msg179969

Tullen

I really want to get this going, especially for the 50D. As soon as I have fished my thesis I hope to be able to help. Even would like to start a Magic Lantern club in Stockholm. That would be in September though. Please dont give up. I am sure that more people would like to help. I am willing to put in time for this for sure.

loknar

Quote from: dfort on June 20, 2017, 01:22:56 AM
What do you mean? EOS M can do mv1080 if you turn on H.264 proxy. It is rather buggy and experimental but hey.

http://www.magiclantern.fm/forum/index.php?topic=16608.msg179969#msg179969

I mean I wasn't able to replicate it, I wasn't able to get same nightly and with my version of ML although i've been able to capture whole frames, all were in pink and after correction of black and white levels it has been extremely noisy to the point of unusability. Same processing of test mlv of Koks the cat lead to excellent results, just my camera didn't deliver same input. When I asked about what build i should use, it stayed unanswered  ( http://www.magiclantern.fm/forum/index.php?topic=9741.msg183234#msg183234 ) (not complaining, just stating). I've got in bookmarks your bitbucket page, but you wrote that your version was really experimental, and also i'd have to update firmware to 2.03, and i thought since 2.02 is more mainstream, that development would go faster there.