#apertus IRC Channel Logs

yes, the streaks are definitely part of the FPN

off to bed now ... have a good one everyone!

remember, that gain is applied AFTER photo-electron conversion, at the e->V stage. you can not control the photon conversion rate and the DR / latitude wont get over the equivalent of full well capacity

danieel: You don't get more data.

danieel: Make sense?

danieel: Middle grey slots in at around 0.2 display linear, which taken up a stop, is 0.4, taken another is 0.8, and a bit.

danieel: In a scene referred model, you must be set to hold many more stops of data. In such a model, 1.0 has no meaning.

danieel: So if you are compositing say, a mere 9 stops upward from say, a middle grey set at an arbitrary 0.3 perhaps, you'd need 0.3, 0.6, 1.2, 2.4, 4.8, 9.6, 19.2, etc.

danieel: And that doesn't even begin to cover an HDR pass or IBL.

(Hopefully that makes sense, and largely explains why inter-pipeline formats are almost exclusively EXR. Interchange formats generally err toward DPX due to the inclusion of a TRC, where OpenEXR is exclusively linear, and requires additional information to properly communicate aesthetic choices such as transfer curves and such.)

Full well charge 13500 e-

(which does not need to be true, depends on implementation of PLR)

danieel: The bit depth conversion to 32 bit float OpenEXR scene referred values is required for post.

undo the plr is simple with lut, 10/12->16bit (at most)

danieel: And requires the inversion of whatever TRC.

troy_s: if you used DNG's a little bit more, there is a lut based interpretation of stored values - the inverted TRC you want. specified in each file. I think that is worth of the extra 8kB :)

danieel: DNGs are fscking useless to the question.

And yes, you can get reasonable scene referred values. Reasonable as in they will composite quite well with no luminance errors

Huh?

Have you EVER done image manipulation man?

Of course the MUST MASH KEYBOARD BEFORE I UNDERSTAND WHAT HE IS SAYING types

look, PLR is just what it is. I totally wonder why do you have such a trouble with understanding how to undo-it

three slopes, you can undo it by code with brances, or by luts

but what matters is, that you never get from such an undo-operation more than 16bits, because of the (crappy) sensor

no matter how much you want a 32bit float

32bit lin or float is unnecessary for the camera!

Read.

The.

Where did _I_ suggest to use 32 bit in the camera?

You keyboard mashers drive me batshit.

Good.

Yes. Now read the damn context.

Fffffuuuuuuuu

i have a practical question

(e.g on a F65)

There is never a slope in an EXR. (Well I suppose you could say there is a linear diagonal slope.)

What?

like 1.0 will always refer to a spot with defined brightness

so it has no knowledge of how much the scene is lit

again

An EXR if scene referred, and not display linear

i am talking about scene referred here

Good.

What did you mean by "like 1.0 will..."?

(Perhaps 1.0 was an arbitrary choice.)

Your dynamic range is your data.

So if you go from 0.0000000212 to 45822.2

or you get 1-1000 at both in night and day for the same scene?

Think data.

It is like me asking you to look around your room and tell me where white is.

it does. how are you going to compose 2 sources then? you need to manually set a "replay gain" to have them matching?

Erm not really. You generally slug them in according to whatever reference base you set.

If we are HDR stacking, then we need ancillary data to cluster the images.

or set afterwards, when the file is used

All that really matters is that your relative intensities are representitive. Rather easy math in scene linear too, as it is a basic multiply.

okay, so EXR is not absolute

Not sure what absolute means.

If you mean "XXX nits maps to value YYY" then no.

yes that

then I see no point / no benefit / in using EXR over 16bit integer linear - on contents from our cameras

Again.

If so, again, I never ever for a moment implied nor stated that.

If you mean in imaging, then you don't understand the problem

:)

Ok

And we wanted to blur that range.

there is no blur on camera content

Again, this entire discourse is predicated on processing as I made clear.

but the source data from camera for you processing pipeline does not need to be EXR/32bit

yes

I am quite sure that if you use your due diligence and read precisely what I wrote and understand the context, that I made no such claim.

Don't. Be. A. Donkey.

why EXR????

you can to TRC and inversion to a 16bit integer

*do

morning everyone!

just think applying a gamma curve to linear data (same bitdepth) and then undoing it later

slowly please

it is same princliple as sLog

let's say we have 12bit

sensor data

the values we get sent over LVDS

we don't know if a 10bit, 12bit or 24bit ADC is there

yes

of course

the lower half is 1:1 and the upper half we make 1:2

so the quantizaiton step in 1st half is 1

the DR range is 1.5x more than in linear mode now

i think :)

now, if we want to undo the TRC here, i.e. get a linear range, what do we need to do?

make a lut, and you result in 13bit output

now currently we receive 12bit and we store 12bit

lose?

i.e. on the lower or on the upper end

sort of lossy compression

(unless we make it 13bit)

and that's all I said in my email reply :)

do you know how the adc works and plr is done in practise?

still no need for float

for storage I would prefer to store the "compressed" raw data as the sensor gives them, and then stitch a lut/trc per frame with it (perfect for dng workflow)

i would maybe care about applying that unpacking - for better looking preview on viewfinders (plr as is is not easy to understand if the scene does not contain fades between ranges)

i know I can do that on my sensors - but the feature is rather less documented as it was an experimental feature

(would interfere with exposure of the frame)

my thinking is rather that it is needed when you do EV correction in post (get back the shadows / highlights )

so it wont show quantization artifacts (posterization)

it is funny that it is always hard to talk with some people and easy with another :)

with high fps sensors we can do lot of magic in that direction

yes, the advantage of the built in HDR mode is that it doesn't require an image transfer

i.e. it happens in the sensor, which is a big advantage from the timing PoV

danieel: pardon me asking, how old are you?

those per row/col different gains you mean?

even in the PLR mode it does that

the sensor can easily do a snap in 1-3ms or less

but how are you then getting into 100 fps?

first, we are only using half the LVDS lanes

so we could half the time/double the frame rate there

second, newer CMV12k sensors (v2) have 600MHz lvds

not yet, but I'm pretty sure they will have some additional range

& a good 1 2 u 2!

I see a certain shift back to 1337 type :D

you started it 536A571AN :)

I ll test my theory by adapting the PLR GUI

sebastian, do you think you can get one or two more examples on PLR in the video? seeing the huge dynamic range is so awesome

:) cu later

so far so good: https://cloud.gerade.org/public.php?service=files&t=88644302ffde4f6e5659627a3c8bbf32&path=/Axiom/alpha/PLR02.jpg

+1 fstop = factor 2

i.e. the reasoning is fine for the given graph, but the light to voltage diagram probably looks a little different

because of nonlinearity ?

i.e. it might match for 30ms/10ms

ok, let me revisit the concept

think I fixed it: https://cloud.gerade.org/public.php?service=files&t=88644302ffde4f6e5659627a3c8bbf32&path=/Axiom/alpha/PLR03.jpg

se6astian: Now that the mangled data is gone, the general progression was lower DE as we marched up exposure. Mean error was 5.9 or something at 34ms.

otherwise the FPN streaks would not show

Bertl: On the flip side, the streaks might simply be extreme errors in the noise.

Bertl: (Or conversely data in the b and g.)

danieel: PS: :P

yep

danieel: "others might be good at theory" was clearly directed at me. All I said was you were wrong. You were. No idea how that is theory. ;)

https://cloud.gerade.org/index.php/apps/gallery/ajax/image.php?file=88644302ffde4f6e5659627a3c8bbf32%2FAxiom%2Falpha%2FPLR04.jpg

but the more you push it the more noise you get

se6astian: I guess a log-ish curve is needed.

se6astian: The curves are pretty simple, and all color space transforms in tricolor to XYZ are 3x3, so I doubt there is an issue there.

se6astian: Wider gamuts when dumped to smaller look desaturated.

(Same goes for wider latitude when viewed on LDR)

well you dont really extend the dynamic range with this mode, you can just pull down the highlights into a useable range

not true :)

basically the lighter sensels have a shorter exposure time

se6astian: Hard to guess from here. The only thing that can ultimately evaluate saturation however, is a post analysis of a chart. Until then, it is just random data to an extent.

Bertl: what settings do you mean?

I cant recall exactly it was just a general impression that the image seems to loose saturation the more I increase the PLR values

I will capture actual footage to analyse soon

these parameters are visible in the GUI

yeah, I know, give me some values to work with

you can try the settings exactly as in the screenshot if you want a good starting point

do you want me to read them to you? :)

ah!

Exp_kp1 = 0.4ms

Vtfl2 = 21

Vtfl3 = 42

slopes = 3

datasheet page 34

kneepoint 1 is to top one in the response curve

okay, so be it

no that must be vtfl3 then

yes, it confused the hell out of me to always swap everything while I was programming this gui

:)

let's assume R,G = 80%, B = 100%

vtfl3 is the first holding voltage, vtfl2 is the last holding voltage

yes

i.e. R,G, and B will max out at 2/3rd anyway

which means, that the 20% difference get reduced to 1/3rd

*100%

Interject here?

What does the vtfl register represent?

the voltage level the sensel is kept at

So it does a stepped capture?

in this specific config (given by se6astian) the following happens:

for 13.5ms, exposure is 'limited' at 2/3rd of the possible range

and after that, it is unlimited for 0.4ms

note that the exposure starts at 100% and the voltage is reduced by exposing

So the kp registers indicate how long they hold voltage at?

se6astian: Will do the IT8s today

se6astian: The more you and Herb hammer on the noise, the better. Once we get the data under control, better things follow.

Ah

Bertl: What is the second value then?

Yes.

Gotcha. So a hardware value.

Bertl: And how many of these knees are possible?

Derp.

(thinking along the lines of the log to lin discussion)

(which is a sane assumption for a first test)

and he also figured that the knees need to happen at the end of the exposure not at even spaced intervals :)

Hrm. Interesting dilemma.

i.e. if you are not interested in the dark ranges, you can 'trade' bits for the light areas

you get 4096 values to break up into three ranges

And given the bent nature of perception

(although _this_ control is extremely interesting if there is a means to expose it in a well designed wrapper)

(where midish is probably in that 20% region)

Bertl: Given that you already have clipbits working

Bertl: Are we able to repurpose the bit depth left over from the clip, or does the existing scale already do that?

Bertl: ^^?

we can't do anything about that in the sensor

Ah.

It does seem a wee tad odd.

I wonder what is going on there.

i.e. it is not really relevan or important atm and again, time is on our side here

we send them on a regular basis

Frustrating that at this early on the sensor is already suffering bit depth degradation.

And are they aware that their sensor goes nonlinear quite badly at the 70% threshold?

anyway, not a real problem right now, workaround exists, everything else will be solved later or if it is unresolveable and problematic, we simply drop the sensor

Anyways... sort out that streaking noise so we can get decent images.

hehe, se6astian just needs to play with the linearization values

Bertl: ?

Bertl: The streaking is purely that?

either that or a missing/bad rcn adjustment

RCN = Royal Canadian Nuts?

that would hint towards RCN (Row Column Noise :)

see how well acronyms work :)

ah linearization values, I did play with them a bit already

Is there a better method to get to values than random trial and error?

I wouldn't use anything below 1.2 from what we've seen so far

so 1.3-1.5 as factor, and probably -0.1 to -0.2 for the offset

my comment on that is to adjust the registers as suggested

cant we correct the non linear areas back to being linear, 1.3 - 1.5 means rather large banding gaps in the histogram already

can't be that large if we have 1.5 (the maximum suggested)

so 0, 1, 3, 4, 6 ...

*horizontal I mean

so if your histogram is 1920 pixels wide (full HD screen) then you won't be able to see it

maybe I just was lucky and "tuned" into those missing slots

se6astian: By the way, the 34ms in the Hutch was heading to best DE. Didn't look too hard at the data, but going further might be good in your brackets.

I just have the chopped histogram effect again, but if you are currently unable to view images/websites I guess it makes no sense to upload

you feed the cmv_hist3 output directly to a graphing software I presume?

to get a 256 wide histogram

I suggest to do the following:

and with previous I mean the one right before not 16 values before

(up to a factor of 2.0 :)

a much better approach would be to average the 16 values

off for a nap .. bbl

Bertl: Just as an FYI, the red and green data channels still have odd wow curves in them.

At about 90% now. Blue's data is fine from what I can see.

Bertl / se6astian - Ran all the IT8s. Similar DE2000s.

Shapers and matrices hold up well on the lower exposed images as well.

Streaking is a nightmare, and likely hurting us quite a bit from what I can see.

Other than that, much improved from DEs of 30+.

interesting, I thought the streaking was already gone with ./linear_conf.sh 1.07 0, at 1.3 I did not expect anything to still remain in the image

(With maximum being the rather ugly 11.5, which is again our linearity and streaking issue.)

Let me push an sRGB version of the raws.

so can you output a matrix from your software already

Always could.

The issue is the data.

(Of course we could _selectively_ dial in a single bit of data and make it appear 'decent' in 709, but that achieves nothing for us.)

se6astian: The transform will require a shaper 1D LUT per channel to get the data values more closely linear (due to lower level hardware blah I suspect) and then a matrix to transform the camera's unique colorspace into XYZ.

se6astian: See the streaking?

I see it

LOL

se6astian: In the end, the screwed up sensor data is causing it to be seen more nastily than in the less obvious data dump to sRGB views you probably look at it in.

se6astian: And I'm quite sure that if we clipscale the data a little more, the streaking will be toned down due to our shaper / matrix being more accurate.

se6astian: My point is that we should work on tuning that out.

se6astian: Which isn't bad for an alpha alpha.

higher linearization values?

1) Refine the clip and scale region. I _think_ we should clip and scale to about 90% of where we currently are.

(Because I'd love to leave the blue as it is, and clip scale the weirdness off the green and red)

I'm sure Bertl has some ideas on how to dial in the RCN values and adjust the clip scale.

sounds good already

se6astian: I know you appeared somewhat worried about the transforms. Hopefully you can see how the data has been / still is a little pooched.

yes its great to see we identified the problem now

I'd love to see Cmosis explain or fix the blasted 12th bit errors.

we should write an article about it ;)

after all we are in the unique position that we can review our own product

se6astian: I think if we can fix the RCN and tweak the clipscale a little further, you can probably get to decent videos.

se6astian: Be careful on YouTube pushes. The broadcast scales can _greatly_ screw your imaging.

you mean 0..255 vs 16..235 ranges?

And it almost _always_ gets pooched by folks not looking for it.

Luma needs scaling to 16-235, and chroma rests at 16-240

when encoding, if you encode full range data (1-254 in 'by the book' reference 'full range')

it will take the 16 value and map it to 0

The files I uploaded were written in DNxHD with RGB Levels (0-255), do you suspect youtube treats that wrongly?

Yep!

and crimps the white at 235/240

Needless to say, the net sum is that "If you don't watch for it, your contrast will be hooped, and contrast impacts perceptual sharpness"

When in actuality it is perceptual contrast.

se6astian: Mandatory reading http://www.zeisscamera.com/doc_ResContrast.shtml

se6astian: And fascinating from an imaging standpoint.

se6astian: My best suggestion is to put a bloop in

se6astian: And freeze on it in YouTube.

http://www.belle-nuit.com/test-chart

the bigger problem I have is that even if I upload in DNxHD at highest quality settings the video on youtube has ugly compression artifacts all over the dark areas, I have seen youtube clips that looked super crisp, do they pay extra :)

Yep.

But let me get the other warning out

At youtube, if you run non-full frame you can get different scaling.

Largely because the full screen version using Flash or some browser accel

and yep... the GFx card may or may not make assumptions about the YCbCr data.

:)

Anyways... put a test chart bloop in for the viewers

I started considering hosting our own video player on the website, we would have the space and bandwidth

se6astian: Probably not entirely worth it at this point. The trick is to find the secret sweet spot at YouTube so it doesn't reencode.

se6astian: Even without the compression issues, people's displays tend to be all over the damn place.

yes, but we can at least provide a good baseline

Yep.

Camera data == Arbitrary. Period. Full stop. It is meaningless. If you are viewing the raw data using a viewer, what you are seeing is not color.

If you snap on test charts, you can also tell almost immediately a few things:

2) What kind of chroma scaling is it doing (see the chroma patterns in the middle region. If you see blurry lines on a pattern, you can tell what version it is doing - likely 420)

4) Is there odd cropping happening?

A bloop chart for a frame is a welcome thing. :)

se6astian: If you want to see what I mean... http://www.youtube.com/watch?v=R6MlUcmOul8

got it

se6astian: Okie. Chin up. We will get there on the color front.

troy_s: yes, thanks for your time and efforts over such a long period

I really appreciate all the help/input, I don't think I mentioned it yet though ;)

se6astian: Hopefully you didn't read my aversion to the colorist approach as me poo pooing it. I wasn't.

The worst part is that a colorist can take just about any image and make it look good. Sadly that isn't our need at the moment. We have to smooth that data out so that we get consistent results that a static shaper LUT and matrix can transform reliably in all situations.

time for bed