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.

kwstas

@waza57

fixed, the problem occurs while FPS override is enabled.
Yet, 1920 1:1 does not work for me and 3.5k gives me a freezed display while recording, but I think that happened before.
Basically, I wish we don't have to zoom in 5x mode and have all this side effects (low fps, greyscale, freezes etc) and use just some basic crop rectangle in 1:1 instead.. but I guess there should be some limitations.

Nevertheless superb job considering this September mkII celebrates its 10-year birthday.. :D

waza57

@ kwstas

Thank you for the feedback.
I'm not sure to correctly understand but :

Quotethe problem occurs while FPS override is enabled
Yes I have not alerted about this because I think it is the case for all cameras model with crop_rec module . if someone can confirm ?

Quotefreezed display while recording
the preview is bad when recording but the recording is good , no ? same thing ,  if someone can confirm wit other cameras model ?

kwstas

Quote from: waza57 on September 02, 2018, 08:01:23 PM
the preview is bad when recording but the recording is good , no ? same thing ,  if someone can confirm wit other cameras model ?

exactly, recording is flawless, preview is freezed.

reddeercity

The frozen Liveview did happen on the 5D3 in crop_rec 4K if memory serve me correctly ,
I do think a1ex fixed that in mlv_lite , that the one I've been working from .
if you can fix the compiling problem/error in mlv_lite , has something to do with compressed raw 10,12 bit ?
I think I had it compiling in d4 4k crop_rec  , I do believe I just commented out the 10-12bit compressed stuff .
With mlv_lite the preview should be better , it where the bulk of the crop_rec 4k stuff is .

I can get around 30 second (average 79-80MB/s) after playing around with the srm write mode , "4" seem to be the fastest until a frame skips .
I did enabled "frame skipping" and shot a 8GB 1:40 second 2880x1080 clip , I really did notice any missing frames (unless it was just 1 frame)
It look seamless after rendering to a prores , next I'll try a talking head and see if there's a noticeable gap -- even if there is run a "bcam"
and kept recording 3k , if it's just one or two frame I can live with that for the monument .

Now next we need compression , that's lossless compressed raw . We are very close on the that front I think , the problem is the cam lockup's upon
saving a lossless silent photo (when we can save a lossless silent photo we should have it for raw video)
Here where we are at right now with 5D2/D4 cam's ProcessTwoInTwoOutLosslessPath

There may be another way also to increase the CF card write speed --
I notice in one of my LOG's that for some reason 5d2 clocks the UDMA at 6 , where the cards are rated for UDMA 7
825FE>  CSMgrTask:00095f98:00:00: *** register_interrupt("CFDriver", 0x82, 0xffb8b8cc, 0x0), from ffb8bb58
      .............
834A0>  CSMgrTask:ffb8a92c:22:05: [ID:Model Number] = LEXAR ATA FLASH CARD                   
834C8>  CSMgrTask:ffb8aabc:22:05: IDE = 4, PCMCIA = 80, UDMA = 6
      .............
83572>  CSMgrTask:ffbdb8a0:22:01: cfDecideTiming: UDMA Mode 6 (CFA4.0)
      .............
83592>  CSMgrTask:ffbdbb3c:22:03: CF_GetAccessTiming : DatTim = 3, DatMod = 6

Quote from a1ex here
Quote@reddeercity: more details after I'll get a new card (it *is* possible to overclock the 5D2 CF interface).
Quote from: a1ex on April 11, 2018, 07:48:49 AM
You can send ATA commands to the CF card (QEMU emulates them), so if the only difference between UDMA 6 and 7 is timing, it might even be possible to put the card in UDMA7.
If this could work , then we would have some write speed as the 5d3 or close to it (120MB/s) anything we could gain is better then 79MB/s
some related stuff --> https://www.magiclantern.fm/forum/index.php?topic=21311.msg204395#msg204395

Lots to do yet ,  but we are on the way  :D
Edit: just notice the crop factor when down from almost 3 (2.8 ) to 1.95 ,
which mean it's more usable  , e.g. 24mm -> 46.8 mm

waza57

@reddeercity
thanks for this detailed feedback!

Quoteif you can fix the compiling problem/error in mlv_lite
yes , I'm working on it.

QuoteNow next we need compression , that's lossless compressed raw
yes, I saw your work with A1ex but but it's not my speciality yet.

Quoteincrease the CF card write speed
yes , good idea . but compressed raw wouldn't be good enough  ?

Quotecrop factor when down from almost 3 (2.8 ) to 1.95 , which mean it's more usable
yes, so, don't you think that it remains also and above a problem with frame height?


reddeercity

Quote from: waza57 on September 03, 2018, 09:07:35 AM
@reddeercity
thanks for this detailed feedback!
yes , good idea . but compressed raw wouldn't be good enough  ?

No we need the higher write speed , compressed raw would give us (at .5 compression , which I read would the average)
from http://rawcalculator.netlify.com/calculator_desktop
basic 10bit just out of reach of cf/5d2-d4 cams

Resolution:2880x1080 10bit
Data rate:88.9MiB/s
Frame size:3.7MiB
Crop factor:1.96x crop
Field of view:20.8°
RECORD TIME: 5 minutes 43 seconds per 32GB card.

14bit compressed raw at .5 compression
Data rate:62.2MiB/s

So this would be the max if lossless worked on 5d2 , better crop factor

Resolution:3200x1080
Data rate:69.1MiB/s
Frame size:2.9MiB
Crop factor:1.76x crop
Field of view:23.1°


16x9 2880 with increased height & compressed raw , still out reach of the current CF D4 bandwidth (75-80MB/s)
need faster interface --  overclock the cf bus driver or find away to run cards at udm7 , theoretically @ umd7 the write speed should be 120-133MB/s

Resolution:2880x1556
Data rate:89.7MiB/s
Frame size:3.7MiB
Crop factor:1.96x crop
Field of view:20.8°

Max rez with compressed raw with increased height at the current cf bandwidth (75MB/s)

Resolution:2880x1200
Data rate:69.1MiB/s
Frame size:2.9MiB
Crop factor:1.96x crop
Field of view:20.8°


I prefer for more horizontal rez , thou there nothing wrong with increasing the height to the max .

This is what I'm hoping to reach as a goal for raw video , it could happen only with 2 things
compressed raw (.5) & faster UMD 6 ->7 & or overclock the cf interface on the write side

Resolution:3840x1556
Data rate:119.5MiB/s
Frame size:5MiB
Crop factor:1.47x crop
Field of view:27.5°


Now , I basic all this on continuous recording for raw video  @ 24p
If some user what to use the full width at lower frame rate with increase height at maybe 10 of 12 fps
for hyperlays etc... will that's great , so there's really should be no limit on resolutions just
limitations on the presets in the crop_rec.mo .

At least now I can say there's no more aliasing & moiré patterns  :)

Danne

Quote from: waza57 on September 03, 2018, 09:07:35 AM
yes , good idea . but compressed raw wouldn't be good enough  ?
Idea. What are the analog gain registers for 5D mark II? Dialing them down will darken output but also reduce bitrate in a lossless manner. For the 100D:
switch (crop_preset)
{
case CROP_PRESET_2K_100D:
case CROP_PRESET_3K_100D:
case CROP_PRESET_4K_100D:
{
/* assuming FPS timer B was overridden before this */
                int fps_timer_b = (shamem_read(0xC0F06014) & 0xFFFF) + 1;
                int readout_end = shamem_read(0xC0F06804) >> 16;    /* fixme: D5 only */

                /* PowerSaveTiming registers */
                /* after readout is finished, we can turn off the sensor until the next frame */
                /* we could also set these to 0; it will work, but the sensor will run a bit hotter */
                /* to be tested to find out exactly how much */

/* will add 10bit through analog gain */
adtg_new[0] = (struct adtg_new) {2, 0x8882, 0x46};
adtg_new[1] = (struct adtg_new) {2, 0x8884, 0x47};
adtg_new[2] = (struct adtg_new) {2, 0x8886, 0x46};
adtg_new[3] = (struct adtg_new) {2, 0x8888, 0x45};

/* even lower bits */
/* adtg_new[0] = (struct adtg_new) {2, 0x8882, 0x14};
adtg_new[1] = (struct adtg_new) {2, 0x8884, 0x15};
adtg_new[2] = (struct adtg_new) {2, 0x8886, 0x14};
adtg_new[3] = (struct adtg_new) {2, 0x8888, 0x13}; */

                adtg_new[4]  = (struct adtg_new) {6, 0x8172, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (6D/700D) */
                adtg_new[5]  = (struct adtg_new) {6, 0x8178, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3/6D/700D) */
                adtg_new[6]  = (struct adtg_new) {6, 0x8196, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3) */

                adtg_new[7]  = (struct adtg_new) {6, 0x8173, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (6D/700D) */
                adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
                adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3) */

                adtg_new[10] = (struct adtg_new) {6, 0x82B6, nrzi_encode(readout_end - 1) }; /* PowerSaveTiming ON? (700D); 2 units below the "ON" timing from above */

                /* ReadOutTiming registers */
                /* these shouldn't be 0, as they affect the image */
                adtg_new[11] = (struct adtg_new) {6, 0x82F8, nrzi_encode(readout_end + 1) }; /* ReadOutTiming */
                adtg_new[12] = (struct adtg_new) {6, 0x82F9, nrzi_encode(fps_timer_b - 1) }; /* ReadOutTiming end? */
}
                break;
}
    }


This part creates lossless:
/* will add 10bit through analog gain */
adtg_new[0] = (struct adtg_new) {2, 0x8882, 0x46};
adtg_new[1] = (struct adtg_new) {2, 0x8884, 0x47};
adtg_new[2] = (struct adtg_new) {2, 0x8886, 0x46};
adtg_new[3] = (struct adtg_new) {2, 0x8888, 0x45};

/* even lower bits */
/* adtg_new[0] = (struct adtg_new) {2, 0x8882, 0x14};
adtg_new[1] = (struct adtg_new) {2, 0x8884, 0x15};
adtg_new[2] = (struct adtg_new) {2, 0x8886, 0x14};
adtg_new[3] = (struct adtg_new) {2, 0x8888, 0x13}; */


Checking your code maybe put in the analog gain registers here?:
    /* these should work on all presets, on all DIGIC 5 models and also on recent DIGIC 4 */
    if (1)                  //waza57 here, I don't think this have an effect on 5D2 until we find proper regs
    {
        /* assuming FPS timer B was overridden before this */
        int fps_timer_b = (shamem_read(0xC0F06014) & 0xFFFF) + 1;
        int readout_end = shamem_read(is_digic4 ? 0xC0F06088 : 0xC0F06804) >> 16;

        /* PowerSaveTiming registers */
        /* after readout is finished, we can turn off the sensor until the next frame */
        /* we could also set these to 0; it will work, but the sensor will run a bit hotter */
        /* to be tested to find out exactly how much */
        adtg_new[4]  = (struct adtg_new) {6, 0x8172, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (6D/700D) */
        adtg_new[5]  = (struct adtg_new) {6, 0x8178, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3/6D/700D) */
        adtg_new[6]  = (struct adtg_new) {6, 0x8196, nrzi_encode(readout_end + 1) }; /* PowerSaveTiming ON (5D3) */

        adtg_new[7]  = (struct adtg_new) {6, 0x8173, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (6D/700D) */
        adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
        adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 1) }; /* PowerSaveTiming OFF (5D3) */

        adtg_new[10] = (struct adtg_new) {6, 0x82B6, nrzi_encode(readout_end - 1) }; /* PowerSaveTiming ON? (700D); 2 units below the "ON" timing from above */

        /* ReadOutTiming registers */
        /* these shouldn't be 0, as they affect the image */
        adtg_new[11] = (struct adtg_new) {6, 0x82F8, nrzi_encode(readout_end + 1) }; /* ReadOutTiming */
        adtg_new[12] = (struct adtg_new) {6, 0x82F9, nrzi_encode(fps_timer_b - 1) }; /* ReadOutTiming end? */
    }


White level will have to follow but this can be altered on the fly in Mlv App, or else some if statement in raw.c or maybe building a crop_rec.c header file...

yobarry

Quote from: reddeercity on August 31, 2018, 08:47:07 AM
Looking up now ,  :)
I'm taken baby steps , able to increase the height now with
c0f06088 , A & B timers , target height is 2160 -- I'm at 1760


I'm a big fan of the work you've been doing for the 5D2! When I check back into the ML forum it's basically just to see what progress you're making. Big thank you for the recent achievements! How's the working coming along with increasing the height? Have you been able to save any footage at 1760px?

reddeercity

Don't take this the wrong way but ,
Like I said before Lossless is not working period so the above is useless at this point , only uncompressed 10,12 & 14 bit works
For this thread 10bit uncompressed is what discussed as the norm . 

On the crop_rec.mo , I notice you can't change the ISO (at least didn't re-fresh in liveview) had to go to 10x adjust ISO then back again
before it would take effect in the crop_rec.mo 3.5k preset -- also tried to connect my hdmi zacuto evf while the in 3.5k preset , the screen what back
on the evf and recorded a few seconds and it change rez to 1856x1006 by it self . Un plugged the hdmi the lcd screen was back also .
flip back & fouth in 3x to 1:1 thern back to 3x toggle the crop_rec.mo off and on a few  then is was back to normal .

I think I know my problem with raw.c & "raw_slurp" I'm still using 0x02 as the write channel like the 12bit I use in 1:1 and I see in the Edmac.mo
I need to be on 0x0 .
I want to reproduce the experiment's from a1ex , like full width (5632x1074) & a1ex said he had figured out a 720p 50fps mode (1856x704 at 50.004 FPS)
Quote from: a1ex on September 02, 2018, 10:09:25 AM
Yes, I see it after getting out of LiveView and back. Works as expected.

Looking for a 720p mode on 5D2? Now we need to figure out how to reduce the resolution in order to increase the frame rate :)
    ...................
edit: reducing resolution seems to work, to some extent, LiveView is frozen, camera didn't crash after ~
1 minute (didn't try more), there are some black level issues, mlv_rec shows 1856x704 at 50.004 FPS.

reddeercity

Quote from: yobarry on September 05, 2018, 07:54:01 AM
I'm a big fan of the work you've been doing for the 5D2! When I check back into the ML forum it's basically just to see what progress you're making.
Big thank you for the recent achievements! How's the working coming along with increasing the height? Have you been able to save any footage at 1760px?
No not yet , test out the 2880x1080 24p preset from waza57 the least few days , I posted video links to prores files & test results here
I'll be back at it in few days  :)

waza57

@Danne
Thanks , I do not know this . I'll try to understand.
This is it is noted in TODO list

waza57

@Reddeercity

Ok, so,  if I understand ( my English is difficult) correctly:

with crop_rec , you can't change ISO settings and you have a black screen when you connect HDMi object?

question:
Is this the same when we use a 5D3 (with his crop_rec enabled)?

I need to know this for investigation , thanks.

reddeercity

Quote from: waza57 on September 05, 2018, 08:36:45 AM
@Reddeercity
with crop_rec , you can't change ISO settings and you have a black screen when you connect HDMi object?
Yes that right , ISO can only be adjusted outside of 3x crop_rec like 10x zoom and is applied correctly .
There seem to be no HDMI buffer , if you do a image_dump in the debug menu the HDMI dump is black  ,
there data in the dump image but all black . Once I connected the HDMI the Overlays where still there
I could go in to ML menu's etc. ..... when I disconnected the HDMI the LCD back screen was black .

If I remember right I disabled the crop_rec to get back the screen , once that happen things where back to normal
and could use crop_rec again without any problems .

Just looking at the Edmac.mo , your read buffer
4096x4096
which I thing is 32MB , that good
write channel "0" connection#5
with a buffer of
7200x1896

Now playing around with HDMI again -- will , sometime the hdmi image is pink noise and another had the frozen liveview
I think maybe there too much over head with HDMI , I did record a 170 frames with HDMI connected , the mlv recording was all messed up
I'm rendering a h264 version out M05-2314.mov (15Mb)
Liveview dump with HDMI

This is what the HDMI was showing , I took a photo after I dump the liveview image

here the LV-000.422 with HDMI connected & the HD-000.422 dumps

Another weird thing , if you disable the overlay to "Always" the Liveview freezes , but still able to record raw video
When you re-enable the Overlays the Liveview is back to normal .
got a idea , switch GD to allow is what happen , I thinking liveview will be not frozen no didn't work

waza57

OK, i added all this in my list of more and more things to do.
My version of crop_rec is essentially based on things known for a long time (see here for reminder)
I also think that A1ex seemed to be about to rewrite a crop-rec module that will work for 5D2 and probably more academically than I could do it.
With changes I do not know:

ADTG [100C]                                      -> I still do not see it (I guess good for the size)
C0F07150 and C0F0713C                  -> which does not change in with the code of the current crop_rec (possibly using adtg_gui.  I suppose good for the height)
"raw_lv_setedmac_patch" solution? -> with or without CONFIG_EDMAC_SLURP? (I guess good for the memory)

reddeercity

One thing I haven't tried yet was to "force hdmi to low rez."
There a option to force hdmi to 720x480 the same size as liveview , I'll try tomorrow .

12georgiadis

Quote from: reddeercity on September 07, 2018, 06:49:39 AM
One thing I haven't tried yet was to "force hdmi to low rez."
There a option to force hdmi to 720x480 the same size as liveview , I'll try tomorrow .
For one project, I needed a monitor HDMI + raw rec on 7D and had a black screen. Force to VGA low rez solved the problem for liveview

ilia3101

Congtartiulations waza57 and reddeercity!!! Sorry I never got involved, magic lantern development/hacking just seems to be something I can not get the hang of even a tiny bit.

THis is amazing I will try and fix my 5D mark II as soon as I can. I am truly excited.

The PNG samples on 5D2 thread have really jagged edges, could you upload some dngs?

reddeercity

Quote from: Ilia3101 on September 07, 2018, 08:44:48 PM
Congtartiulations waza57 and reddeercity!!! ....
The PNG samples on 5D2 thread have really jagged edges, could you upload some dngs?

Sure , here you go , I dumped the dng's to true 10bit .  I had to use a Old version of mlv_dump , the new one keeps upsampleing to 14bit for some reason .
the difference is size , 14bit 5.3MB & 10bit 3.7 MB
M02-1800_000000_2880x1080_10bit.dng
M02-1810_000000_2880x1080_10bit.dng
M02-1802_000010_2880x1080_10bit.dng

reddeercity

@waza57 , tried to "force hdmi to VGA" (720x480) just pink noise , but there is movement when recording raw video , the preview is not frozen .
Looks like frame rate (fps) is out or the size of the buffer that feed in to the encoder is messed up .
more low level investigation is needed .

Edit: checking the mlv file I recorded (2880x1080) with HDMI force to VGA (720x480)
No frame corruption as seen on the previous file I posted here Made a quick h264 file of that recording here

reddeercity

Something interesting , I think this for D4 cams 5d2 etc. .... from http://magiclantern.wikia.com/wiki/Register_Map
0xC0F383D4 Preview area (y1 << 16) | (x1/4), similar to raw_info.active_area (5D3)
0xC0F383DC Preview area (y2 << 16) | (x2/4)

useful ? needs investigation

reddeercity

@waza57 , this could useful for HDMI preview , from my decompiled 5d2 rom
https://www.magiclantern.fm/forum/index.php?topic=21311.msg197060#msg197060
ff0316b4 FramTable == NULL
ff031b47 @DP_SetCroppingFrameLocation(X:%d Y:%d W:%d H:%d)
ff031b7c BaseW:%d BaseH:%d Angle:%d
ff031b9f @DP_SetCroppingFrameLocation FrameSize Exchange To HDMI
ff031bd8 Angle == 3600

Would be nice to know what the in the "framtable" 

ilia3101

Thanks for the DNGs they look wonderful, highlights ont he first one are smooth 😍

reddeercity

Notice on the 3.5k preset the image is not centered , it looks like it's Left and down of center

ilia3101

Can you not move it like in normal crop recording?

reddeercity

Quote from: Ilia3101 on September 11, 2018, 06:30:15 PM
Can you not move it like in normal crop recording?
No , I think because the crop windows has increased from default .