Current Server Time: 02:47 (Central Europe)

#apertus IRC Channel Logs

2015/01/06

Timezone: UTC


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