#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

Hi all

I'm good thank you :)

great! we have been able to iron out the last hardware kinks (or so it seems :)

That great - congratulations!

thanks!

I apologise if this has all been published on the blog - I just drop by IRC from time to time xD

for those interested in digital image filters, raw raw recording via hdmi, and pixel peeping, you may want to check this: https://wiki.apertus.org/index.php/Reversing_digital_filters

alexML: Sampling looks like.

alexML: What filter do the recorders use? I'm guessing not a cubic.

(Going to guess some sort of tent or something?)

(still learning how to do it, that's why I experimented with simpler cases)

alexML: Bitwise, the YCbCr must be compliant, and there is a bitwise exact test IIRC.

alexML: So it is entirely plausible that the bulk of the image result is largely a byproduct of the sampling on the YCbCr elements, in particular, the Cb Cr. A LERP will most greatly augment the blocking for example.

alexML: Are you triple checking the broadcast range flags?

and the images alexML uses are decoded from that format (probably via ffmpeg)

codec is prores

could as well be, IIRC max was doing that ...

(that was on a resulution chart)

either way, the Shogun might be assuming interlaced content

ah ok

nope

the Shogun's blue channel looks especially nasty on the hair :|

0-255 vs 16-235 issue?

what conversions happened inside the shogun and on decoding the prores stream is unknown

which is standard broadcast levels

alexML: The moment you pass through FFMPEG all bets are off methinks.

define "re-encode"

The bitstreams should be identical.

Bertl: Well that is part of what intracube hints at above.

There's going to be three areas to investigate:

That is, if you feed it RGB, the resultant values must be 16-235 for 8 bit Y, and 16-240 for CbCr.

what bitsream?

2) If fed YCbCr, then in theory I'd expect no adjustment for the scaling otherwise we are in double-up land, but we can also expect that we'd need to test a round trip noop.

fed along the stream

a round trip if fed YCbCr, should be a noop assuming that A) the sampling is identical (eg 444 in, 444 recorded, 444 out, or 422 in, 422 recorded, 422 out, etc.)

the shogun does some magic to it, and records it as _prores_ file

B) that the dimensions are identical (Full Y, fully Cb (half res x at 422 of course), full Cr (half res x at 422 etc.))

Again, the bitstream would still be YCbCr

(as opposed to the plethora of other compressions)

the problem is, the whole process is all over the map currently with the testing, so the evaluation is likely way off.

everything inbetween is a black box

That is, stay in the YCbCr domain and avoid the RGB

easy to say, but we don't have YCbCr out yet

So you are getting RGB?

then the inversion is equally trivial assuming you can assert the coefficients

(which are likely 709 weights)

prores file decoded to RGB 444

no explicit conversion on our side

and back to RGB 8 bit yes?

I don't know

we send 8-bit RGB and we get back 8-bit RGB with some magic applied

it's a black box from the moment the RGB 444 is received to the moment the RGB 444 comes out of the prores decoder

Is there a way we can get or set YCbCr and skip an RGB hop?

no issue there.

So if it delivers ProRes, we aren't doing RGB -> YCbCr -> RGB

That's trivial.

who says that?

Because I'd be 90% certain it is YCbCr in the ProRes. :)

note that I agree that it probably does

Dump the raw YCbCr and that will be bitwise exact

Then you can manually perform the transform back

ProRes quality levels _do_ include compression though, so a LERP on the Cb/Cr will show you exactly where that is happening.

(if 422, obviously you have full frames on 444)

because the shogun does not do lossless recording AFAIC

So the "black box" portion is strictly on the RGB to YCbCr transform

In particular, the compression applied to the channels.

bitwise exact = identical

As in

you obviously mean something else here

(three transformations)

that is the first RGB to YCbCr

that would imply that we could extract the YCbCr from the prores _without_ decoding it

FFMPEG decodes the raw bitstream

without going to RGB

fine, but still there is a second "black box" the decoder

which is known in the ffmpeg case

The compression I believe is also reasonably stable

because Apple mandates it based on the four types of ProRes.

concrete.

should full range RGB be sent to the shogun though?

a good question, which should be answered by one of the artificial test images

PC land looks to be 0-255. hardware bluray players and other media devices 16-235

Bertl: Easy to test on the YCbCr.

(and even then, there are _two_ variants. Technically a 'full range' according to specification must skip values 0 and 255, but Canon's for example, violate this and actually record data on those two values)

intracube: Yes.

alexML: do we have a tif for one of the color bar test images?

Bertl: Don't need it.

troy_s: but what it *records* isn't necessarily the same as the input formats it supports

intracube: It _is_ recording YCbCr, with a less than 10% chance it is recording an RGB variant of ProRes (not even remembering if that is viable in the spec)

troy_s: I'm not disputing that :)

intracube: So the moment it dumps to YCbCr, that transform is over.

intracube: We can actually touch those bits.

That's nothing more than a RGB to YCbCr

hey troy_s

hence 0-255

slikdigit: Slick shit

slikdigit: Try irccloud.

is that one?

slikdigit: Yep.

intracube: I'd be utterly shocked if the Shogun had a toggle to accept scaled RGB. There is never really a legitimate reason to ever use scaled RGB.

slikdigit: Tried it.

:)

Bertl: these are the tif's we have: http://files.apertus.org/AXIOM-Beta/snapshots/BetaRecTest/

troy_s: ok. I don't know nearly enough about HDMI/SDI. I'm an analogue dinosaur :P

alexML: If you use that command and store them as greyscale, you can sample the resultant 8 bit planes and figure out immediately if it is broadcast scaled off of a test image.

intracube: it can and it should be announced in the metaframes

Depends I suppose. I have seen the toggle on _encoding_ devices, so that an imager can control the conversion right up to the point of the YCbCr (you eliminate one more bit of guesswork)

A simple flag

but that is also crap now because of Canon etc and the DSLRs

alas.

but scaling isn't a problem for me

scaling and offsets are pretty easy to find and reverse, but the other black magic... not so easy

alexML: ALL of the artifacts are part of scaling

alexML: The difference between a LERP to a cubic for example, is _huge_, and will have a _huge_ impact on the result. Doubly so if we consider that the Y is vastly more relevant for some types of visual things, and other times chroma is.

troy_s: just a sec

troy_s: got some detailed info from ffmpeg

[auto-inserted scaler 0 @ 0x42d4600] w:iw h:ih flags:'0x4' interl:0

[auto-inserted scaler 0 @ 0x42d4600] w:1920 h:1080 fmt:yuv422p10le sar:0/1 -> w:1920 h:1080 fmt:rgb48be sar:0/1 flags:0x4

so I guess I should get rid of those extra filters somehow

I'm not 100% sure these were the settings used in the TIF tests from the wiki

Bertl: My goof.

Imagemagick can peel that apart into planes into images.

just curious, but what is the main lens type/brand that will be supported?

but I was unaware of any actual work going on here

@Bertl

adapters for nikon and other lens systems are readily available

the Early Betas won't support electrically controlled lens systems though

ok. that makes sense. thank you!