#apertus IRC Channel Logs

Arrg, just typed a bunch off stuff but none of it seems to be here

Oh it's Geordie, I'll log out and change my nic

http://blog.selfshadow.com/publications/s2012-shading-course/mcauley/s2012_pbs_farcry3_notes_v2.pdf

We also use cross polarization to filter out specular reflection so we only capture the diffuse, here's an example:

http://filmicgames.com/archives/233

Bertl: lets assume the white paper is a little bit brown... the calibration has to be done, that it renders #FFF in PC and then all those browninsh papers (= all white papers) will be captures really white. Maybe some specialty white paper will appear colder, blue, but that is only a small chance

good morning

morning

1. a guy decide that there some colors that would make sense for a specific (or general) calibration purpose. He creates differents colors (including hard to match skin tones if it is the intented use). Those colors are printed. The chart is scanned and expected colour values are written in this file (it8.cht). They are not the pure colour the guy intented due to limitations in the printing/capture process. But at least the ex

3. then we arrive with our captured chart. I'd say the purpose of providing expected values in the it8.cht is to assess the quality of the chart we use and the relative quality of calculation we'll get from the intended purpose of this particular chart system. If it's way of, and if the intent of the orginal chart was skin tones for example, it would mean that for this intent, the profile won't be of high interest.

If you read here the section "refining profiles" : http://www.northlight-images.co.uk/reviews/profiling/colormunki_printing.html

With measurements from the first 50 patches, ColorMunki builds a profile and then runs a known set of Lab values (containing neutrals, skin tones, etc.) through the profile to determine roughly the device values of those desired colours.

This refinement process helps identify exactly where these key colour areas reside in the printer gamut.

The new iterative discovery process helps find these neutrals much more easily with fewer colour patches."""

reading it right now :-)

to write/read sensor registers I need sudo priviledges which php/apache wont do

but shell_exec is non interactive so I cant enter the root password

any ideas?

Bertl: Tell gabe you can get raw data using a library from Canons.

philippej: I cannot remember the exact formula. DE is the one that has a standard interpretation as well as standardized formulas.

philippej: And all of what you typed is somewhat tangential. The easy thing to remember is that a chart maps colors that define the shape of the gamut and marks them to known xy coordinates in the xyY model.

and no

DE is a perceptual measurement error.

what is the command to detect the errors?

guesst: colprof -v -D"Apertus axiom" it8-tungsten-01-12ms-perfect

philippej: Just think that the sensor captures random data, the charts of known xy coordinates (Google xyY which is a scaled XYZ that the "color" of the light relative to white is stored in two coordinates)

how does it know it is it8 ?

guesst, read this part : http://www.argyllcms.com/doc/Scenarios.html#PS1

The greater the number of swatches, the smoother the transforms.

troy_s, how many swatches would we need to create a good profile?

yep

philippej: So an IT8 is more than sufficient assuming we A) Have a proper one B) can get a shot that has a mean error of perhaps 3-5.

(Or a DE of maybe 3 ish. Not ideal. But we aren't fine brushstrokes. We are slapping paint on at this point :) )

philippej: Yes. When we get the chart that is suitable for photography. I think the current is based on Illuminant Flor.

guesst: Gamuts are gamuts. They are a volume.

If the chart maps xy values of a given volume, the camera captures a subset of that, the result is a smaller volume.

guesst: Of course it does.

guesst: The real full volume CIE standard observer gamut cannot be crafted with tri color stimulus.

guesst: You _cannot_ map the full volume as the points of the triangle of the base of the gamut _must_ be imaginary.

Which is precisely what XYZ is. And ACES. Etc.

Which is the biggest volume subject to the rules above. When you map values that do not do that to achieve a wider gamut, your software had better account for it or even parts will _not_ result in a perceptual middle value.

what volume you cover with the particular hw

is such data available for other cameras?

guesst: Camera gamuts are generally well defined in motion picture land.

yes. they are calibrated... but it does not mean they can fully cover some standard space

For example, imagine a 12 bit capture of a very wide gamut versus very small.

So gamut is a critical part of evaluating the resulting "quality" of an image.

in the above talk... have one measured the DE of a unprocessed or processed data? (unprocessed would mean nothing, no?)

guesst: Your chart has a particular shape

guesst: When you attempt to bend A to B, some things can't bend to match; you bend A and some of the curves end up moving away from their targets in B

even with 3D lut ? :)

guesst: Which, given we are talking of light in the real physical world, is telling you that your capture / context / circumstance is incorrect.

guesst: Think if R + G is supppsed to equal 6 and we figure R is 4 and G is 2

guesst: But in the next swatch, R + G is supposed to be 8

lost a little

"bending" wont be linear or 3x1D lut... given the uneven shape of the CFA transmission curve

the prototype is now mobile, I just finished soldering the cable for the battery pack!

excellent se6astian !

maybe, not sure yet, as there is not that much to show

troy_s: I was just wondering because the 'measured' XYZ values of the IT8 charts (granted, they are designed for scanners) do not match my expectations

se6astian: ad php, simply run php as root for now

I fixed the php issue already

just finsiedh turneding my living room into an IT8 chart laboratory

(i.e. unnecessary indirection/overhead)

I tried running php as root first but it complained and refused to start up

(White is effectively an adaptive phenomenon that is psychophysical; the sensation of achromatic)

troy_s: agreed, but why would the IT8 chart GS00 XYZ values end up at #FFEFCC when converted to sRGB?

:)

I do not see the white point affecting XYZ to sRGB ... am I missing something?

It influences the color in the chart.

Where the white lives

Our source target

If there is some illuminant strangeness, the achromatic is bent a certain way.

Ideally if illuminant matches destination color space

As in D65

okay, where in the CIE XYZ to sRGB transformation does the white point come in?

(and we magically get a normalized and scaled perfect chart of course)

in this instance, our "connection space" (in ICC terms)

is XYZ

the source MUST be bradforded to the same color temp

Or

LOL

XYZ is always XYZ

Always

You will have a screw up with say, a modified D50 sRGB (sRGB munged to D50)

You can simply transform the primaries

but the white point for sRGB is D65 which impacts all transforms INTO XYZ.

Let me find Lindbloom's page on it to help.

look, I have 'so called' XYZ values in the IT8.cht and measured XYZ values in the R100604.txt

as the transformation to sRGB should be bidirectional, I'd expect at least the gray values to be somewhat near gray/black/white

http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html

1) Transform from WhitePointInput IT8 RGB to SpaceOutputWhitePoint via Bradford Matrix and XYZ Matrix

2) Transform from XYZ to SpaceOutput RGB

So "yes"

Fair?

and why does the R100604 measure the GS00 XYZ as

it simply doesn't make sense for me, why the GS00 (white bar) should be beige

I have no light on it at all :)

eh?:)

Because it isnt white!!!!!!

It is an achromatic patch illuminated by a blue light

or yes.. the patch is not white, that is the other reason :)

Same thing. D65 is not achromatic

but chances are good, that the IT8 chart is wrong or I am missing something crucial

(for the measurements taken on those charts)

yes, that is my understanding as well

and the values are what? xyz should be 0..1 no?

3.2404542 -1.5371385 -0.4985314

0.0556434 -0.2040259 1.0572252

i would try to get some other conversion of IT8 to sRGB and see what matrix they have applied :)

You are confusing things

Well if you use a green light to light your chart, you guess.

See how relative the conversion is?

having a image captured under green light is not an sRGB image...

For the love of god

If you light a chart with a light

it is biased

It is always biased by the light illuminating it

yes. but if you light it with a proper (calibrated) light... you should get RGB which conforms to a color space (eg. sRGB, maybe with some matrix transofrmation)

the values of the swatches are relative to that illumination point and the sampled values will be skewed.

There is no RGB color space

And the illuminant is always there.

So if you lit your chart with a uniform 6500k light source

Si?

This gets screwed all the time as ICCs use a D50 profile conmection space

what you want to say that RGB is relative, when we put RGB+K you have an "absolute color" as you have in xyz

Well

But feel free to keep educating me on XYZ.

a fixed point in XYZ space is not a specific color?

All of what you are saying has been generated based on a conversation that I have not been a part of.

BUT

Otherwise it is apples to oranges.

and if the white point is not consistent... where is the correction plugged in?

or you are trying to say there is an XYZ/D50 and XYZ/D65 where the same xyz's mean different colors?

guesst: I am not trying to say anything. What you are inferring is up to you.

ok, so there is only XYZ needed in that "space", no white point spec

But all of color management is based on assumptions. So if you slug a chart (key here is chart) of known xy coord swatches into XYZ it will not be the precise values without a known color temp

Huh? Achromatic swatch?

have tried other methods (web converter) of xyz to srgb, and the numbers are not same for the gray patch..

or there is some other flavor of rgb where that is true

Not 100% certain

(which ours clearly still is)