slashCAM Forum

R S K hat geschrieben: ↑Sa 22 Sep, 2018 19:44 Wenn schon, dann influenza.

- RK

Funless hat geschrieben: ↑Sa 22 Sep, 2018 19:48Ist aber kein Grippe Video.

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

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.

Frank Glencairn hat geschrieben: ↑Mo 24 Sep, 2018 12:07 Ich glaub nur, was ich in meinem Material sehe :-)

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.