Hier hat mal jemand mit Programmierkenntnissen ein reverse engineering von BRAW anhand des SDK vorgenommen:
What there is:
8x8 DCT (same as in jpeg-ext, prores, prores-raw and other codecs) - but in 12 bit precision
(with specific funny constants from one academic paper telling you how to do it super-fast)
The iDCT has separate shaders for full,half,quarter and eight of the resolution
The DCT compressed data is in a pseudo-YCbCr colour-space, so encoding a weighted RGB average, and differences towards R and B
Transfer curve that is partially linear and partially quadratic, with a threshold
Linearization LUT, with 32K points
There is a yet unknown feature that selects one of the 4 tables how to mix colors up (or that might be the quantization)
Decoding quality is either fast/rough or high-quality
Decoding to 4 buffer formats (RGBA, 32bit, 32bit planar, 16bit planar)
Decoding to 2 not yet understood formats with 1 and 4 elements (maybe yuv/rgb or rgb/raw)
Simple and straightforward processing (blacklevel, gain, linearization, demosaic, saturation, colorspace conversion)
What there is not:
Wavelets (dirac-pro, TICO/jpeg-xs)
Encoding (at least no API exists for inserting raw data and creating files)
No advanced de-mosaicing that would trace contours or do other funny stuff
Looking into a sample 4K6 file:
it is based on ISO MEDIA format (Quicktime MOV), had no trouble to parse it through by my MP4 library
it is clearly an i-frame file and it might be a constant bit-rate one I got, since the frame sizes were almost same
there is some acquisition metadata about lens, shutter, iso per frame, these take few 64byte chunks of each frame, in custom QT atom format (256 on my sample)
then goes the binary header, with information about the resolution and slicing the file
and the slice index and those unknown mixing flags per slice
The 4k6 file seems to be partitioned into 240 slices, that are in 8x30 matrix. 8 wide shall correspond to the camera capabilities seen earlier with the JPEG extended profile in the 3:1 and 4:1 codecs, yet there the slices spanned over the whole (or half) the height of the picture. Here they span just 88 pixels tall. More slices means more potential to get things decoded in parallel (either on cpu or gpu).
I have not found yet a way to decode the slice bitstream, to tell whether it is just a JPEG, or it has subsections that lead to even faster /progressive/ decoding when processed partially.
My opinion on some choices:
Use of ISO MEDIA is fine and getting a new extension is good to avoid people telling "hey, i cant open this MP4"
(which was and is a trouble with the nonstandard coding in the 3:1/4:1 formats)
Including the shady shader source code - this makes the library future-hardware proof. When you get a new GPU architecture, it will run optimally.
e.g. Canon in their SDK pre-compiled these functions for the current gpu architectures, which means it might not even run on something newer, or will run sub-optimally.
Instead of obfuscation, they just might use a compression/encryption and I would probably never find these shaders. Not on first sight.
The partial de-mosaic may just mean:
- take this RGGB raw data, create R, (Gr+Gb)/2, B, convert it to pseudoYUV444, encode with JPEG(444). And the little of Gb-Gr residue is encoded extra
- for fast decoding at 1/2 of resolution just decompress the JPEG and convert to final color space, no de-mosaic, look ma - what a speed!
- for high quality decoding, get the Gr/Gb difference back, compose the original RGGB bayer data and do a full resolution de-mosaic
diese ersten erkenntnise über die tatsächliche sind natürlich wirklich sehr interessant.
auf so einer basis kann man wesentlich vernünftiger über die tatsächlichen vorzüge und grenzen des formats diskutieren.
schade, dass es nicht von haus aus in einer solchen weise dokumentiert wurde. gibt ja offenbar wirklich nichts aufregendes daran, dass nicht auch in vielen anderen formaten und anwendungen ständig sehr ähnlich abgewickelt wird.
Frank Glencairn hat geschrieben: ↑Mo 24 Sep, 2018 11:53
Die tatsächlichen Vorzüge und Grenzen des Formats erkundet man am besten, indem man es ausprobiert.
da hast recht -- nur nennt sich das halt in jenen kreisen, die an entsprechenden technischen einsichten und fakten interessiert sind, gleich einmal: reverse engineering. ;)
das kann bei völlig ungenügender dokumentation durch den hersteller oft tatsächlich weit mehr bringen, als alles zu glauben, was einem diverse werbefritzen und technisch weniger bewanderte fanboys einzureden versuchen.
Frank Glencairn hat geschrieben: ↑Mo 24 Sep, 2018 12:07
Ich glaub nur, was ich in meinem Material sehe :-)
naja -- mein alter hoch geschätzter logik-professor hat seinen studenten den sinn entsprechender bemühunge immer mit dem sehr einfachen beispielsatz: "wenn es regnet, ist die straße nass" zu veranschaulichen versucht, der ja bekanntlich leider auch den umkehrschluss nicht zulässt, dass es geregnet haben muss, wenn uns die straße nass erscheint...
aber natürlich macht's sinn, dass man einfach auch seinen augen traut bzw. die dinge auf ihre praktische tauglichkeit hin überprüft, nur erübigt sich dadurch noch lange nicht die sinnhaftigkeit, technische lösungen auch aus anderen blickwinkeln zu betrachten, sie zu verstehen/hinterfragen und auch in dieser hinsicht mit anderen lösungen zu vergleichen.
Zuletzt geändert von mash_gh4 am Mo 24 Sep, 2018 12:35, insgesamt 1-mal geändert.
Frank Glencairn hat geschrieben: ↑Mo 24 Sep, 2018 11:53
Die tatsächlichen Vorzüge und Grenzen des Formats erkundet man am besten, indem man es ausprobiert.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
