#apertus IRC Channel Logs

irieger: That is what I said; dual greens. Impossible to do two readouts in succession without a temporal bit of strangeness I believe?

(Lean on the other green to figure out proper range when out of zone.)

imagine you have two audio amps connected to the same music source

two greens may give a little more latitude, but what do you do when the other two channel clip?

08:24 < alexML> troy_s: they can do two readouts at the same time, with two different amplifiers on the same signal

08:24 < alexML> troy_s: they can do two readouts at the same time, with two different amplifiers on the same signal

alexML: I like your kid ... how old is (s)he?

it's always good to start early with IRC :)

yeah, I remember we talked about it a while ago

that one is RGB based

so, the simplest one would be to apply a curve, and then, direct mapping to RGB

yep

btw, it should be already implemented in the current setup

because we have a gamma LUT for HDMI out, and the alternating green should be there as well

in my simulations I used the same LUT for all channels

I wonder if it wouldn't make sense to use a slightly shifted lut for alternating frames (in the future, not possible at the moment)

another option would be to use alternating pixels for Cb and Cr to compensate for the 422

worth trying, though introduces more flicker[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Dit

flicker is not a problem I thin

the codecs are all intra frame codecs, so no adverse effect on the recording

of course if we can do both over the same thats even better

they also do credit card and bitcoin processing

btw, 422 averagees 2 pixels horizontally, so we may consider doubling the horizontal resolution in some channels (transmit left half, then right half), or shifting some channels horizontally by 1 pixel

isn't the spacial relation fixed in YCbCr and the averaging only happens at reconstruction?

well, each group of 2 pixels have two luma values and one shared chroma (Cb+Cr)

(or otherwise combined)

or Cb/Cr from every second pixel

we should do a simple color grid test

how about a single pixel red/blue bar every 7 or 13 pixels?

s/>/?

there may be even helpful patterns in what you already recorded (didn't manage to look into them yet, only decoded the memory dumps and recovered one image)

hoho!

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/it8-gainx1-offset2047-80ms-02.jpg

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/HTC-gainx1-offset2047-80ms-02.jpg

the 20ms it8 was exposed to the right (the 25ms one was already clipping)

then, used the same curves to HTC 80ms

besides LUTs, I used dark frame, clip frame (nonlinearity-gainx1-offset2047-75ms-01.raw12), and extreme row noise correction

alexML: It _is_ non data.

Absolutely fine as a post production pass after all the work is donr

troy_s: Would sign that. That data isn't usable for serious work.

off for a nap ... bbl

irieger: Amen.

alexML: nice :)

I'd rather say the repeatability

https://dl.dropboxusercontent.com/u/4124919/bleeding-edge/apertus/highlights/it8-gainx1-offset2047-80ms-02.jpg

I guess this is the limits of the colour when pushed this far?

I should have taken a slightly more overexposed image

this is just the first proof of concept, without any claims of perfect colors

(so, a little early to jump in and call it junk, imo)

not you :P

especially since this sensor barely has 9-10 stops of DR

(just commited the code, btw)

doesn't the piece-wise linear mode avoid temporal problems?

the exposure is interupted up to two times

will be interesting to see what that looks like in practice

off to bed