#apertus IRC Channel Logs

morning folks!

Bertl: Get those variances and linearity solved?

as long as you stay in the 'linear' range, i.e. the range where no clipping or offsets apply, you should be fine

not much, but not zero either

even illumination is definitely a problem, sebastian has a bunch of 'helpers' to simplify that

OTOH, if I output the linear data just gamma corrected and with a little tint correction on the red side, it looks quite fine

Bertl: It is to XYZ.

And it of course maps white and black via scale

hence why the need for chart based estimations

that variance across the sensor is "dead shit" from an imager perspective

the linear tailoff is nowhere near where we are shootinf

So I don't know what to say other than the color in the sensor is off by an order of a magnitude of variance (swatch to adjacent swatch)

(and ask why on earth a sensor needs to be corrected _down_ from red and you can begin to see why it is troubling - red has the least luninance of the three channels, and shouldn't be filling up the sensel wells first or, even at d60 etc., in line with green. That is plain broken.)

Bertl: Anyways... hope you make progress on it.

(last try was 8.7,de2k)

s/hast/has/

and the problem is, it doesn't help me much if the calibration gives a perfect score, but the matrix is unuseable for whatever reason

as far as I can tell, the math and the sensor is fine

all we want is to rotate the space defined by sensor primaries, to the sRGB primaries? that could be calculated without calibration

currently all I would like to have is a matrix from sensor to ITU709

so given that the calibration produces sensor to XYZ, a simple matrix multiplication should give the proper matrix

it behaves strange, so I prefer to run it as you described, plain r/g/b with gamma luts

the multiplication is done in a dsp primitive, so not much which can go wrong there either

the color matrix also works as expected if you feed test information

which are all very simple and easy to test matrix operations

if it wouldn't take a lot of time, I would render the IT8 target under given illumination

this completely eliminates the sensor and should give a perfect calibration as well

hmm, unfortunately the IT8.7 target is obscured

danieel: don't you think the calibration process is unnecessarily complicated for a prototype? I think the same applies to your setup, no?

but it quite relies on a calibrated screen too

i would assume it is again a matrix and 3 un-luts

good evening

Egads

Bertl: Look at the GS swatches.

danieel: How exactly do you propose to transform to RGB to sRGB without a chart? I can sleepwalk through this stuff, and I am certain you are failing to grasp the issue.

Egads.

Just "carrying on" is a very unfortunate suggestion. Color is everything the damn camera will be capturing, and it is pretty darn important.

danieel: Doesnt work that way

in todays world of massive color correction, the color is not the important thing, rather DR, noise, linearity

danieel: You are _so_ wrong

danieel: I challenge you to find the F65 LUTs or Arri LUTs etc.

Junk guess statement

And I will call you out on that sort of bogus speculation.

omg, matrix and luts provide a completely different set of operation, they are not equivalent!

Bertl: help me :)

You really arent listening

Fsck this keyboard

A well behaved sensor WILL behave better

Color for a camera is important, and calculating the matrix PROPERLY is also important

we should calculate the matrix then from 3 patches, r/g/b - is that an option?

Why the hell do you think they make charts?

Egads

A matrix has three primaries yes

You can get it down to <2 de

AND resolving any sensor issues

to above 77 rgb values

WHICH tells us SOMETHING is wrong

even when loaded under blue d60-65

as red lives at a MUCH lower luminance than green

first

As it is most indicative of Y pure luminance

I just explained it

RGB doesn't live at the same heights in luminance

i can overblow your sensor with IR and you wont notice it visually

or do you do this to rehash things in your head?

So you don't like logic and averages

I don't mind

and green, depending on variety of green, lives highest

danieel: So remember when we covered XYZ?

yes, but that are end colors, has nothing to do with the fill rate of the pixel

that depends mostly on how narrow/wide the filter on it is

look at the QE charts for the sensor

The color range is determined by those wells filling up, and given that color doesnt exist except in pur heads

and that is the energy level of the photons landing on the sensel

hence why they fill faster

danieel: https://www.youtube.com/watch?v=x0-qoXOCOow

that is the outer edge hull "heights" when projected outwards

confusing video

danieel: Just look at the damn cur e

The video is NOT confusing

(which sums to confusion ;))

danieel: Projected out to the flat walls of the XYZ infinite pyramid

higher

but that applies to humans

a sensor wont care about that

That IS how they fill

forget it

the XYZ model is linear light energy

if you wont agree with the fact, that one set of primaries can be turned to other set of primaries

that is possible. look a cmy sensors

<troy_s> danieel: Doesnt work that way <-- here

you cannot

You get tp

Fair?

so what is the output of the calibration

And again, most sensors can be profiled quite well using a single matrix. Can a 3D LUT push it further? Likely possible, but not in the DE ranges we are getting, which can still be a number of reasons.

It is an XYZ matrix

not exactly complex

0.181713 1.167207 -0.447090

X = 0.85 r + 0.37 g - 0.08 b ... that way?

because it may have more or less scaling

-u or?

So downs should be the primaries transforms

argyll-colprof -vv -am -D"cloudy-sky" -u -qu ./table.cloud.gs.avg

danieel: Try this with it

that is in reverse direction matrix

so type that the.

enter

and you will see something unique

with reverse toggle (-ir)

1.000000 0.000000 0.000000 [RGB] -> MatrixFwd -> 0.874222 0.182312 -0.066498 [XYZ]

(looks like you have the scaling on)

that is your PRIMARY in XYZ

try

so the matrix printed out by colprof is nine rand() numbers.. great

It is your nine XYZ primaries of your RGBs

so what with them?

You need XYZ to unlock all color transforms to alternate spaces

and attach a transfer curve

0.000000 1.000000 0.000000 [RGB] -> MatrixFwd -> 0.376678 1.215790 -0.420441 [XYZ]

That is green

which corresponds to your starting matrix

yes

and you could plot them if you wished, but they won't be quite like sRGB etc as the filters aren't narrow field.

so to go to sRGB from those primaries

ICCs always are morphed to D50 for XYZ transform

(you need a defined white point, and ICCs use D50.)

just fired up my CCU... so lets find finally out what matrices are needed

danieel: Which could account for the range of RGB being high in red on the charts, but there still seems to be issues just looking at a raw dump of the data on sRGB

to 709

now we want to go sRGB

http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html - here the D65 or D50 variant?

XYZ is absolute

(D50 would have effectively no Bradford to D65)

Done all of this stuff by the way

it is heavily red, with Final RGB matrix:

G = -0.508098 1.898262 -0.732542 + 0.000000

Shocker!

what?

It shoukd be counter red heavy

You may have fubard an inversion

The inputs (on seb's most recent sets) balance on the achromatic swatches at 77, 77, 39 or something whack

And further, that is random anecdotal "looks ok" on a display that isn't profiled with an image that has no profile

Look

There are a lot of variations that you can bog the hell up.

But if you are hell bent on trying to "prove me wrong" go nuts and have fun. I could care less.

then I would suggest you evaluate all of the areas that you may have bogged up

Profiling works. I don't have much else to add.

so "hardware" wise, the matrix is applied correctly

identified correctly. Also note that direct sun with no sky catching will give you a decent D50)

(and I would do it first with an ICC capable app until you are 110% certain you have a handle on the transforms and the other bits)

forget the app, the processing is just not correct

R = 2.585789 -0.438627 -0.348700 + 0.000000 .... is just wrong (source is sensor RGB here)

danieel: For the love of god

What de was reported in de2k?

danieel: ?

cant find the number

whoops

typo!!!

(I am sucking with keyboards today. damn phone screens and such)

what other options?

Profile check complete, errors(CIEDE2000): max. = 13.986425, avg. = 3.836771, RMS = 4.445354

Can be better

So 3.8 is off

that does not explain why the numbers in the apllied matrix are such high

I give up

danieel: I need a timeout from you. If you understand what profiling is and does, you can figure out the rest from there. If you cannot, and you simply want to be contrarian have fun for a while.

Use ICCs it works.

See you in a few.

1) Test with an ICC enabled application. I know this may offend Einstein there, but you need a control.

Bertl: Ping me when you are around sir.