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 1 Guest are viewing this topic.

reddeercity

@ a1ex I posting when you posted this , I try this tomorrow -- should have time then  :D

reddeercity

Quote from: a1ex on November 20, 2018, 09:35:43 AM
Here's a simple task for you guys: find out how far you can push FPS timer A.

Steps:
- download raw_diag.mo and adtg_gui.mo and load them on top of the build from first post
- enable RAW Diagnostics (Debug menu)
- enable OB zones, disable other types of analysis
- in LiveView, press shutter halfway for 1-2 seconds to run the analysis
- enable ADTG Registers, enable Advanced -> ENGIO Registers, override FPS timer A (C0F06008) and decrease its value
- notice only odd raw values (i.e. same parity as with Canon firmware) are going to give clean image on this camera
- find the lowest value of timer A that still gives clean image (pay attention to the right border in the raw_diag screenshot)
- upload the raw_diag screenshot with the optimal value (clean image) and with the first bad value (that is, optimal value minus 2)

Run this in 1080p24/25/30 (during standby) and also in x5 zoom mode.

Mission accomplished
ob-zones.rar

default                                                                                                                     
1080 30p  1080 24p 1080 25p 480 30p 3xcrop-30p 3xcrop-24p
------------------------------------------------------------------------------------------------------------------------------------------------------

Modified Timer A c0f06008
NTSC 30p
1st: 23b0219=>31.864 fps -- good    2nd: 23b0217=>31.982 fps -- bad
1080-30p 1080-30p

NTSC 24p
1st: 23b0219=>25.491 fps -- good       2nd: 23b0217=>25.586 fps -- bad
1080-24p 1080-24p   

3x Crop_Mode 30p NTSC
1st: 277025d=> Good (fought to write down fps)     2nd:277025b=> Bad
3xCrop-30p 3xCrop-30p

PaL 1080 25p
1st: 2570219=>27.881 fps Good    2nd:  2570217=>27.985 fps Bad
1080-25p 1080-25p

NTSC 640x480 30p
1st: 23b0219=>31.864 fps Good   2nd:  23b0217=>31.980 fps Bad
480-30p 480-30p



a1ex

Pretty sure the modified images labeled as "good" are actually bad. Double-check the right side; if in doubt, check the DNG as well. An image is good if and only if all the columns contain valid image data (from the original subject, not noise). It doesn't have to be totally broken to be "bad".

480p is no different from 1080p on this camera; no need to include it.

x5 is only one, regardless of FPS. No need to use FPS override.

The x5 24p (ob-zon-5-3xCrop-24p-over-ride.png) probably was done using FPS override, and looks bad to me. There are 24 bad columns, so timer A - whatever it was in that mode - was wrong by 6 units. That means, FPS override should be fixed as well (FPS_TIMER_A_MIN in fps-engio.c).

In the other images labeled as "good", there are more than 50 bad columns (the chart displays only the last 50), so I'm unable to tell the exact number.

reddeercity

Ok ,
I used the "auto Preview" in all the tests , when the image got scrambled when I pushed timer A (decreased the number value)
I would increase the value until I got a clean image , noted the timer-A setting then decrease the number value by "2" this
would scrambled the image , so I called it "bad" .

I'll re-run the tests again with just the ML B/W low res . preview instead of "auto" preview .
with 1080 30p , 24, 25, & 3x crop 30p

Yes I ran 3x crop in 24p with frame over ride enabled .

reddeercity

Alright just did 24p in 1080 with ML gray preview ,
Is it right now ? 1080-24p-ob-zones_11-21-2018.rar

1080 24p Good
c0f06008 23b021c =>25.349 fps **good**

1080 24p Bad
c0f06008 23021a=>25.443 fps **bad**

Basically , I adjusted timer A (increase fps) until I saw a white line/bar in the image on the right side of Liveview and
dialed it back until the white line/bar was gone , (23b021c) that's the one I call "good"

On the one I call "bad" I dialed the value down by 2 (23b021a) .

If this is the right procedure , let me know and I'll finish the rest tomorrow .

a1ex

Nope, timer A still seems to be too low.

If in doubt, check or upload the DNG as well (either "dump raw buffer" from raw_diag, or plain silent pictures). Look closely at the last columns (they should not be black or white or otherwise static noise; they should have details from the test scene). These columns may not be obvious on the low-res preview.

Also, please pay attention to parity. Both of these examples show different parities, e.g. Canon value 0x23b is an odd number, modified value 0x21c is even. This causes some non-uniform noise (look closely at the images; it's no longer Gaussian).

reddeercity

Ok , I thought I my have messed up . Now I understand sorry slow learner  :)
Actually I did do a Image_Dump on both tests , just incase there were needed.
Good-RAW-013.DNG  & Bad-RAW-014.DNG

I'll re-run the test again & I'll  pay attention to parity

a1ex

These artifacts all over the image are caused by different parity of timer A (compared to Canon value).

From the DNG, I can now do the math. Number of bad columns: 52 in the "good" image, 60 in the "bad" image. Difference of 8. Timer difference: 2 units. One unit of timer A reads out 4 pixels, so it adds up. The "good image" is off by 13 units, the "bad" one is off by 15 units.

The screenshot shows the last 50 columns, and all of them were bad, so I could not do the math from there.

0x21c + 13 = 0x21a + 15 = 553 units. Adding 1 since hardware register is written with timer-1.

Therefore, the minimum timer A value in 1080p is 554 (when doing the math for frame rate) or 553 in the hardware register. Canon default is 0x23b (hardware register) or 572 (when doing the math).

That means, in 1080p24 and 30, we can reduce timer A by no more than 18 units (starting from default value of 572). In 25p, default value will be 600, so you'll be able to reduce it by 46 units.

This value (554) will give the lowest rolling shutter and the highest resolution at any given frame rate. Why not just using this? When aiming for a certain frame rate, timers can be set to integer values, so it may not be possible to get the requested frame rate with 3 decimal places. For example, 23.976 => timer B would be 1807 => 23.974 (closest approximation). For 25p => timer B would be 1733 => 24.998 fps. Or, 1732 => 25.012 fps. For this reason, we should try slightly higher timer A values that may result in frame rates closer to what we expect, but these higher timer A values will require lower values for timer B (which might limit the vertical resolution).

If you'll ever want to reduce horizontal resolution in 1080p (e.g. to get higher frame rates or smaller rolling shutter), you may reduce timer A even more. For example, if you are OK with 1872 pixels, you may use A = 552 (2 units = 8 pixels). If you want higher resolutions, you will need to add 2 units for every 8 pixels; however, on 5D2, you won't be able to increase active area beyond 1880 in 1080p; there are not enough pixels on the sensor. You can still request higher resolutions and get a "4K" frame good for April 1st announcements, if you want :D

Now it's your turn to do the same with x5.

reddeercity

Great ! thanks for the math ,

Quote from: a1ex on November 22, 2018, 08:16:08 AM
Now it's your turn to do the same with x5.
Ok , Weekend project .

Quote from: a1ex on November 22, 2018, 08:16:08 AM
You can still request higher resolutions and get a "4K" frame good for April 1st announcements, if you want :D
Yes , I like that idea ! :))

reddeercity

Continue on with the Timer A experiment , to see how far it can be push in 5x Zoom (3xCrop) .
but before I start I did a 4k frame in 1:1 (FHD) for kicks and
QuoteYou can still request higher resolutions and get a "4K" frame good for April 1st announcements, if you want :D
to see what happens , will something I thought that could not work .

1:1-FHD-4104x1249_RAW-015.DNG
4104x1249_RAW-015_uncroped.png
Default Crop Size               : 4104 1249
Active Area                     : 18 160 1267 4264



So I crop off the bottom part & ended up with 4104x594 , as you can see it's vertically compressed

4104x594_compressed_RAW-015.png

In Irfanview I vertically stretched the image 300% , pixel binding maybe "1:3" ?

I ended up with 4104x1782  :))

RAW-015_Unsqueezed_4104x1782.png

This was done in 1:1 FHD not 3x crop(5x zoom) that's what makes this so very interesting
Setting: 9.980 FPS
COMS[2] 0x40e ->0xe
c0f06008 0x23b023b ->0x23b080b **not too sure but very close to this**
c0f06088 0x4f40432 -> 0x4f4088a

So when I set CMOS[2] from 0x40e to 0xe that changed the image form the Full HD (pixel binding  & line skipping) to center crop at 1856x1249
then I slowed the frame rate to 9.980 fps and increased the raw image buffer to 0x4f4088a=>4096(4104)
I'm still wonder  how this possible , it shouldn't work unless I stumbled upon pixel binding mode  :o

Oh yea here the 4k ob zone that started this all

4K-FHD-ob-zon-7.png

a1ex

Yeah, binning factors on X and Y are pretty much*) independent. With the notation from crop_rec, this is the 3x1 binning mode (read 1 line, skip 2, read every column). You probably want to experiment with the opposite, i.e. 1x3.

Binning factor is controlled like this:
- horizontally: from CMOS registers (model-specific, CMOS[2] on 5D2); apparently doing proper binning on all models;
- vertically: from ADTG[1000/100C] or [8000/800C]; one register switches between 5 = read out every line and 6 = enable line skipping/binning, the other selects the number of lines skipped/binned.

*) On 5D3, in this mode (3x1) there are some artifacts I don't know how to fix; register ADTG[8806] appears to control these.

banertop

When i was shooting with this build, i had problem with opening 12 files in mlv producer
I got run-time error 52 - bad file name or number.

Did not have such a problem in the past.

Any ideas?

Tnx

reddeercity

It more then likely a problem with mlv producer , remember there was a issue with too many files open and causing a crash.
Report it on mlv producer thread , and post your log file from mlv producer also try deleting all your "idx" (index files) in the "data" subdirectory folder "IDX"



reddeercity

Quote from: a1ex on November 25, 2018, 09:52:22 AM
Yeah, binning factors on X and Y are pretty much*) independent. With the notation from crop_rec, this is the 3x1 binning mode (read 1 line, skip 2, read every column). You probably want to experiment with the opposite, i.e. 1x3.

Binning factor is controlled like this:
- horizontally: from CMOS registers (model-specific, CMOS[2] on 5D2); apparently doing proper binning on all models;
- vertically: from ADTG[1000/100C] or [8000/800C]; one register switches between 5 = read out every line and 6 = enable line skipping/binning, the other selects the number of lines skipped/binned.

*) On 5D3, in this mode (3x1) there are some artifacts I don't know how to fix; register ADTG[8806] appears to control these.

That's great , I gave 3x1 a try but unsuccessful -- It seem I can't find that long vertical with CMOS[2]
more investigation needed , I must be missing something .

reddeercity

I'm starting to finalize the crop_rec preset's , I'll keep 2880x1080 as is but it will not have the broken preview
as I found a fix with a1ex's help (as always  :) ) here is the post with proof.

2400x1200 @23.976 is next , It's 90% , just getting some image ghosting a little , but clean black levels .
5x frame blanking & CMOS[1] reg's were needed
CMOS[1] was changed to 0xe6a ->0xa28 (I think , I forgot to write it down)


2144x1200 @ 23.976 fps is stable and ready to go , post is here with samples
4096x1074 @ 18fps is working , and I will include it in the presets , I may be able to squeeze a few more frames/sec to 20fps
full res 5632x3750 @4 fps
I do plan on including a squeezed 48/50fps 1856x704 but there's still a black level issue , so that need to be fix before I can include it


This is not the final list of crop_rec preset's , but these are the ones I can get to work right now



banertop

reddeercity,

you were right!
the problem was with mlv producer. I did not use latest version. No problems with latest one.

very excited about your future crop build.

tnx

ilia3101

Quote from: reddeercity on November 30, 2018, 07:08:09 AM
I'm starting to finalize the crop_rec preset's , I'll keep 2880x1080 as is but it will not have the broken preview
as I found a fix with a1ex's help (as always  :) ) here is the post with proof.

2400x1200 @23.976 is next , It's 90% , just getting some image ghosting a little , but clean black levels .
5x frame blanking & CMOS[1] reg's were needed
CMOS[1] was changed to 0xe6a ->0xa28 (I think , I forgot to write it down)


2144x1200 @ 23.976 fps is stable and ready to go , post is here with samples
4096x1074 @ 18fps is working , and I will include it in the presets , I may be able to squeeze a few more frames/sec to 20fps
full res 5632x3750 @4 fps
I do plan on including a squeezed 48/50fps 1856x704 but there's still a black level issue , so that need to be fix before I can include it


This is not the final list of crop_rec preset's , but these are the ones I can get to work right now




Sounds amazing.

Are any of these available to test yet?

Also do you have a code repository/upload it somewhere?

reddeercity

No , not yet , thou you could load the adtg_gui.mo and manual set it .
I'm not the fastest or best coder  :D so may take me a little time , plus I would like to update 5d2 4k branch in to the main 4k branch
since we have "raw_slurp" working now ( 10bit_12bit FHD) like 5d3/D5 cams , there will be no need for waza57 edmac hack (to extend higher resolutions)

I may also add a cheap & dirty 4k/3.6k squeezed 3x1 in 1:1 FHD , there will be some Aliasing but not as bad as 3x3 .
I'm close to getting 24 fps (currently 20.5 fps unstable ,  17.3 fps stable no image artifacts) @ 3648x660 squeezed ( un-squeezed 3648x1980) 1.85:1 A.R. almost 16x9  :)
I'm most likely will have to reduce the vertical to 2.35 A.R. (1550) (squeezed 519) to get more fps , or more -- still experimenting .

@Ilia3101 , being using your app (mlv app 1.3) to get the right final size with 3x1 , thanks
It's 500% better then the last time I use it , (6 months ago)

From Image_Dump

3672x661-squeezed-RAW-018.DNG
3672x661-squeezed_RAW-018.png



3672x1983-RAW-018.png

Here a short 13Mb clip 14 seconds 3648x1980-17.3fps-M01-0004.mp4

reddeercity

Ok got it !  :)) 24 fps !! 3.6k Squeezed !!!


3672x513-RAW-020.DNG
3672x513-SqueezedRAW-020.png

3672x1539 @ 24 fps A.R. 2.375:1

3621x1539-UN-Squeezed_RAW-020.png




2 clips  -  3648x1536 @ 24.003 fps
No-frame_blanking-M01-2328.mp4
Frame_blanking-M01-2343.mp4

3672x513 @ 24.004fps
ADTG1[1061] frame blanking was add to try and get the frame ghosting to stop , still need more work.  :-\



A & B Timer info

banertop

wow...cant wait!!!

You are the man.

This is more than a  dream for 5d2

reddeercity

Going back to Hi-Frame rate 50/48fps to see if I can clean up the black levels.
Got side tracked , wanted to see how far I could push the frame rate passed 50 fps
in a smaller resolution (squeezed-1600x500=>un-squeezed-1600x832) (don't think 1856 will work , but didn't try)
I could push it to 64.020 fps but Liveview seemed to lockup/freeze -- battery pull.

But I can record at a little less frame rate 63.050 fps !! :D
Thou 62.5fps is more stable and has at least good black levels (101-1013 10bit) and mostly if not all artifact free.

Setting for 63.051fps @ 1600x500 (squeezed)


From .mlv file @ 62.50fps Squeezed

1600x500-M02-2327_000000.dng
1600x500-M02-2327_000000.png

Un-Squeezed 1600x832 @ 62.50fps

1600x832-M02-2327_000000.png

Here a short 5 second h264 clip -- 1600x832 @ 62.50fps
1600x832-62.5fps-M02-2327.mov

Photo from my iPhone with the camera @ 60.024fps


There one thing really puzzles me , as I increase the frame rate with timer "B" the image clean up ,
the black levels are better and no corruption . If you pan fast to a low light area then back to a Hi-Constat (bright Object) then there's the
odd corrupted frame or frames .

Wondering about sensor readout , 5d2 as noted by a1ex is 100 Mpixel/s (Mega pixel per second) on 4 Channels or 24 per channel
so could the bad black level/corruption be that at lower fps  (48/50) the channel band width is too wide as the 5d3 has twice this (at 8 channels) so
a narrower band width . Not too sure how to read this , I guess this sensor is too slow for what I'm expecting it to do.
Still trying to get my head around this sensor readout stuff to understand the limitation correctly .

Edit: found this about readout on CMOS sensor , Interesting !
https://www.researchgate.net/figure/a-Readout-direction-in-one-channel-and-b-the-timing-for-sensor_fig2_238541020

benoit

Quote from: reddeercity on December 02, 2018, 07:58:56 AM
Ok got it !  :)) 24 fps !! 3.6k Squeezed !!!
Could you explain me the reel pro of a high horizontal resolution squeezed at 24fps ? I can understand at 62fps to minimize the data rate per picture and getting better fps.
In this test image the aliasing is awful once unsqueezed, so I'm thinking I'm miss something.
David

reddeercity

Quote from: benoit on December 03, 2018, 11:10:56 AM
Could you explain me the reel pro of a high horizontal resolution squeezed at 24fps ? I can understand at 62fps to minimize the data rate per picture and getting better fps.
In this test image the aliasing is awful once unsqueezed, so I'm thinking I'm miss something.
David

Those are all experiment's for investigation purposes .

reddeercity

Ok I think I have found 3x1 pixel binding for reduce aliasing .

1856x1248 3x3 @ 29.97 fps (I haven't increased the raw height yet to 3750)

M03-1806_00001-3x3pinning.png

1856x412 3x1 

M03-1806_00001-3x1pinning.png


CMOS[1] 0xc00->0xbe0
ADTG12[100c] 0x2->0x100
c0f06084 0x10036 ->0x36 **I think , have to check again**


Need to clean up ,  just my very first try & test with this binning mode , still experimenting .
In theory , 3750/3=>1250

reddeercity

Finding different pining modes on 5d2 in 1:1 FHD (3x3) with
ADTG12[100c] 0x2 ->100
Compresses the image vertical 3x - maximum raw height 402=>1206
1856x402-M04-2332_000000.png
1856x1206-300%-M04-2332_000000.png

The image pretty bad , so I won't post a screen shot

ADTG12[100c] 0x2 ->107
Compresses the image vertical 6x - maximum raw height 210=>1260
1856x210-M04-2336_000000.png
1856x1260-600%-vertical-M04-2336_000000.png