Current Server Time: 10:28 (Central Europe)

#apertus IRC Channel Logs

2015/01/06

Timezone: UTC


00:08
se6astian
left the channel
00:08
philippej
left the channel
01:48
intracube
left the channel
01:52
fsteinel_
joined the channel
01:55
fsteinel
left the channel
02:03
g3gg0
left the channel
04:57
Bertl
off to bed now ... have a good one everyone!
04:57
Bertl
changed nick to: Bertl_zZ
05:04
fsteinel_
changed nick to: fsteinel
07:25
davidak
joined the channel
07:50
davidak
left the channel
09:28
rhavan
left the channel
09:38
rhavan
joined the channel
09:53
g3gg0
joined the channel
10:43
ItsMeLenny
joined the channel
12:08
ItsMeLenny
left the channel
13:44
se6astian
joined the channel
13:45
philippej|away
joined the channel
13:45
se6astian|away
joined the channel
13:45
se6astian
changed nick to: Guest73129
13:45
philippej|away
changed nick to: philippej
13:45
Guest73129
left the channel
13:45
se6astian|away
changed nick to: se6astian
14:39
lab-bot
sebastian created T246: Full HD/16mm crop mode . http://lab.apertus.org/T246
15:21
daFred
joined the channel
15:21
intracube
joined the channel
15:26
designbybeck
joined the channel
16:09
troy_s
slikdigit: Ping.
16:19
Bertl_zZ
changed nick to: Bertl
16:19
Bertl
morning folks!
16:24
daFred
left the channel
16:32
troy_s
Bertl: In terms of structural grain / noise, is it always a linearized add / subtract to add / remove?
16:32
troy_s
(I would have been under the impression that if it were light based, it would be a divide / multiply)
16:35
Bertl
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?
16:36
Bertl
(if not, please rephrase)
16:41
troy_s
Bertl: Specifically on sensor noise, what is the math behind it to remove / add it back.
16:41
slikdigit
hey troy_s
16:41
troy_s
Bertl: Is it pure addition (all discussions pertaining to say, scene referred linearized data values)
16:41
troy_s
Bertl: Or is it a photometric byproduct, that is, in the domain of light and therefore multiplicative?
16:42
troy_s
slikdigit: Greets B. I was going to try and discuss an encoding tool.
16:42
troy_s
slikdigit: Really nice work on the animation. And a really nice writeup. Would have been nice to see a little more detail into the stymies on a project of that sort of scale WRT the libre toolset.
16:43
slikdigit
troy_s: yeah! an encoding tool would be rad. also: web video that isn't taken over by the mpeg cartel
16:45
troy_s
slikdigit: Well I was a little surprised you decided to go to an intermediate and was wondering why you simply didn't encode off of your master frames?
16:45
troy_s
(Although arguably, HuffYUV in Blender _is_ RGB domain. I fixed that.)
16:46
Bertl
troy_s: assuming that the noise is identical (in quality) then adding up N frames will increase the noise by sqrt(N)
16:46
slikdigit
troy_s first ingredient: 4 am after an 80 something hour workweek
16:47
slikdigit
second ingredient: said person trying to figure out encodings stanzas on the command line for hours and making garbage files
16:47
Bertl
troy_s: also note that add/subtract doesn't matter with high quality noise
16:47
troy_s
Bertl: Right... just learned that N*Frames/n
16:48
troy_s
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.
16:48
troy_s
I see literally _months_ of work flushed because of a bad encode. Really sad.
16:49
slikdigit
well, it's not like I was sitting around idle for the majority of the project :)
16:49
slikdigit
but yeah, encoding to an intermediary allows me to use pitivi / handbrake / transmageddon /etc
16:49
troy_s
(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.)
16:49
troy_s
Uck.
16:50
slikdigit
and avidemux is broken on png sequences....
16:50
troy_s
Only because better tools that allow you to master off of your master frames don't exist for you.
16:50
troy_s
Right?
16:50
slikdigit
yup
16:50
troy_s
That's a bloody horrific and massive failure of culture.
16:50
troy_s
Really brutally frustrating.
16:50
slikdigit
pitivi is working on adding image sequence support
16:50
troy_s
Bertl: So is noise always addition / subtraction?
16:50
slikdigit
and I had this weird idea
16:50
troy_s
slikdigit: It's that glaring oopsie of muddling phases.
16:51
troy_s
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.
16:51
slikdigit
i should write it up, too long to explain on irc
16:51
troy_s
(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.)
16:51
troy_s
You should.
16:52
troy_s
What was the weird idea?
16:52
troy_s
(PS if you bump into the PiTiVi folks, please try to stress that the Editing act is a vast airgap between the Conforming / Finishing side. That's a portion of the problem right there - the muddling of phases where distinct workflows apply.)
16:53
Bertl
troy_s: noise always adds up like normal signals, but depending on the noise distribution it becomes smaller and smaller compared to the signal
16:53
troy_s
(this is a pretty great discussion of noise by the way, http://www.imatest.com/docs/noise/ )
16:53
troy_s
Smaller and smaller where?
16:53
Bertl
when adding up data with noise
16:54
troy_s
Is that in the highlight regions?
16:54
troy_s
Where the ceiling forces it into a smaller clamp range?
16:54
troy_s
(I'm really wondering about the math of grain now.)
16:54
Bertl
no, no campling here
16:55
Bertl
let's assume you have a signal (in real numbers, no clipping/clamping/discrete values)
16:55
Bertl
let's also assume you add uniform noise to that signal
16:55
Bertl
(purely random)
16:55
daFred
joined the channel
16:55
troy_s
Hrm. So this is purely a byproduct of log2
16:56
troy_s
Noise is constant, but linear scene referred values divide, so noise decreases as you move up and increases down.
16:56
troy_s
Yes?
16:56
Bertl
when you add up two such signal/noise mixes, you reduce the noise compared to the new signal
16:56
troy_s
Why can I not wrap my head around your last statement.
16:56
troy_s
Argh.
16:57
troy_s
So One Signal, One Noise, mix them.
16:57
troy_s
Reduce the noise in Output?
16:57
Bertl
let's make an example which is better suited
16:58
Bertl
you take a picture with your camera, way withing the sensor limits
16:58
Bertl
i.e. your picture only covers 8 of 16 bit
16:58
Bertl
and the 8 bit are in the middle range of the 16bit
16:58
Bertl
obviously it will have some noise content
16:59
Bertl
now you use a tripod and take 4 pictures
16:59
Bertl
the sum of all 4 pictures will cover 10 bit
16:59
Bertl
again, way in the 16 bit range
17:00
Bertl
so the signal increased by a factor of 4
17:00
Bertl
but the noise only increased by a factor of 2
17:00
Bertl
(because of the way noise is distributed)
17:04
troy_s
9 bit no?
17:04
troy_s
Oh I see.
17:05
troy_s
So in terms of f-stops, the image increased by two stops (1+1 = 1 stop, then +2 is the second stop)
17:05
Bertl
that is why taking several (N) samples can reduce the noise (sqrt(N))
17:05
troy_s
Right. So a median average is actually a mathematical relation to the noise
17:05
troy_s
So the further we increase the sum of our frames, the more we distance our noise from our signals.
17:06
troy_s
slikdigit: You writing or are you going to keep me in suspense on the "and I had this weird idea"
17:06
troy_s
Bertl: Thanks so much.
17:06
Bertl
you're welcome!
17:07
troy_s
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?
17:08
Bertl
I have no real experience with grain (the well behaved and liked noise :)
17:08
Bertl
but if it is reasonably randomly distributed, it should behave similar
17:20
troy_s
Bertl: Is there any way that you could see to imitate the 4 shot (or more) situation and add synthetic random noise to try and find a useful coefficient to pull the actual noise from the image?
17:22
Bertl
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 :)
17:23
Bertl
if you know the signal (e.g. a test pattern), then it is simple to extract the noise
17:23
Bertl
if you don't know the signal, you can reduce the noise by taking N samples
17:24
Bertl
and of course, with the averaged signal you can again extract the noise (to some degree) from each sample
17:25
troy_s
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.
17:26
Bertl
well, to some degree you can, this is what is done with superesolution
17:26
Bertl
you have to figure out what parts of the scene moved where
17:27
Bertl
but for the generic one image scene there is no way to separate noise from signal
17:58
HAL-1999
joined the channel
17:59
HAL-1999
hello everybody
18:00
intracube
troy_s: they did fix the black level for the 4K remaster
18:00
intracube
(ToS)
18:01
HAL-1999
Tesla500 on YouTube has finished his High Speed Camera prototype. You should check it out.
18:01
HAL-1999
http://www.youtube.com/watch?v=yhUO673YgJg
18:04
intracube
HAL-1999: nice shuttling feature when reviewing the footage
18:04
intracube
what is maximum fps @ 1280 ?
18:04
troy_s
intracube: Link?
18:05
intracube
troy_s: https://www.youtube.com/watch?v=OHOpb2fS-cM
18:05
HAL-1999
This is his site: http://omeganaught.com/2014/10/hsc768-high-speed-camera-intro/
18:05
intracube
troy_s: but the AR was changed for some reason
18:05
intracube
from 2.39 to about 2.24
18:05
intracube
and by cropping at the sides, not expanding the height
18:06
HAL-1999
He mentioned 1000'sh something. I think he is limited by the sensor.
18:06
intracube
HAL-1999: thanks
18:06
intracube
oh, 500fps. nice
18:07
intracube
what fps the CMV12000 can do in windowed 1280px mode
18:07
intracube
if it can theoretically do 60 fps @ 4k
18:07
troy_s
intracube: Yes. Looks fixed. Colors look like they shipped it off to someone else.
18:08
intracube
actually, can't CMV12000 do 300fps?
18:08
intracube
troy_s: why do you say that?
18:09
troy_s
Just because the saturation looks well off the orginal.
18:09
troy_s
And wow... those are some nasty ass plate works. LOL
18:10
troy_s
6:55 for example (random scrub point I did)
18:11
slikdigit
troy_s: https://pumprock.net/bkurdali/note/fg8SMPdhTiG7CInvDczVGg
18:14
se6astian
CMV12000 can skip rows to increase FPS
18:14
se6astian
not coloumns though
18:15
troy_s
intracube: Can't seem to find the original mangled one.
18:15
se6astian
so 720 rows are ~1/4 of the 3072 lines
18:15
troy_s
slikdigit: Spinning load wheel.
18:15
se6astian
so roughtly a bit less than 1200FPS I guess
18:15
troy_s
slikdigit: Slowly coming in... yay.
18:16
intracube
troy_s: https://www.youtube.com/watch?v=R6MlUcmOul8
18:17
troy_s
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.
18:18
troy_s
(In theory you shouldn't need to do anything and just master to the specifications, but trim passes are a reality for some folks.)
18:18
troy_s
intracube: Wow
18:18
troy_s
intracube: Mind. Blown.
18:20
intracube
se6astian: that would be an awesome feature for the future :)
18:20
se6astian
definitely
18:20
intracube
lots of data though :)
18:20
troy_s
slikdigit: "Ability to scale and crop per-target" explain.
18:21
troy_s
slikdigit: As in crop your masters or crop simply for output formats?
18:22
slikdigit
crop the output formats
18:22
slikdigit
if you have a target with a different aspect ratio: either crop or letterbox
18:23
troy_s
intracube: It looks like there was another grade there. But I am still suspect on the transform. It looks suspiciously (aside from the horrific bloody double-up broadcast encode that slotted the playback at 16-235/240) like they didn't transform the colors from their Eizo grade.
18:23
troy_s
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. :)
18:23
troy_s
slikdigit: Right.
18:24
slikdigit
anyway, that was kind of my random thought-dump: it seems that we are 'almost there' but not quite
18:24
HAL-1999
What if you want to output to multiple formats? It would be a huge processing overhead.
18:28
troy_s
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.
18:28
troy_s
intracube: Is it just me or is _every_ plate blurred more in the 4k/
18:28
troy_s
intracube: (And there is certainly some color futzing and mutzing between the two versions.)
18:29
slikdigit
yeah. I was saying on another channel: whoever can make something like this doesn't really need it :)
18:29
troy_s
slikdigit: It's the great fallacy of "scratching one's own itch"
18:29
troy_s
slikdigit: Most folks involved with wavelet understanding for example, have bugger all interest in imaging noise reduction.
18:33
intracube
troy_s: maybe continue ToS talk in #blendervse ?
18:35
intracube
slikdigit: I was also thinking about a formatting tool for different aspect ratios a while back
18:35
slikdigit
intracube: cool :)
18:35
intracube
but it would be more useful for dealing with mixed AR source footage as much as destination formats
18:35
intracube
although I can see both uses
18:36
intracube
as in you mix archive 4:3 and current 16:9 src footage
18:36
intracube
and might want to create two different masters. one where footage is formatted for 16:9 displays, and another for 4:3
18:37
Bertl
note: the CMV12k can do binning and subsampling which reduces rows and columns
18:38
Bertl
so I presume, with a few tricks (and a lot of light :) the framerate can go way up
18:39
HAL-1999
intracube: That would require data be processed realtime. Some sort of a multiplexer maybe?
18:39
HAL-1999
intracube: Well, not multiplexer but you know what I mean.
18:42
intracube
HAL-1999: you mean a real-time preview of the formatting (croppping, zooming)?
18:43
intracube
and these features would be better off as some 'finishing tool'
18:43
intracube
and separate from an NLE
18:47
HAL-1999
I guess you already have a preview system. I mean if some realtime crop is desirable but without losing the uncropped sensor raw.
18:51
intracube
HAL-1999: do you mean in camera preview?
18:53
HAL-1999
If camera preview is cropped I suppose yes.
18:54
intracube
I think that would be possible from what Bertl has said
18:54
intracube
but seeing the whole recorded image with frame marker lines would be more common
18:55
HAL-1999
What I have in mind is some sort of a distribution hub that can feed multiple crops to multiple destinations in realtime. Some of these for storage, some for DSP, some for preview etc.
18:57
HAL-1999
For example if you want redundant storage.
19:13
intracube
HAL-1999: that sounds like an extension to what the Beta camera will be able to do with the 3x HDMI outs
19:16
HAL-1999
Sounds good as long as the latency is managable.
19:19
lab-bot
BAndiT1983 created T247: Add preview on secondary screen. http://lab.apertus.org/T247
19:37
davidak
joined the channel
19:58
lab-bot
colinelves created T248: Enable windowed and pixel binning modes - potential for high speed filming and increased DR. http://lab.apertus.org/T248
21:22
comradekingu
left the channel
21:26
davidak
left the channel
21:27
skinkie
joined the channel
21:27
skinkie
ping Bertl your mailserver needs love
21:27
skinkie
http://www.ahbl.org/content/last-notice-wildcarding-services-jan-1st
21:32
lab-bot
BAndiT1983 committed rOPENCINE8507ed6d25f7: - T236: Added reverse playback and adjusted handling - Started adding log⦠(authored by BAndiT1983).
21:34
lab-bot
BAndiT1983 closed T236: swap "play forward" and "next frame" button functions as "Resolved". http://lab.apertus.org/T236
21:43
Bertl
skinkie: ah, thanks
21:45
HAL-1999
left the channel
21:51
skinkie
And what I wanted to mail you, Sven found why uenv.txt is not used.
21:51
skinkie
So i'll try if i can make it work
21:52
Bertl
ah, great! please also compile in the xadc
21:52
Bertl
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
22:48
se6astian
time for bed
22:48
se6astian
changed nick to: se6astian|away
23:00
designbybeck
left the channel
23:09
g3gg0
left the channel
23:20
mars_
left the channel
23:20
Juicyfruit
left the channel
23:20
danieel
left the channel
23:20
TD-Linux
left the channel
23:21
Juicyfruit
joined the channel
23:21
jucar
left the channel
23:22
danieel
joined the channel
23:22
TD-Linux
joined the channel
23:33
daFred
left the channel
23:45
jucar
joined the channel
23:56
mars_
joined the channel