Current Server Time: 17:03 (Central Europe)

#apertus IRC Channel Logs

2016/01/18

Timezone: UTC


00:36
slikdigit_
joined the channel
00:36
slikdigit_
changed nick to: slikdigit
00:36
slikdigit
left the channel
00:36
slikdigit
joined the channel
00:53
slikdigit
left the channel
01:48
slikdigit_
joined the channel
01:48
slikdigit_
changed nick to: slikdigit
01:48
slikdigit
left the channel
01:48
slikdigit
joined the channel
02:05
slikdigit
left the channel
02:13
slikdigit_
joined the channel
02:13
slikdigit_
changed nick to: slikdigit
02:39
davidak
left the channel
03:38
slikdigit
left the channel
03:38
slikdigit
joined the channel
03:45
slikdigit
left the channel
05:45
jucar
joined the channel
06:07
jucar
left the channel
06:39
Bertl_oO
changed nick to: Bertl
07:05
se6astian|away
changed nick to: se6astian
07:05
se6astian
good morning
07:12
alexML
good morning
07:43
alexML
updated highlight recovery samples: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/it8-gainx1-offset2047-80ms-02-v2.jpg and https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/HTC-gainx1-offset2047-80ms-02-v2.jpg (lower noise/fpn after using black reference columns)
07:43
tezburma
joined the channel
07:44
Bertl
alexML: hmm, gives 404
08:00
LordVan
joined the channel
08:59
Bertl
off for a nap ... bbl
08:59
Bertl
changed nick to: Bertl_zZ
09:03
alexML
Bertl_zZ: works here
10:49
se6astian
yes now it does
10:49
se6astian
very nice
11:46
jucar
joined the channel
11:57
jucar
left the channel
12:38
Bertl_zZ
changed nick to: Bertl
12:38
Bertl
back now ...
13:39
jucar
joined the channel
13:44
sebastian_1
changed nick to: AxiomHQ
13:54
jucar
left the channel
14:23
LordVan
left the channel
15:14
alexML
Bertl: just commited a method of reducing row noise using black reference columns
15:14
alexML
https://github.com/apertus-open-source-cinema/misc-tools-utilities/commit/48de47b2a544dc32bbd5a8fd7701bb44a31ea850
15:14
alexML
in my opinion, the results are reasonably good and the algorithm should be simple enough for a real-time implementation
15:14
alexML
do you mind taking a look at it?
15:15
alexML
(the black column step is applied after subtracting a dark frame)
15:15
se6astian
changed nick to: se6astian|away
15:27
Bertl
looks doable, but not trivial for the FPGA
15:27
Bertl
i.e. you need to buffer a line and process the data twice
15:28
Bertl
once to calculate the black column offset, and a second time to correct the actual data
15:29
alexML
right, it needs two passes
15:30
alexML
though, the offsets are probably unlikely to change from frame to frame (didn't test for it)
15:30
alexML
if that's true, you may be able to reuse one pass from the previous image
15:31
Bertl
I'm pretty sure they will change because of dynamic noise
15:31
alexML
yes, but the first pass computes some constant offsets, which I assume they are not that dynamic
15:32
alexML
(e.g. median of black columns)
15:32
Bertl
part of the dynamic noise affects the ADCs and the precharge, so I wouldn't take that from the previous frame
15:33
alexML
guess we need a movie to check
15:36
Bertl
check out an01
15:43
alexML
which part exactly? (btw, I'm talking about reusing noise average, that is, an offset, from previous frame, not the row noise itself)
15:43
alexML
I expect that average to be static
15:43
alexML
(or, at least, changing slowly, not flickering)
15:45
Bertl
ah, obviously missed the frame average
15:45
Bertl
that is a big problem in real time
15:45
alexML
it's not averaging the entire frame, just the black columns
15:46
Bertl
well, we might get away doing that during acquisition
15:46
Bertl
but that is definitely a major modification (not saying it can't be done)
15:47
Bertl
i.e. there should be a really good reason why we would want to do that in the camera instead of in post
15:49
alexML
time raw2dng *.raw12 --swap-lines: real 0m7.469s
15:49
alexML
time raw2dng *.raw12 --totally-raw: real 0m1.276s
15:50
alexML
that's the only valid reason I can think of
15:50
Bertl
both is too slow for real time, no?
15:51
alexML
second is just copying the raw data
15:51
Bertl
(unless you're happy with 8FPS :)
15:51
alexML
on a 8-year old laptop
15:52
Bertl
well, probably faster than on the ARM cores :)
15:53
Bertl
but we can make a list what would be a Good Thing (tm) to calculate when a frame is transferred
15:53
Bertl
(preferably on the Wiki)
16:10
se6astian|away
changed nick to: se6astian
16:48
alexML
Bertl: something like this? https://wiki.apertus.org/index.php/Raw_preprocessing
16:50
Bertl
yes, something like that :)
17:53
jucar
joined the channel
19:34
tezburma
left the channel
20:02
troy_s
intracube: Just donned on me that after all of our sRGB versus Log transformation discussions that I probably missed out the critical point.
20:02
troy_s
intracube: That is, while the sRGB transfer maps a perceptual middle grey to a reasonable normalized 0..1 range for manipulation, it fails on the other half.
20:58
LordVan
joined the channel
21:08
LordVan
left the channel
21:12
troy_s
intracube: A log entry point will properly map a larger chunk of the scene referred image to the display referred domain.
21:13
troy_s
intracube: Also, thanks to your Assassin's Creed Unity clip you linked to on YouTube, with the dynamic iris adjustment, I found this post which will interest you. They started with a Josh Pines Log, and evolved into what seems like an ACES S-Curve log.
21:13
troy_s
https://placeholderart.wordpress.com/2014/11/21/implementing-a-physically-based-camera-manual-exposure/#comment-4
21:48
se6astian
off to bed
21:49
se6astian
changed nick to: se6astian|away
21:50
jucar
left the channel
21:58
intracube
troy_s: sorry, was doing a tax return :|
21:58
intracube
what do you mean "fails on the other half"?
21:59
troy_s
intracube: The upper above-middle-grey values
21:59
troy_s
intracube: If you think of a typical point and shoot crappo camera, it's going to grab maybe five or six stops above middle grey exposure.
22:00
troy_s
intracube: Those five to six stops get crammed into the sRGB mapping from 0.42ish to 1.0ish
22:00
troy_s
intracube: So when we linearized sRGB and back, we have permanently lost those additional stops into the Gordian Knot of colour transforms.
22:01
troy_s
intracube: So when you use an sRGB view, you are moving the linearized middle grey value (probably mapped, but not necessarily so, to 0.18-0.2)
22:01
troy_s
intracube: To around 0.4something-0.5
22:01
troy_s
Which is also what a log transform will do.
22:02
troy_s
But the upside of a log transform is that it _also_ reaches up far further.
22:02
troy_s
That is, if you use for example a Josh Pines log (which is basically a power of 10 log with some alchemy that slides for middle grey etc.)
22:02
troy_s
you are grabbing about six and a half stops above middle grey from the scene referred values.
22:02
intracube
yep
22:03
troy_s
That means in terms of UI, your 0..1 diagonal line in curves now has two very useful facets
22:03
troy_s
1) You get your "middle" about where perceptual "middle" is
22:03
troy_s
2) Between 0.4 (JPLog) and 1.0, you have a decent range of control over not just a piddly 2.1something stops of latitude with sRGB, but a lovely 6.5 stops or so.
22:03
intracube
'linear' stored in sRGB is definitely not a good for acquisition
22:03
troy_s
Not good for manipulating either.
22:04
troy_s
But for some reason I glazed over that so many times in our countless discussions.
22:04
intracube
well... depends
22:04
troy_s
No. It doesn't.
22:04
troy_s
That's precisely the point.
22:04
intracube
tried to grade Log footage and it didn't go so well
22:04
troy_s
How come?
22:04
troy_s
What log?
22:04
intracube
^ not sure what exactly
22:05
troy_s
You realize you can set up a very simple Josh Pines log very quickly using OCIO and use it to render some synthetic work.
22:05
intracube
but the issue was it was difficult making fine ajustments because there was so much dynamic range there
22:05
troy_s
So for example, slap some Suzannes around and put some lights on them as you might expect in a typical scene.
22:05
troy_s
The range only changes on the upward side of 0.4
22:06
troy_s
Instead of that 60% representing 2.1 stops, it now represents 6.5.
22:06
intracube
yep, just subjective 'upper highlights'
22:06
troy_s
This is sort of critical to 'photorealistic'
22:06
troy_s
Because without the "photo" learned aesthetic, there is no "realistic"
22:06
troy_s
(and no photos are going to be 2.1 stops unless you go to some uber-tricky slide reversal stock from 1970)
22:07
troy_s
Being log though, you also shouldn't need to tweak the curves as much
22:07
intracube
troy_s: some time I'll have to explain my half-baked pipeline and you can comment :P
22:07
troy_s
Just learn to love log.
22:07
intracube
eeeh. eh. eh.
22:07
troy_s
It's pretty much a canonized reference standard for good reason.
22:08
troy_s
You can't do it using sRGB. You just can't.
22:08
troy_s
You lose your dynamic range and therefore end up with less than photo type of work. Of course that can work for an aesthetic choice, but is largely crappy.
22:08
intracube
I mean I don't love the 'log look'. not as a final delivery.
22:08
troy_s
There is no log look
22:08
troy_s
That's some dumbass
22:08
intracube
you mean within the workflow
22:08
troy_s
It probably started with an accident.
22:08
troy_s
Yes.
22:08
intracube
right
22:09
troy_s
log is an encoding necessity on a number of levels
22:09
intracube
seems about 70% of our commercials here have the flat, washed out, look
22:11
troy_s
It's trendy.
22:11
troy_s
Did you see that Assassin's Creed link?
22:11
troy_s
I'm trying to chase down what ACES transfer curve they used.
22:12
Bertl
off to bed now ... have a good one everyone!
22:12
Bertl
changed nick to: Bertl_zZ
22:14
intracube
troy_s: could it be some custom effect/transform?
22:14
troy_s
intracube: Nope. He specifically says it is an ACES ODT
22:14
intracube
ah, I haven't read the link yet
22:16
troy_s
I wonder if it is this https://github.com/hpd/OpenColorIO-Configs/blob/master/aces_1.0.1/luts/LMT_Shaper_to_linear.spi1d
22:16
troy_s
I see value of 16 at high end
22:16
troy_s
which suggests about seven stops of latitude
22:19
intracube
alexML: nice work on the colour chart: https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/HTC-gainx1-offset2047-80ms-02-v2.jpg
22:19
intracube
I can see there's a pink falloff in the bottom right corner
22:19
intracube
more obvious if you bring the brightness down
22:19
intracube
is that a sensor issue?
22:20
intracube
it doesn't look like the scene lighting