#apertus IRC Channel Logs

How many people paid their 1k€ vouchers

good morning

hi John_K`

intermittent connection between the pin headers on the main board and the receptacle on the power board

pusle: that would require SATA controller IP in the FPGA

"An Open-Source SATA Core for Virtex-4 FPGAs" http://www.ecs.umass.edu/ece/tessier/gorman-fpt13.pdf

ok only the new Zynq UltraScale+ MPSoC has Sata (3.1)

it's also not shipping yet

pusle: that's the reason why we started a FOSS/OH project in the first place ... somebody interested (like you maybe) can and will extend the AXIOM cameras with new interfaces

Bertl: how do I program the CPLD with the PICs?

John_K`: PIC is working as expected and has been programmed?

the right IDs came up and then I programmed both

sounds great, thanks

Bertl: which is the input file for ab1? (I only downloaded the ones for o, p and d)

also, Max promised me the prores data, just not today

it is implemented in the mimg test image suite

you can also generate it and dump the memory of course

ah, yes, the Beta is not available

do you remember if you used any gamma correction during the test? (it looks like around 0.8 to me)

with this value, input values (after gamma) under 16 and over 235 were indeed clipped, and then the range was stretched back to 0-255 when decoding

Bertl: no PMOD module

alexML: might have been with a gamma set, don't know

and you do see missing values

recorded: http://files.apertus.org/AXIOM-Beta/snapshots/reversing-digital-filters/hdmitest/red-hdmi-from-tif.jpg

anyway, let me upload the python scripts

you managed to build the lattice code yourself?

haven't installed their tools yet

okay, you can use a prebuilt one, but it is probably better to get that part working as well

of course

and we'd like to make use of global shutter

I see one pair has termination, is the other pair terminated on the uZed?

there is termination for both

it's just not populated in our Early Betas at the moment

scripts uploaded?

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/pic_jtag_id.py

which bitstream should be loaded on FPGA for that?

00000001001010111001000001000011

ah it might be the old one

usercode 00000000 [00000000000000000000000000000000]

that looks way better

in this case you need to rebuild the bitstream for the lattice anyway

ah ok

I'll grab their tools now

there were quite a few departures from your BOM in the one linked from the wiki apparently

downloading lattice tools now

alexML: That is the only way to properly analyse.

It isn't a clip either, it is a uniform scale.

There is a very simple matrix plus offset via OCIO to do the conversion at 32 bits per channel float.

alexML: Ping me and I can help you with the FFMPEG command to dump the raw YCbCr planes.

People got stuff to do!!!

"<Bertl> alexML, intracube: after I downloaded the entire RecTest image collection, the ab1.tif seems to be a good candidate for analysis"

yep, might be related to the encoding though

(we found at least two bugs in the experimental raw encodings)

Use a LERP to sample the channel dimensions, and simply look at what was in the bitstream. It is hokey voodoo if you don't.

The RGB <-> YCbCr _twice_ is madness.

Bertl: You are going from RGB to YCbCr then? Or letting the Atmos handle that?

intracube: Likely _not_ the Shogun. Decent estimate it isn't.

intracube: what would be a "known source"?

Easiest test would be to do the following:

troy_s: if you're feeding the Shogun an RGB signal, by definition it has to convert to YCbCr and scale down the chroma channels, right?

A) Send the RGB to the unit and pull the YCbCr raw planes from the resultant file.

B) Manually perform an RGB to YCbCr transform via OCIO and feed that to FFMPEG using the same encoding level. Compare.

CbCr are not at full res

Wait, are you telling me?

:P

The ProRes encodes aren't nearly as all-over-the-map either, so once the ProRes level is deduced (hq?)

As a final notch of testing, a decode can be done using straight LERP on the Cb/Cr and an OCIO transform at 32 bit float per channel. (It is literally a single spimtx transform)

Bertl: Bitwise exact being the bitstream.

As in _all_ decoders will be looking at that precise exact series of bits.

Whereas likewise, there is a zero chance that _any_ decoder will deliver RGB values at that same level.

All that really matters is that the YCbCr matches or isn't doing anything too funk.

RGB-444-full -> [backbox aka. shogun] -> RGB-444-full

the blackbox further can be broken down into:

[ProRes Encoder (shogun)] -> [ProRes Decoder (ffmpeg, adobe)]

That is my point!

No speculation.

The "decode" isn't nearly as complex as it seems.

the ProRes Encoding part (shogun) consists of a) Color Space Conversion, b) Color Space Decimation, c) Lossy Compression and d) Actual Encoding

The decimation is quantization only.

nope

IIRC, the shogun record YCbCr 422

*records

that's what I'm trying to say, there is nothing "bitwise identical" anywhere

You are misreading what I was saying

(Been over this with MN a few times, and I am reasonably faithful in his judgement)

God.

Based on an RGB to YCbCr to RGB transform series

troy_s: I found the ffmpeg commands, now waiting for the movie; until then, I just analyzed what I had

We can be absolutely _certain_ that if you and I are using that same exact source, we are looking at precisely the same values.

okay, let's go that route for entertainment

we produce an RGB 444 full test image

we record it to ProRes

now what?

How?

alexML: Great. It is relatively easy.

a ProRes recording

If we instead do something foolish and decode that back to RGB

There is exactly zero chance we will be looking at the same values.

troy_s is right; instead of one black box (the ProRes), we had 3

alexML: Exsctly!

alexML: Worse, that last one is a massive black box of complexity that I can't begin to even say.

Bertl: It will be.

I can say beyond certaibty

but how does that help us?

Yeah that is how flakey the decoding landscape is.

(GPU frequently gets handed the YCbCr streams and they will take alternate code paths (frequently wrong) compared to the software implementation (frequently wrong)

so is encoding :)

There are certainly variations etc, but the flags in the file etc. or the raw bitstream can't lie; it is what it is.

Yes. I understand your concern. Totally.

But where we _were_ was looking at RGB, which is plain and simple a fool's errand.

I know.

and that is not even by changing the quality

and there's scaling from 16-235 to 0-255 as well (most likely on the last black box)

That is _mandatory_ to call yourself "709" or "240m" etc.

It should be 16-235 for Y', and 16-240 Cb' Cr'.

so probably the clipping is applied after RGB->YCbCr

(in my simulation, I applied it on RGB)

troy_s: RGB values below 16 and above 235 got clipped

Nope.

Bad encode.

;)

how do you pass flags on the Shogun?

Don't know.

yes, and if it's not, what happens?

If RGB, it _should not_ be mapping 240ish to 240ish. That is wrong.

Nope.

right

Proper encode maps 0-255 to the YCbCr broadcast scaled values

That issue is _extremely_ common.

Remember too that the same mangling can happen on decode.

A proper and correct round trip should deliver 1:1 on the 0 and 255 values

alexML: So factor in this:

B) Proper specification based "full range" (1-254 IIRC)

E) Coefficient mangling (601 vs 709)

Now do that mangling once on encode

Oh

Factor in exactly TWO code paths

And one for GPU and the application's mangling smashed into the video card acceleration

Now tell me how many variations we have.

It is a total mess.

Finally, note that the quantization reference space matters; many decoders are doing it at that buffer depth, which adds to poor decodes.

off for now ... bbl

no, waiting for the original movie file (and even then, I can get rid of only one black box - the one at the end of the chain)

and the RGB -> YCbCr that happen on the recorder, for which I think I've identified the clipping behavior (which you say it shouldn't be done)

so, until then, I'm just looking at all those black boxes together

alexML: great idea

the movie file from the recorder

alexML: If the original Shogun was fed a codec of sorts, then that's another issue entirely. That is where you'd see the botched scaling mangling appearing. If it was fed literal RGB values, then there would be a setting somewhere on the encoder to honor the fully range RGB (which it should by default, as there is technically no real way to scale RGB ready

Ah.

converted with some Adobe software, I think

alexML: So here's a hypothesis then...

BUT...

I've identified a gamma correction applied to those dumps before feeding

most likely Bertl forgot to tell me about it

(hate the term gamma. awful)

Can't see any discussions of gamma.

Technically, I'd not do any conversions on anything as RGB in is RGB out (minus the massive discussion we had)

That is, no matter what the coefficients etc., as long as the encode is done "correctly" and the decode is done "correctly" (again all caveats about quantization, compression, etc. aside) the RGB values are 1:1 (again, please please please do not mistake that for meaning 'lossless' etc.)

Od.

(I'm just interpreting the files I've already got)

What are you considering it "should be"?

maybe it was unintentional, idk

a bit too much for a coincidence :P

I am not certain, but I don't believe the broadcast scale would end up uniform across the 235 range, but I'd need to check the math.

(Perhaps not because it _is_ the luminance weights after all, and the 235 broadcast scale is on the Y)

alexML: If that is the case, I'd not read too much into it because that could easily be a botched decode.

for decoding, we compared both Adobe and ffmpeg on a different test file (a resolution chart) and found only minor differences (not obvious when watching the images)

and I've also fed the (gamma-corrected and 16-235-corrected) input data to ffmpeg prores, and the artifacts are much less obvious

even with prores proxy (strongest compression), the artifacts aren't that bad as on the hdmi recorder

You shouldn't feed anything "corrected" to FFMPEG or an encoder.

well, I believe that was the closest approximation of the data sent to the HDMI recorder

That's part of the problem then.

The encoder should understand that what you are feeding it is RGB, and in particular, sRGB.

If the encoder is only grabbing a limited "scaled" range, then something is _totally_ whack.

If it is fed along an HDMI port, FSM knows it is going to be Mr. Toad's Wild Ride.

comradek

Email sebastian.

yes email me :)

thanks, writing another one now :)

perfect

nah

Yah

LibAv is a joke.

Wait. So mangled colour decoding (aka the pixels you are looking at) take a lower precedence than "cleaning up old crap"

You are one of those astronaut types.

lol

Great.

I get that.

and my camcorder

You'll have to have faith when I say it is doing it wrong.

It uses _really_ old FFMPEG code that MN cleaned up a couple of years ago.

If you are at all keen on imaging, LibAv is as far away from useful as you can get regarding proper decoding.

Great. But that would also imply that your "preference" is a broken decode, which I can't advise anyone to do.

just the usual works4me

^^

yeah seen that

nor do i intend to advertise

Were voucher-numbers ever sent out as individual emails?