Author Topic: ProcessTwoInTwoOutLosslessPath (Read 233360 times)

goldenchild9to5 · « **Reply #25 on:** December 23, 2016, 04:39:30 PM »

@Danne Were you able to shoot continuously? if not how many seconds or frames were you able to capture?

Danne · « **Reply #26 on:** December 23, 2016, 04:59:55 PM »

It,s coded into silent dng module for now as a1ex is stating. Only shot a few stills. Files about half size from a regular still dng file.

goldenchild9to5 · « **Reply #27 on:** December 23, 2016, 06:49:03 PM »

@Danne That's awesome.. do you know the Bit depth 10Bit, 12, or 14. When it's fully implemented it's going to be awesome.

ricbi1 · « **Reply #28 on:** December 23, 2016, 08:11:40 PM »

Unbelievable! You guys are squeezing every inch of performance out of these cameras. Thanks all!

Danne · « **Reply #29 on:** December 23, 2016, 08:16:56 PM »

@goldenchild9to5

Quote

That's awesome.. do you know the Bit depth 10Bit, 12, or 14

Nice and beefy 14-bit lossless dng files.

ricbi1 · « **Reply #30 on:** December 23, 2016, 08:28:05 PM »

Donwloaded Dec 21 build to test lossless DNG on 5d3, but I can't figure out the workflow to make it work. Anyone has any hints?

goldenchild9to5 · « **Reply #31 on:** December 23, 2016, 09:26:10 PM »

@Danne "Nice and Beefy 14 Bit" lol.. but WOW.. + 1/2 the file size that's just incredible. Magic Lantern is making it harder and harder to wanna buy another Camera after the 5D3

Markus · « **Reply #32 on:** December 23, 2016, 11:02:39 PM »

Crazy stuff! Freaking awsome!

RenatoPhoto · « **Reply #33 on:** December 24, 2016, 03:49:06 PM »

Ohh my! This is great.. A1lex said the processing time for a dng was 23 ms.. So at 30 fps each dng would require 33ms.. This means the hardware may be able to compress the dng during video!

Teamsleepkid · « **Reply #34 on:** December 24, 2016, 08:44:18 PM »

sounds amazing. think this will eventually work at 24fps? would we be able to still have crop mode for less aliasing? could we use more of the sensor in crop mode and get higher resolutions? sorry just wondering.. merry christmas

DavidSh · « **Reply #35 on:** December 24, 2016, 10:35:16 PM »

Wow! you guys...
This is really something.

goldenchild9to5 · « **Reply #36 on:** December 25, 2016, 02:00:28 AM »

This DNG development got me too excited. Happy Holidays everybody..

togg · « **Reply #37 on:** December 25, 2016, 10:15:10 PM »

Quote

My 5D mark III just gave birth to some lossless DNG files. Here,s a compiled version for testing from a1ex compressed_raw branch. Awesome stuff.

5D mark III
https://bitbucket.org/Dannephoto/magic-lantern/downloads/magiclantern-Nightly.2016Dec21.5D3113_lossless_DNG.zip

Two lossless DNG files
https://bitbucket.org/Dannephoto/magic-lantern/downloads/65260001.DNG
https://bitbucket.org/Dannephoto/magic-lantern/downloads/65260002.DNG

Wait a moment here, does all this means that MAYBE we can get this beautiful cat (nice pic!) on full hd raw video with half the GB/speed needed?
Same process for the 5DII ? (cross finger...) edit: I now understand that probably the CPU isn't up to the task... I guess I'll buy a 5DIII if things work out

This is incredible!

g3gg0 · « **Reply #38 on:** December 25, 2016, 10:28:49 PM »

-> MAYBE on april 1st

g3gg0 · « **Reply #39 on:** December 27, 2016, 12:05:30 PM »

updated the register map.

houston, it really seems to run its custom firmware. couldnt identify the instruction set type yet.

___
The JPCore seems to an extra processor based engine that exists at three base addresses with equivalent layouts. JPCORE is e.g. used in YUV2JPEG while JP57 in RAW2JPEG. Those seem both to support lossless compression. It also handles MPEG compression, only seen in JP62 yet.

It uses its own firmware in main memory, the address (!) where it was copied into RAM is written to +0x928 before init. Its size is approx 16-18KiB, depending on its exact instance. The address must be aligned to 0x80 bytes.

There is also a buffer address written to 0x92C which is 0x5000 bytes big and starts with 0x500000 and the character sequence "xbuf". Seems not to be used in main firmware, perhaps it is the JPCORE's internal scratchpad memory?

g3gg0 · « **Reply #40 on:** December 27, 2016, 12:24:42 PM »

i found the "xbuf" reference in the firmware.
tried to understand which kind of CPU we have by looking how the string is used.

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000017F0  EC 20 93 4F 43 02 4C 86 BA 66 3E 75 3E 62 3E 78  ì “OC.L†ºf>u>b>x
00001800  6A 12 8B 1F 43 02 4C 81 6A 12 FA 02 52 17 AE 51  j.‹.C.L.j.ú.R.®Q
00001810  C6 18 97 41 41 7D BA 78 3E 64 3E 69 3E 78 6A 12  Æ.—AA}ºx>d>i>xj.
00001820  8B 1F 41 79 AE 13 82 11 82 11 EC 10 82 1F 6E 11  ‹.Ay®.‚.‚.ì.‚.n.

i don't know which kind of CPU it is...

a few bytes later it also loads XIDX

a1ex · « **Reply #41 on:** December 27, 2016, 03:05:01 PM »

Very interesting.

Some excerpts from QEMU logs, showing where these memory areas are initialized (5D3 1.1.3):

Code: [Select]

memcpy(0x40649080, 0xff9a0580, 18560) from ff570270
...
[JPCORE] at ShootCa:FF28D28C:00001D1C [0xC0E00928] <- 0x649080  : ???
[JPCORE] at ShootCa:FF28D28C:00001D1C [0xC0E0092C] <- 0x64D9BC  : ???

Code: [Select]

memcpy(0x40653080, 0xff9a4e00, 16000) from ff5702e8
...
[JP57] at ShootCapt:FF28DDA4:00001D1C [0xC0E20928] <- 0x652F80  : ???
[JP57] at ShootCapt:FF28DDA4:00001D1C [0xC0E2092C] <- 0x656EF0  : ???

goldenchild9to5 · « **Reply #42 on:** December 27, 2016, 07:58:54 PM »

@a1ex @g3gg0 Man you guy's are genius, don't know how you do it. Those codes are like Matrix codes to me.

RenatoPhoto · « **Reply #43 on:** December 27, 2016, 09:34:31 PM »

The Magic at Magic Lantern!

a1ex · « **Reply #44 on:** December 28, 2016, 02:49:33 PM »

Please find a small script that extracts all JPCORE instances from a ROM dump:

Code: [Select]

import os, sys
from struct import unpack

def getLongLE(d, a):
   return unpack('<L',(d)[a:a+4])[0]

def getShortBE(d, a):
   return unpack('>H',(d)[a:a+2])[0]

d = open(sys.argv[1]).read()

blob_id = 0
for a in range(0, len(d) & ~3, 4):
    v = getLongLE(d, a)
    if v == 0xF4B2:
        v2 = getLongLE(d, a+4)
        if v2 == 0x7E4C:
            sz = getShortBE(d, a + 0x84) * 2
            print hex(a), hex(sz)
            blob_id += 1
            blob = d[a : a+sz]
            fout = os.path.join(os.path.dirname(sys.argv[1]), "JPCORE%d.BIN" % blob_id)
            print " -> %s" % fout
            out = open(fout, "w")
            out.write(blob)
            out.close()
        else:
            print "false alarm at", hex(a), hex(v2)

Very old models (such as 5D and 400D) have some strings in the JPCORE firmware. For example, on 400D:

Code: [Select]

diagnostics() rev-1.0 2001/07/17 author  Satoshi Naito CM51 
launcher.s rev-1.0 2001/07/17 author Satoshi Naito
bypass() rev-1.0 author S.Naito 2001/07/17 
encdec_jpeg rev2.11 2004/02/12 Yukio Chiba & Satoshi Naito 
predecode_mpeg2() rev-0.10 2001/4/23 author  Akihiro Uehara BH51
decode_mpeg1() rev-0.18 2001/07/09 author  Akihiro Uehara BH51
decode_mpeg2() rev-0.18 2001/07/09 author  Akihiro Uehara BH51
encode_mpeg1() rev-0.20 2001/5/13 author  Satoshi Naito and Akihiro Uehara BH51 
encode_mpeg2() rev-0.19 2002/5/13 author  Satoshi Naito and Akihiro Uehara BH51

The JPCORE firmware is also present in PowerShots, and appears to be shared across many cameras. For example, 60D and A1100 (EOS and PowerShot, both DIGIC 4) contain identical JPCORE firmwares. I've tried to group both DSLR and PowerShot models that use identical JPCORE blobs:

Code: [Select]

(D2) 5D IXUS50 IXUS700 S2IS
(D2) 30D 400D IXUS30 IXUS40
(D3) 1000D 40D 450D A470 A580 A590 A650 A720 G9 IXUS80 IXUS82 IXUS85 IXUS860 IXUS90 IXUS960 IXUS970 SX100IS
(D4) 1100D 1200D 1300D 500D 50D 550D 5D2 600D 60D 7D A1100 A1100 A1200 A2100 A2200 A3200 A3300 D10 G10 G11 G12 IXUS1100 IXUS115 IXUS117 IXUS220 IXUS230 IXUS310 IXUS1000 IXUS100 IXUS105 IXUS110 IXUS120 IXUS130 IXUS200 IXUS210 IXUS300 IXUS870 IXUS95 IXUS980 IXUS990 S90 S95 SX10 SX1 SX120 SX130 SX150 SX200 SX200IS SX20 SX210IS SX220 SX220HS SX230 SX30
(D5) 100D 5D3 650D 6D 70D EOSM G1X S100 SX40
(D5) 700D
(D6) 5D4 750D 760D 7D2M 7D2S 80D EOSM10 EOSM3 G16 G3X G5X G7X IXUS145 IXUS150 IXUS155 IXUS157 IXUS160 IXUS170 IXUS175 IXUS180 IXUS265 IXUS275 S120 SX270 SX280 SX400 SX410IS SX520 SX530 SX600 SX60 SX610 SX700 SX710 SX720

(D2) A410 A420 A430 A450 A460 A530 A540 A550 A610 A620 A700 IXUS55 IXUS60 IXUS65 IXUS750 IXUS800 IXUSIZOOM IXUSW S3IS S80
(D2) A630 A640 A710
(D3) A1000 A2000 A3000 A3100 A3150 A480 A490 A495 A800 E1 SX110
(D3) A560 A570 G7 IXUS70 IXUS75 IXUS850 IXUS900 IXUS950 IXUSI7ZOOM S5IS TX1
(D4) A1300 A1400 A2300 A2400 A2500 A2600 A3400 A3500 A4000 A810 D20 D30 G15 IXUS125 IXUS132 IXUS140 IXUS240 IXUS255 IXUS500 IXUS510 N N-FB S110 SX160 SX170 SX240 SX260 SX260HS SX500 SX50 SX510

Some interesting ideas about how to figure out the meaning of these codes:
https://recon.cx/2012/schedule/attachments/40_Chernov-Troshina.pdf

Frequency of 16-bit codes, 16-bit alignment:

Code: [Select]

Code         5D3JP  5D3JP57    60DJP    80DJP   400DJP    Total
    0000:      153      250      151      228      314     1096 
    f37e:      196      172      196      196      289     1049 
    1762:      168      140      168      172      172      820 
    02fa:      166      144      166      166      157      799 
    7f1a:       97      140       97       97      186      617 
    dfae:      109      108      109      109      121      556 
    f76e:       82       70       82       82      204      520 
    2762:       99       84       99       99      105      486 
    41e8:       97       77       97       97       93      461 
    04ba:       66       83       66       66      176      457

Frequency of 32-bit codes, 16-bit alignment:

Code: [Select]

Code         5D3JP  5D3JP57    60DJP    80DJP   400DJP    Total
00000000:      103      196      103      173      254      829 
02faf37e:      102       90      102       98       96      488 
20202020:      142        0      142      142        0      426 
f37e00ec:       76       36       76       76       73      337 
f37e02ec:       49       58       49       49       48      253 
11cb1762:       45       39       45       45       45      219 
176200e8:       43       39       43       43       43      211 
304a1fae:        0        0        0        0      178      178 
276241e8:       32       27       32       32       28      151 
003e04ba:       24       21       24       24       44      137

Frequency of 32-bit codes, 32-bit alignment:

Code: [Select]

Code         5D3JP  5D3JP57    60DJP    80DJP   400DJP    Total
00000000:       52       99       52       90      131      424 
02faf37e:       45       51       45       44       46      231 
20202020:       72        0       72       72        0      216 
f37e00ec:       33       16       33       35       34      151 
f37e02ec:       27       25       27       27       23      129 
11cb1762:       23       21       23       24       23      114 
176200e8:       22       21       22       21       24      110 
304a1fae:        0        0        0        0       76       76 
f76a7f1a:       13       10       13       11       26       73 
003e04ba:       13       11       13       13       22       72

Frequency of 64-bit codes, 32-bit alignment:

Code: [Select]

Code                 5D3JP  5D3JP57    60DJP    80DJP   400DJP    Total
0000000000000000:       43       88       43       79      118      371 
2020202020202020:       67        0       67       67        0      201 
f76a7f1a003e04ba:       10        4       10        9       12       45 
5d5202faf37e02ec:       13        0       13       13        0       39 
27660f1af162121a:        5        4        5        7        6       27 
815202faf37e02ec:        9        0        9        9        0       27 
f162121a21c62762:        5        4        5        7        6       27 
0aeb008a10fc1fb2:        6        2        6        6        6       26 
41e8004a27660f1a:        5        4        5        6        6       26 
10fc1fb2017e067e:        6        2        6        6        6       26

a1ex · « **Reply #45 on:** December 28, 2016, 04:30:15 PM »

Quote from: goldenchild9to5 on December 27, 2016, 07:58:54 PM

Those codes are like Matrix codes to me.

Good idea. Here's the similarity matrix (Levenshtein ratio) between the JPCORE firmware groups:

Code: [Select]

         5D   30D 1000D  A560 A1000  A410  A630 1100D A1300  100D  700D   5D4
   5D 1.000 0.962 0.593 0.594 0.587 0.696 0.692 0.669 0.669 0.669 0.669 0.667
  30D 0.962 1.000 0.582 0.583 0.576 0.679 0.676 0.658 0.658 0.658 0.658 0.655
1000D 0.593 0.582 1.000 0.987 0.986 0.815 0.815 0.804 0.804 0.804 0.804 0.803
 A560 0.594 0.583 0.987 1.000 0.973 0.816 0.814 0.804 0.804 0.804 0.804 0.803
A1000 0.587 0.576 0.986 0.973 1.000 0.806 0.806 0.814 0.814 0.814 0.813 0.812
 A410 0.696 0.679 0.815 0.816 0.806 1.000 0.994 0.963 0.962 0.963 0.962 0.958
 A630 0.692 0.676 0.815 0.814 0.806 0.994 1.000 0.966 0.966 0.966 0.966 0.958
1100D 0.669 0.658 0.804 0.804 0.814 0.963 0.966 1.000 0.999 1.000 0.999 0.984
A1300 0.669 0.658 0.804 0.804 0.814 0.962 0.966 0.999 1.000 1.000 0.999 0.984
 100D 0.669 0.658 0.804 0.804 0.814 0.963 0.966 1.000 1.000 1.000 1.000 0.984
 700D 0.669 0.658 0.804 0.804 0.813 0.962 0.966 0.999 0.999 1.000 1.000 0.983
  5D4 0.667 0.655 0.803 0.803 0.812 0.958 0.958 0.984 0.984 0.984 0.983 1.000

g3gg0 · « **Reply #46 on:** December 28, 2016, 05:03:17 PM »

cool way of analyzing

DeafEyeJedi · « **Reply #47 on:** December 28, 2016, 07:39:05 PM »

Incredible work @a1ex!

Ant123 · « **Reply #48 on:** December 28, 2016, 07:50:58 PM »

a1ex
Definitely, that guy should know something

Look at his patents...

g3gg0 · « **Reply #49 on:** December 28, 2016, 08:50:53 PM »

yeah, for sure he knows a lot.
but i also bet he wont tell anything

News:

Author Topic: ProcessTwoInTwoOutLosslessPath (Read 233360 times)