#apertus IRC Channel Logs

sebastian created T246: Full HD/16mm crop mode . http://lab.apertus.org/T246

slikdigit: Ping.

morning folks!

Bertl: In terms of structural grain / noise, is it always a linearized add / subtract to add / remove?

not sure what you mean, but I presume you want to know how 'noise' adds up when you add up data containing signal and noise, yes?

Bertl: Specifically on sensor noise, what is the math behind it to remove / add it back.

Bertl: Is it pure addition (all discussions pertaining to say, scene referred linearized data values)

slikdigit: Greets B. I was going to try and discuss an encoding tool.

troy_s: yeah! an encoding tool would be rad. also: web video that isn't taken over by the mpeg cartel

(Although arguably, HuffYUV in Blender _is_ RGB domain. I fixed that.)

troy_s first ingredient: 4 am after an 80 something hour workweek

troy_s: also note that add/subtract doesn't matter with high quality noise

slikdigit: Yeah it's one of those things that really smart folks seem to ignore until the last possible time. See Tears of Steel and that godawful encode.

well, it's not like I was sitting around idle for the majority of the project :)

(And if you are unclear as to the godawful encode, there's several things going wrong on that ToS encode. The most significant is the black level. If you look at the title credits, you can be reasonably sure that the background plate was black. It ends up, surprisingly, about 15-16/255, which is the telltale oopsie of a bad encode.)

and avidemux is broken on png sequences....

Right?

That's a bloody horrific and massive failure of culture.

pitivi is working on adding image sequence support

and I had this weird idea

The fact that everyone is so obsessed with the consumer land "Codec codec codec" steers the tools into being horrifically unsuitable for more complex work.

(not the least of which is the disturbing lack of awareness of computing power required for higher grade imaging and the nuances of say, 32 bit float imaging, or deeper planes for other needs etc.)

What was the weird idea?

troy_s: noise always adds up like normal signals, but depending on the noise distribution it becomes smaller and smaller compared to the signal

Smaller and smaller where?

Is that in the highlight regions?

(I'm really wondering about the math of grain now.)

let's assume you have a signal (in real numbers, no clipping/clamping/discrete values)

(purely random)

Hrm. So this is purely a byproduct of log2

Yes?

Why can I not wrap my head around your last statement.

So One Signal, One Noise, mix them.

let's make an example which is better suited

i.e. your picture only covers 8 of 16 bit

obviously it will have some noise content

the sum of all 4 pictures will cover 10 bit

so the signal increased by a factor of 4

(because of the way noise is distributed)

Oh I see.

that is why taking several (N) samples can reduce the noise (sqrt(N))

So the further we increase the sum of our frames, the more we distance our noise from our signals.

Bertl: Thanks so much.

Bertl: To the best of your knowledge, is grain a counterpart or does it behave differently due to the logarithmic nature of the film stock?

but if it is reasonably randomly distributed, it should behave similar

again, not sure what you plan to do, do you want to separate noise from signal on a single generic shot? if so, that would be the holy grail of signal processing :)

if you don't know the signal, you can reduce the noise by taking N samples

Bertl: Problem is you can't average if you have a motion picture can you? You don't know the signal and that ends up a mess.

you have to figure out what parts of the scene moved where

troy_s: they did fix the black level for the 4K remaster

Tesla500 on YouTube has finished his High Speed Camera prototype. You should check it out.

HAL-1999: nice shuttling feature when reviewing the footage

intracube: Link?

This is his site: http://omeganaught.com/2014/10/hsc768-high-speed-camera-intro/

from 2.39 to about 2.24

He mentioned 1000'sh something. I think he is limited by the sensor.

oh, 500fps. nice

if it can theoretically do 60 fps @ 4k

actually, can't CMV12000 do 300fps?

Just because the saturation looks well off the orginal.

6:55 for example (random scrub point I did)

CMV12000 can skip rows to increase FPS

intracube: Can't seem to find the original mangled one.

slikdigit: Spinning load wheel.

slikdigit: Slowly coming in... yay.

slikdigit: "Multiple targets per video: add multiple output formats/ devices/ resolutions to each 'master', which implies" <- That would require trim passes likely. Good idea, but there _might_ need to be a trim pass applied to your master frames. Basically bake a LUT in.

intracube: Wow

se6astian: that would be an awesome feature for the future :)

lots of data though :)

slikdigit: As in crop your masters or crop simply for output formats?

if you have a target with a different aspect ratio: either crop or letterbox

intracube: As in the footage has a uniquely desaturated look which is, I suspect, from someone staring at the wide gamut Eizo and grading in the wide gamut primaries of the Eizo and then simply dumping the values as sRGB/ 709. :)

anyway, that was kind of my random thought-dump: it seems that we are 'almost there' but not quite

slikdigit: Won't get there without a unique bit of development for that sort of thing. It's somewhere between a finisher and purely an encoder.

intracube: (And there is certainly some color futzing and mutzing between the two versions.)

slikdigit: It's the great fallacy of "scratching one's own itch"

troy_s: maybe continue ToS talk in #blendervse ?

intracube: cool :)

although I can see both uses

and might want to create two different masters. one where footage is formatted for 16:9 displays, and another for 4:3

so I presume, with a few tricks (and a lot of light :) the framerate can go way up

intracube: Well, not multiplexer but you know what I mean.

and these features would be better off as some 'finishing tool'

I guess you already have a preview system. I mean if some realtime crop is desirable but without losing the uncropped sensor raw.

If camera preview is cropped I suppose yes.

but seeing the whole recorded image with frame marker lines would be more common

For example if you want redundant storage.

Sounds good as long as the latency is managable.

http://www.ahbl.org/content/last-notice-wildcarding-services-jan-1st

BAndiT1983 closed T236: swap "play forward" and "next frame" button functions as "Resolved". http://lab.apertus.org/T236

So i'll try if i can make it work

and I suspect that there is a memory leak on xdevcfg, but I can't tell for sure right now, needs some more testing with the kernel