#apertus IRC Channel Logs

good morning

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)

alexML: hmm, gives 404

off for a nap ... bbl

Bertl_zZ: works here

very nice

back now ...

https://github.com/apertus-open-source-cinema/misc-tools-utilities/commit/48de47b2a544dc32bbd5a8fd7701bb44a31ea850

do you mind taking a look at it?

i.e. you need to buffer a line and process the data twice

right, it needs two passes

if that's true, you may be able to reuse one pass from the previous image

yes, but the first pass computes some constant offsets, which I assume they are not that dynamic

part of the dynamic noise affects the ADCs and the precharge, so I wouldn't take that from the previous frame

check out an01

I expect that average to be static

ah, obviously missed the frame average

it's not averaging the entire frame, just the black columns

but that is definitely a major modification (not saying it can't be done)

time raw2dng *.raw12 --swap-lines: real 0m7.469s

that's the only valid reason I can think of

second is just copying the raw data

on a 8-year old laptop

but we can make a list what would be a Good Thing (tm) to calculate when a frame is transferred

yes, something like that :)

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.

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.

off to bed

what do you mean "fails on the other half"?

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.

intracube: So when we linearized sRGB and back, we have permanently lost those additional stops into the Gordian Knot of colour transforms.

intracube: To around 0.4something-0.5

But the upside of a log transform is that it _also_ reaches up far further.

you are grabbing about six and a half stops above middle grey from the scene referred values.

That means in terms of UI, your 0..1 diagonal line in curves now has two very useful facets

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.

Not good for manipulating either.

well... depends

That's precisely the point.

How come?

^ not sure what exactly

but the issue was it was difficult making fine ajustments because there was so much dynamic range there

The range only changes on the upward side of 0.4

yep, just subjective 'upper highlights'

Because without the "photo" learned aesthetic, there is no "realistic"

Being log though, you also shouldn't need to tweak the curves as much

Just learn to love log.

It's pretty much a canonized reference standard for good reason.

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.

There is no log look

you mean within the workflow

Yes.

log is an encoding necessity on a number of levels

It's trendy.

I'm trying to chase down what ACES transfer curve they used.

intracube: Nope. He specifically says it is an ACES ODT

I wonder if it is this https://github.com/hpd/OpenColorIO-Configs/blob/master/aces_1.0.1/luts/LMT_Shaper_to_linear.spi1d

which suggests about seven stops of latitude

I can see there's a pink falloff in the bottom right corner

is that a sensor issue?