Current Server Time: 19:42 (Central Europe)

#apertus IRC Channel Logs

2016/01/18

Timezone: UTC


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