ProcessTwoInTwoOutLosslessPath

[dfort]

Ok--let's see if the 6D needs the RABBIT.

Code: [Select]

    if (is_camera("6D", "*"))
    {
        /* 6D and 5D3 - maybe needed for full frame cameras? */
        EngDrvOut(0xC0F13068, PACK32(width*2  - 1,  height/2  - 1));  /* 0xF6D171F */
    }

If this caused issues on 700D and EOSM it will probably also cause issues on 650D.

New 6D test build uploaded.

[Levas]

This build from Dfort has working full-res-silent lossless pictures.
Simple lossless also works
And I have recorded a 14 bit lossless mlv (1824x1026) which gave normal frames.

So this means that the 6d doesn't need RABBIT, right ?

[dfort]

Careful with the RABBIT -- it could bite your head off! (Yeah, I'm a Monty Python nerd.)

Need some feedback from 650D and 70D users.

[a1ex]

What did the RABBIT on 700D and EOSM?

Does it work with plain width and height, rather than width*2 and height/2 ? (for 6D and 700D/M)

[dfort]

You mean like this?

Code: [Select]

    if (is_camera("[camera to test]", "*"))
    {
        EngDrvOut(0xC0F13068, PACK32(width  - 1,  height  - 1));  /* 0xF6D171F */
    }
Or also take out the "-1" ?

[Levas]

Made the above suggested changes and all is still working normal on the 6d.
Full-ress-silent lossless -> works
1824x1026 MLV 14 bit lossless -> works

[a1ex]

@dfort: keep the -1.

    EngDrvOut(0xC0F13068, 0x0x1edb0b8f);  /* 0xF6D171F */

If I change it [0xC0F13068] to something that has the same area (in the above example: 5920x3950 -> 2960x7900), it still works

If you get it working, the question also applies to full-res lossless encoding without height-1, and if that doesn't work, with height+1, height+3, height+5 etc (as the encoder might require even heights).

[dfort]

The EOSM tests came out pretty much like what @Levas found on the 6D. I also tested removing the -1 and it didn't work.

EOSM: (width*2  - 1,  height/2  - 1) -- will not save lossless compressed DNG's
700D: (width*2  - 1,  height/2  - 1) -- will not save lossless compressed FRSP DNG's but works with simple silent
EOSM: (width  - 1,  height  - 1)     -- works with simple silent and FRSP lossless compression and uncompressed
700D: (width  - 1,  height  - 1)     -- works with simple silent and FRSP lossless compression and uncompressed

Both the 700D and EOSM are also doing fine without manipulating C0F13068 as in the current PR and the current crop_rec_4k.

Now for the strange part. While testing the 700D I would sometimes get DNG's that would not open in Adobe Camera Raw, though dcraw has no problems with the files. I could not reproduce these errors consistently. They might be build errors because it wouldn't happen after running "make clean" from the top directory. (I was taking a shortcut an only rebuilding the silent module.)

More quirks with the 700D. The DNG files, both compressed and uncompressed, aren't viewable with the Mac's quick view feature but they usually open fine in ACR. Another thing I never noticed before is that if you shoot a simple silent DNG (compressed or uncompressed) in photo mode it will use the mv720 raw buffer even though the movie setting is on 1920x1080 but if you shoot the silent still in movie mode it will use the mv1080 buffer.

Ok--so, what should we do with the RABBIT?

[EDIT] Seems like it would be fine to add it to the general Digic 5 stuff:

Code: [Select]

EngDrvOut(0xC0F375B4, PACK32(width    - 1,  height/2  - 1));  /* 0xF6D0B8F on 5D3 */
EngDrvOut(0xC0F13068, PACK32(width - 1,  height  - 1));       /* 0xF6D171F on 5D3 */

[a1ex]

Ok--so, what should we do with the RABBIT?

If the version with width-1 and height-1 helps breaking the encoder height limit on 700D/100D/M/etc (see the updated question in previous post), I'm tempted to place it in the common block (for all D5 models, since all of them use this register).

[dfort]

If you get it working, the question also applies to full-res lossless encoding without height-1, and if that doesn't work, with height+1, height+3, height+5 etc (as the encoder might require even heights).

This is working:

Code: [Select]

        EngDrvOut(0xC0F13068, PACK32(width    - 1,  height));         /* 0xF6D171F on 5D3 */

I'm updating the PR and making new test builds.

Note that I haven't been testing the 5D3 because I've got enough on my plate for now and you are already checking it.

[a1ex]

I meant, can you save full-res lossless DNG with height greater than 3528 on 700D/M?

(the answer will be useful as documentation, regarding what this register does - what we know about it; I don't care about that one pixel difference, I just want to know where that limit comes from)

[Levas]

@Alex.
The FRSP lossless I get with all working builds from today are all in 5496x3670 resolution.
While CR2’s are in 5472x3648 resolution 
Could it be that this difference in resolution, ‘break’ full res silent in the first place?

[a1ex]

Yes, this is the limit I'm talking about. Encoding an image larger than a CR2 works on some models (including 6D and 5D3), but not on others (700D/M/100D), and that's the point of these tests - to figure out why.

[dfort]

I think the idea is to try some of these:

Code: [Select]

EngDrvOut(0xC0F13068, PACK32(width    - 1,  height));
EngDrvOut(0xC0F13068, PACK32(width    - 1,  height +1));
EngDrvOut(0xC0F13068, PACK32(width    - 1,  height +3));
EngDrvOut(0xC0F13068, PACK32(width    - 1,  height +5));
And keep going until it breaks, right?

Hard to get my head back to where it was a month ago.

[dfort]

Running out of time for today but ran a test on the EOSM and turned the volume up all the way to 11.

Using ACR:

CR2 - 5184x3456
FRSP DNG +0 through +11 - 5208x3476

In other words, no difference in the size of the image by changing the height here:

Code: [Select]

EngDrvOut(0xC0F13068, PACK32(width    - 1,  height +[0...11]));

[a1ex]

No, the idea is to feed larger images into the encoder (not necessarily with valid data - it will compress whatever it finds in memory), and keep height-1 for 0xC0F13068. Click on the links.

[andy kh]

#dfort  tried installing your latest crop rec4k for 70D. after installing  i turn On crop rec and mlv lite. restart my camera. no buttons would work after that. i tried reinstalling your build 2 times but no luck

[dfort]

turn On crop rec and mlv lite. restart my camera. no buttons would work after that.

Pull the card and battery, delete the ML/settings directory from the card and try again with only the silent module. Try shooting simple silent DNG's, both regular and lossless. Once we get that working we can move on to MLV. The crop_rec module isn't working AFAIK.


Sent from my iPad using Tapatalk

[andy kh]

Try shooting simple silent DNG's, both regular and lossless.

for lossless i think i have to activate the mlv lite. once i activate mlv lite all buttons dont response

[dfort]

for lossless i think i have to activate the mlv lite.

No. The lossless code is actually a part of the silent module so let's start with just a simple silent DNG.


Sent from my iPad using Tapatalk

[reddeercity]

Did some body say something about a "RABBIT"



from Digic 4 5d2 dm-log

Code: [Select]

F4D30> ImgPlayDrv:ffa3bf78:1a:02: DEC Jpeg Format:1 W:5616 H:3744
52BC5> ImgPlayDrv:ffa3be08:1a:02: DEC CalculateRabbitParameter 895
52BF2> ImgPlayDrv:ffa3bf04:1a:02: DEC CalculateRabbitParameterSeems to be doing pixel binding & line skipping ? more then likely see log info below

Code: [Select]

F4DB0> ImgPlayDrv:ffa3bf2c:1a:02: DEC XA:160 XB:16 XN:35 YA:8 YB:8 YN:467
F4DF2> ImgPlayDrv:ffa3ba30:1a:02: DEC SetResampleParametersForJuno 991from what I can tell this is the full operation with RABBIT haven't found the controlling resistor yet

Code: [Select]

ffa42720:18:03: SingleWorkWidth:2106, SingleWorkHeight:1404 (line:1575)
ff98a81c:19:03:  <<<<<< ImagePlayDriverTask ProcessID = 10
ff98a81c:19:03:  <<<<<< ImagePlayDriverTask ProcessID = 1
ff9886a8:19:03:  StartJpegDecoding 614
ff9886d4:19:01: [IMPD] add1:0x436C4088 sz:1228112
ff9886f0:19:01: [IMPD] BaseAdd:0x40D00000 BaseW:2106
ff988710:19:01: [IMPD] x:0 y:0 w:2106 h:1404
ff98872c:19:01: [IMPD] Pfil1:1 PreRes:1
ff98874c:19:01: [IMPD] xxa:8 xxb:3 xya:8 xyb:3
ffa3c1e4:1a:02: DEC RegisterCBROfCompleteDecodeJpeg 466
ffa3c214:1a:02: DEC RegisterCBROfStopDecodeJpeg 485
ffa3ae5c:1a:02: DEC SetParameterDecodeJpeg 148
ffa3b290:1a:02: DEC RequestDecodeJpeg(mode:1) 193
ffa3b2c0:1a:02: DEC add:0x436C4088 size:1228112
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
ffa3b324:1a:04: DEC RequestDecodeJpeg Before Lock
ffa3b340:1a:04: DEC RequestDecodeJpeg After Lock
ff9a47e0:00:02: [ENG] RegisterEDmacAbortCBR(11)
ff988408:19:03:  CompleteJpegAnalysing 428
ffa3b020:1a:02: DEC NotifyCompleteByAnalysis 640
ff9883a4:19:03:  StopEventCallBack 396
ffa3bf50:1a:02: DEC UpdateParameterDecodeJpeg 380
ffa3bf78:1a:02: DEC Jpeg Format:1 W:5616 H:3744
ffa3be08:1a:02: DEC CalculateRabbitParameter 895
ffa3bf04:1a:02: DEC CalculateRabbitParameter
ffa3bf2c:1a:02: DEC XA:160 XB:16 XN:35 YA:8 YB:8 YN:467
ffa3ba30:1a:02: DEC SetResampleParametersForJuno 991
ffa3ba60:1a:02: DEC XXA:8 XXB:3 YXA:8 YXB:3
ffa3bbc8:1a:02: DEC LES_H  XA:60 XB:6 XN:35 YA:8 YB:8 YN:467
ffa3bbf0:1a:02: DEC PFIL1  XA:60 XB:6 XN:35 YA:8 YB:8 YN:467
ffa3bc18:1a:02: DEC LES_V  XA:60 XB:6 XN:35 YA:3 YB:3 YN:467
ffa3bc40:1a:02: DEC P_RES  XA:60 XB:6 XN:35 YA:3 YB:3 YN:467
I don't know if D4's RABBIT is the same on D5 but I seems to be a encore/resizer

Code: [Select]

DEC SetResampleParametersForJuno 991Ok , more "code names"now there a JUNO 

I know this has been mention before that ml captures a bigger area of the sensor  then cr2's
canon code  is only decoding for this size "DEC Jpeg Format:1 W:5616 H:3744" and not 5632x3752
So I understand why a1ex is changing thing up a bit , at least for the 5d2 it seems as if it has a preset ,
I'll try and explain , as 5d2 doesn't really fit in to the resources[] unless I'm off in left field digic 4 has four preset engine resource
Which  makes senses -- PiP quick preview(320x240 I think) HQ preview window(3xcrop mode 1:1 2k etc. ..) full Livevew(photo mode H5616 H:3744 ) full Liveveiw (video mode w:2106 h:1404)
I could be wrong ......

Code: [Select]

02A15> LiveViewMg:ffa0708c:98:02: ResumeEngineResource
02A40> LiveViewMg:ffa06df8:98:02: ReleaseEngineResource Res:0, Free:ffffffff Count:4
02A86> LiveViewMg:ffa06ef4:98:02: ReleaseEngineResource GetResource Res:2, Free:fffffffd Count:3
02ACD> LiveViewMg:ffa06ef4:98:02: ReleaseEngineResource GetResource Res:4, Free:fffffff9 Count:2
02B0C> LiveViewMg:ffa06ef4:98:02: ReleaseEngineResource GetResource Res:1, Free:fffffff8 Count:1I wonder if the ml code was change to capture the same area as canon would there be the same problems ?
not sure where to look right now , just a thought ,
sorry for the long post

[andy kh]

lossless dng has something to do with black level. uploaded a file
https://files.fm/u/eu2tfak9

silent simple dng below
https://files.fm/u/jqr7fcna

[a1ex]

Looks slightly better than this (no more "diagonal" artifacts). However, I don't really know what to tweak for the black level fix. The processing path it uses is pretty different from all other D5 models (different enough to confuse me), but closer to 6D, so the relevant log diff is this.

Candidates: C0F37074 (try 0x180000), 0xC0F37290/94 (maybe 0? no idea)

How does the image look like if you try to review it (file_man + pic_view)?

The RD1 EDMAC also shows some differences in slice configuration, but that appears to be just a larger optical black area (though the difference is unusually high). Still, the slice size is no different from 6D, so this difference is likely not relevant.
6D: (4872, skip 4872) x 3707, 4872, skip -36121008,  (4872, skip 4872) x 3708
70D: (4872, skip 5012) x 3707, 4872, skip -36639988,  (4872, skip 5012) x 3708
6D: C0F06804: 5568 x 3723 (from raw_res.txt)
70D: C0F06804: 5648 x 3719

Uncompressed full-res silent DNG, please (ideally the full set of VRAM dumps).

For reference: 70D photo capture log from nikfreak.

[andy kh]

How does the image look like if you try to review it (file_man + pic_view)?

when i try to review in the camera "no image"

[saulbass]

New test 650D using dfort’s  crop_rec_4k.2018Mar04.650D104.

A significant advance in the loss less capabilities using this camera / build combination.

1080p & crop mode (1920x1080) tested so far.

14bit lossless, 12bit lossless, 11bit lossless - all working much better - the blocking cadence has gone - brilliant.

However there is still this behaviour that the brightness of the realtime live-view image decreases as I step from 14 > 12 > 11bit lossless. This doesn’t happen without lossless compression engaged in the mlv-lite menu. This characteristic also appears to be encoded into the compressed mlv recordings so they actually appear to get brighter and brighter as the compression ratio increases.
The other issue here is that the highlights become pinker and pinker and even using the highlight reconstruction of the mlv014 app it won’t go away.

Also
silent DNG compressed / uncompressed working - except there is a slight greenish cast to the compressed version. So something is going on with the lossless on the 650D.

14bit lossless - slight pinkish cast to highlights
12bit lossless - darker live view / brighter mlv / pinker highlights
11bit lossless - even darker live view / even brighter mlv / even pinker highlights

silent - faint green cast to lossless DNG

Will do some more tests later.