Current Server Time: 19:47 (Central Europe)

#apertus IRC Channel Logs

2015/12/08

Timezone: UTC


00:25
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.raw12.xz
00:25
Bertl_oO
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.png
00:25
Bertl_oO
changed nick to: Bertl
00:26
Bertl
note that the png is the raw image 'debayered' with the simple imagemagick debayer (i.e. combine 4 sensel into one RGB pixel)
00:27
Bertl
also note that if you reduce the green channel by 16% you already get a quite nice image (what we did on the live feed today)
01:04
Bertl
troy_s: let me know what you thing of the all new an improved "look" of the AXIOM Beta :)
01:04
Bertl
*think
01:06
Bertl
just for the record, no FPN correction or other alteration has been applied, this is the raw sensor data
01:07
troy_s
Bertl: Were you able to get a log-like knee in on the last pass?
01:08
troy_s
Bertl: The smartest approximation going is to attempt and distribute equal bits per stop.
01:19
troy_s
Bertl: Only got a small strip of the register settings PNG.
01:20
troy_s
Bertl: And I don't understand what you mean by "reduce green channel by 16%"
01:21
troy_s
Bertl: Unless you mean it looks "acceptable" dumped to sRGB primaries
01:23
dmjnova
left the channel
01:23
dmjnova
joined the channel
01:26
Bertl
yes, i.e. just reducing the green by 16% makes it look nice on the HDMI feed, nothing more
01:27
Bertl
so nothing color-science relevant there, just a simple observation
01:55
troy_s
Bertl: Can't wait to look into the images.
01:55
troy_s
Bertl: Is the xz a Macbeth / ColorChecker?
01:55
Bertl
it is the raw data for the (same named) png
01:56
troy_s
The PNG is corrupted.
01:56
troy_s
Can't see what it is of. ;)
01:56
Bertl
really, sec, let me double check
01:56
troy_s
Also, to everyone in here, read this great article by Thomas...
01:56
troy_s
http://colour-science.org/posts/the-importance-of-terminology-and-srgb-uncertainty/
01:57
Bertl
ah, damn, I'll re-upload it
01:57
troy_s
(Great to see him call out yet-another-dev for spreading misleading information)
01:59
Bertl
so, png should be fine now, sorry for the confusion
02:00
troy_s
Bertl: Any progress on the curve?
02:01
troy_s
Wow... Reminds me of Viper footage dumped raw to sRGB primaries!
02:02
Bertl
@curve: not yet, but I'm optimistic we will get a lot further in the next few weeks now that the sensor registers have much more saner values
02:13
troy_s
irieger: http://www.curtpalme.com/ChromaPure_JETI.shtm
02:13
troy_s
irieger: I strongly suspect one of those is in Apertus' future.
02:13
troy_s
Bertl: That is terrific.
02:17
troy_s
Bertl: Working on getting TM to help out. Great peep to help on the characterizations as he works in post and understands the needs better than most typical forum dwellers.
02:18
Bertl
great!
02:43
Bertl
off to bed now ... have a good one everyone!
02:43
Bertl
changed nick to: Bertl_zZ
05:34
pozitrono
joined the channel
06:09
james
joined the channel
06:09
james
changed nick to: Guest41630
06:10
Guest41630
left the channel
07:34
aombk2
joined the channel
07:36
aombk
left the channel
08:06
pozitrono
left the channel
09:24
se6astian|away
changed nick to: se6astian
10:33
pozitron
joined the channel
10:53
Bertl_zZ
changed nick to: Bertl
10:53
Bertl
morning folks!
11:26
irieger
troy_s: Our color guy here prefers the Photo Research things over the JETI spectros.
11:27
irieger
If needed later on to verify some spectral colors I'll try to get the PR we already had a few times for some research stuff from another institute here on the campus.
11:31
arpu
joined the channel
11:45
Bertl
off for now ... bbl
11:45
Bertl
changed nick to: Bertl_oO
13:12
arpu
left the channel
15:18
Gaudis
joined the channel
15:18
Gaudis
Hello Im Gaudis Sosa, from to Venezuela
15:20
se6astian
hi Gaudis!
15:20
se6astian
how can we help you ?
15:20
Gaudis
I would like through this chat to share knowledge about the realization of these extraordinadias cameras and help in what I can
15:21
Gaudis
im 3d animator in blender
15:22
Gaudis
also worked in the audiovisual area
15:23
Gaudis
and I am very interested in the development of cameras free technology
15:25
Gaudis
in my country it is very difficult to obtain high-definition cameras , have many limitations. And as an advocate of free software and hardware you have proposed this project to various partners and we learn from their experience in the development of these cameras here ... to open a chapter of the project apertus here in Venezuela
15:26
Gaudis
quisieramos contribuir con lo que se pueda o incluso comprar la camara mas basica para ir aprendiendo de a poco
15:26
Gaudis
We would like to contribute what they can or even buy the most basic camera to go slowly learning
15:29
Gaudis
sorry for my bad English!!! :)
15:33
Gaudis
so far is that dared to write , and for me it is an honor to talk to you
15:34
se6astian
great, was occupied for a sec
15:35
se6astian
back now
15:35
Gaudis
OK I'll wait for you
15:35
se6astian
sounds wonderful
15:36
Gaudis
oh yeah wonderful serious
15:36
se6astian
For acquiring a camera please join the preorder notification list here: https://www.apertus.org/axiom-beta
15:37
Gaudis
ok
15:37
se6astian
"Register for preorder"
15:37
Gaudis
ok
15:37
se6astian
once you have a voucher you get the axiom beta at-cost
15:38
se6astian
you can decide if you want to get the hardware early on - when the software is still in development and participate in testing or even defining the software
15:38
se6astian
with feedback, ideas or software development contributions
15:38
se6astian
or you can decide to wait until the hardware matures
15:38
se6astian
then it will be more stable and solid
15:39
se6astian
but of course many decision have already been taken then and there is less room for direct participation
15:39
se6astian
no matter when you decide to get your camera unit
15:39
se6astian
it will be at-cost
15:40
se6astian
We started collecting Phase 1 payments last week
15:40
se6astian
which allows us to buy essential components like the image sensor at larger volume soon to make it cheaper for everyone participating
15:42
Gaudis
Wait for a minute that I am translating , I do not speak English
15:43
se6astian
sure no problem :)
15:44
Gaudis
that they are under development right now ?
15:45
se6astian
The AXIOM Beta hardware development has just been finished
15:45
se6astian
we are now shifting focus on software development
15:46
se6astian
some hardware additions are still planned though
15:46
Gaudis
if I buy a camera axiom beta , you also give developing manuals ? or only the camera ?
15:49
Gaudis
woow excellent , ie if I order in January next year, you give me a camera that just develop ? So I think the most exciting and thrilling !!!
16:03
se6astian
what do you mean with "developing manuals"?
16:06
Gaudis
well ... my main interest replicate their work here , forming a multidisciplinary team to help make a camera as you have developed and also contribute to improvements ... so besides getting the camera ready interests us is that exchange knowledge
16:08
arpu
joined the channel
16:09
se6astian
great, then it sounds like you are interested in an early prototype already
16:12
Gaudis
Sure, I'm writing and planning the project , and I need as much information for people who can support me
16:14
Gaudis
it is still a project, but the sooner it will be obtaining the fastest raise resources for financing
16:14
se6astian
great
16:18
Gaudis
our proposal is to form a multidisciplinary team to study the development stages of the chambers , and from there into a school that will serve for the development of new cameras .
16:18
Gaudis
our proposal is to form a multidisciplinary team to study the development stages of the camera, and from there into a school that will serve for the development of new cameras .
16:19
Gaudis
excuse me
16:20
Gaudis
I'm using this translator is very bad
16:21
Gaudis
I mean we want to create a school of high-definition cameras
16:23
Gaudis
we know that this project is not possible without help , so we wanted to have your support ... and also to extend our help you count on us
16:28
se6astian
you have our support
16:41
Gaudis
woow excelent
16:42
Gaudis
You do not know what it means to me to contact you !!! and count on your support
16:45
troy_s
irieger: Haven't heard of them. Looking.
16:51
troy_s
irieger: Ah. SpectraScan. Got it.
16:52
troy_s
irieger: Rather sure that to test sensors, light boxes, etc. at some point a spectro will be required. Not sure how feasible it is to keep renting them etc. Plausible for a little while.
17:34
test
joined the channel
17:34
test
left the channel
18:02
Bertl_oO
alexML: if you don't mind, let's move the raw/deep color encoding discussion here
18:02
Bertl_oO
changed nick to: Bertl
18:03
alexML
okay
18:04
troy_s
How be things folks?
18:04
Bertl
alexML: the modes I implemented so far are very basic but I have spent some thought on preserving as much data as possible as well
18:05
Bertl
currently we produce RGB 444 output for HDMI
18:05
alexML
ah, so you don't do any chroma subsampling on your side
18:05
Bertl
we will be able to change that in the (near) future, but that is what works right now
18:05
alexML
but the recorder probably does it instead
18:05
Bertl
yes, the shogun does the conversion and compression
18:06
Bertl
so, what I think we should avoid is abrupt changes in the image where there are none
18:06
alexML
right
18:06
Bertl
because they have a good chance to get compressed the wrong way :)
18:07
Bertl
we also want to avoid sudden color changes, as they will result in wrong pixels
18:07
Bertl
(again due to the converson/compression)
18:07
alexML
correct
18:08
Bertl
one idea I had (but haven't implemented yet) is to use overlaping bit ranges
18:08
se6astian
sudden color changes = areas with high image frequencies, right?
18:08
Bertl
i.e. send out 11:4 on even frames and 7:0 on odd frames
18:09
Bertl
the problem with that is that 7:0 will produce thos sudden changes
18:09
Bertl
*those
18:09
Bertl
which in turn will mostly affect the lower bits, which is what we want to avoid
18:09
alexML
I'm also afraid that sending 11:4 will place some fairly significant bits in LSB positions (more likely to get affected by some slight blur, sharpening, or whatever the recorder does)
18:10
Bertl
yeah, but that might not be so problematic if we have redundancy
18:10
Bertl
(like the 7:4 from the 7:0)
18:10
alexML
I'm thinking to optimize the bit order numerically, on a test image
18:11
se6astian
what about swapping 7:4 and 3:0 bits in the second image?
18:11
Bertl
I thought about that as well, and while we can do that, it has a number of bad side effects (speculation i.e. untested)
18:11
se6astian
or just outputting 3:0 and pad the LSBs with zeros
18:11
Bertl
consider a 12bit gradient from left to right
18:12
Bertl
i.e. we go from 0 to 4095
18:12
Bertl
everything is extremely smooth
18:12
Bertl
now let's take out the lower 8 bit
18:12
Bertl
and use it for 8bit RGB
18:13
Bertl
this will give 16 ramps from 0 to 255
18:13
Bertl
and 15 problematic points where 255 suddenly changes back to 0
18:14
Bertl
we can be almos certain that the values 255 and 0 will be badly mutilated and become something else like 240/15
18:14
Bertl
*almost
18:15
Bertl
the general problem here is, if we change the bit order or put lower bits in more prominent places, we will drastically increase the number of those "bad points"
18:16
Bertl
and that is for smooth images which we "assume" as typical input
18:17
Gaudis
left the channel
18:17
Bertl
on the other hand, while the codec changes some bits, it is designed to do it in a way not directly visible to the human eye
18:18
se6astian
but the compression algorithmn will likely kill not the 15 problematic points but the areas with small luminosity changes no?
18:18
Bertl
which means that if we create smooth pixel sequences, the codec is forced to be more precise than on huge changes
18:18
se6astian
aka we are fighting against a) sharpening algortihmns and b) the compression
18:18
se6astian
where we need to test if the shogun does sharpening at all first
18:20
Bertl
alexML: there are a number of high resolution photos on the Beta, which have been re-bayered and can be used to test compression and encoding
18:20
alexML
yes, I already started to write a simulation in octave
18:20
se6astian
I think we need to start a todo list for shots to collect with the beta :)
18:21
Bertl
the mimg tool can also generate artificial test patterns (feel free to add your own there)
18:22
Bertl
I think we need to first get an idea what effects the encoding (starting from RGB444 or YCbCr422 later) has and what approaches preserve most information
18:24
se6astian
https://wiki.apertus.org/index.php/AXIOM_Beta_TestsTODO
18:25
se6astian
FPN is likely sensor temperature dependent
18:25
Bertl
there is a script called rectest.sh, which will cycle through the test images with the 8 encodings
18:25
se6astian
so we should also record sensor temperature for 1. and 2. I guess
18:26
Bertl
which can be easily adjusted for new images/patterns and/or encodings
18:26
se6astian
which testimage should we use tomorrow?
18:27
Bertl
if you want to use a live image for tests, there is a script as well, you just have to freeze the live view (fil_reg 15 0)
18:27
Bertl
and then run rectest2.sh (IIRC)
18:29
Bertl
for the TestsTODO, I would suggest to make a number of test chart images (preferably gray sequence) with different ND filters so that we have overlaping ranges
18:30
Bertl
which can be used to calculate the linearity and sensor behaviour on the upper and lower edges
18:30
se6astian
you mean a printed testchart not an mimg right?
18:31
Bertl
yes, I'm talking about snapshots here not HDMI output
18:31
Bertl
(i.e. different pipeline :)
18:34
se6astian
ah you mean that for the gain settings and exposure time changes we make sure to not clip the data, right?
18:36
se6astian
but what mimg should we use for the HDMI rectest.sh recording?
18:38
Bertl
check the rectest.sh script it invokes mimg during the testrun
18:38
Bertl
(with various test patterns)
18:40
se6astian
ah perfect, I thought it just cycles rec modes
18:40
se6astian
right
18:40
se6astian
anything else we should shoot? alexML?
18:41
troy_s
Watch your illuminants. ;)
18:43
alexML
I already have some good samples for this test (the resolution chart, and real-world images from ursa - http://www.magiclantern.fm/forum/index.php?topic=11787.msg158356#msg158356 )
18:43
alexML
so, I'm not sure what else to ask for right now
18:43
se6astian
ok, good
18:44
Bertl
alexML: you should definitely get new sample images since we fixed the sensor registers, thanks to irieger
18:44
alexML
I'm writing a simulation that would evaluate any bit order, on a test image (shuffle the bits, simulate rgb to 422, some blur, some sharpen, maybe some compression, then recover the raw and compare with the original)
18:45
Bertl
(see the one snap shot I uploaded last night)
18:45
alexML
I already downloaded the snap from last night
18:45
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.raw12.xz
18:45
alexML
exposure is much better, but - as I already told to irieger - I would like the black level raised even more (and have a nonzero value in exif)
18:45
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.png (IM simple debayered)
18:45
alexML
reason: there are still pixels clipped to black
18:46
troy_s
Who is the fellow in the thread commenting on color noise?
18:46
troy_s
Strikes me it is challenging to discuss noise while looking at a dump to sRGB with no transform.
18:49
troy_s
Bertl: What was the process for your simple debayer off of the raw 12?
18:51
Bertl
R=r, G=(g1+g2)/2, B=b (from each bayer block)
18:51
Bertl
https://wiki.apertus.org/index.php?title=AXIOM_Alpha_Software#Simple_debayer_with_ImageMagick:
18:53
troy_s
Bertl: Is the image flipped or non?
18:53
Bertl
the flipped line was used
18:56
troy_s
Grr. Can't get the IM to see the file.
18:57
troy_s
Bertl: Tripping an unexpected end of file. Any reason?
18:57
troy_s
(Plane size or something different?)
19:01
troy_s
Bertl: Any idea?
19:01
troy_s
Bertl: I was going to get a quickie matrix out of it.
19:12
troy_s
Bertl: Hit me back when you have a moment. Love to get a quickie debayer.
19:15
Bertl
have you adjusted the -depth 16 to -depth 12?
19:15
Bertl
(the line originally was for raw16 data)
19:17
troy_s
Oh damn duh..
19:18
troy_s
Bertl: Would be super lovely if you would dump tifs at the very least. Not to go into the PNG discussion again. (All of the colour profiling tools can't read PNG)
19:18
Bertl
alexML, se6astian: btw, if you have a preferred bit sequence you want to test with the Beta, just let me know, I can easily add it to the next firmware round
19:19
Bertl
(for testing)
19:19
Bertl
troy_s: just change the .png at the end to .tiff
19:19
Bertl
(and you will get tiffs :)
19:28
troy_s
Any idea what the illuminant white was in the image?
19:28
troy_s
Bertl: I love you.
19:28
troy_s
Bertl: (I used your generated PNG)
19:31
Bertl
alexML, se6astian: i.e., just let me know what bits go where in the two consecutive frames
19:34
alexML
yes, once I'll get a good bit order, I'll let you know; for now, I'm trying to reproduce your test images
19:36
Bertl
okay, no problem
19:40
troy_s
Bertl: Not horrible.
19:40
troy_s
Bertl: You want the XYZ matrix?
19:41
troy_s
Bertl: http://www.pasteall.org/pic/show.php?id=96336
19:42
Bertl
sure
19:42
troy_s
Here's to XYZ
19:42
troy_s
- !<MatrixTransform> {matrix: [0.775918, 0.905383, -0.288160, 0, 0.035324, 1.738325, -0.511805, 0, -0.177910, -0.546866, 3.364549, 0, 0, 0, 0, 1]}
19:42
troy_s
- !<MatrixTransform> {matrix: [3.2404542, -1.5371385, -0.4985314, 0, -0.9692660, 1.8760108, 0.0415560, 0, 0.0556434, -0.2040259, 1.0572252, 0, 0, 0, 0, 1]}
19:42
troy_s
Those are the OCIO transform if anyone wants to use a viewer.
19:43
troy_s
Here's the full stanza... Just add it to Blender or Krita or whatever OCIO enabled thing you have.
19:43
troy_s
- !<ColorSpace>
19:43
troy_s
name: Space - Apertus
19:43
troy_s
family: Spaces
19:43
troy_s
equalitygroup:
19:43
troy_s
bitdepth: 32f
19:43
troy_s
description: |
19:43
troy_s
AdobeRGB compatible space as outlined in the Adobe RGB 1998 specification
19:43
troy_s
isdata: false
19:43
troy_s
allocation: uniform
19:43
troy_s
allocationvars: [0, 1]
19:43
troy_s
to_reference: !<GroupTransform>
19:43
troy_s
children:
19:43
troy_s
- !<MatrixTransform> {matrix: [0.775918, 0.905383, -0.288160, 0, 0.035324, 1.738325, -0.511805, 0, -0.177910, -0.546866, 3.364549, 0, 0, 0, 0, 1]}
19:43
troy_s
- !<MatrixTransform> {matrix: [3.2404542, -1.5371385, -0.4985314, 0, -0.9692660, 1.8760108, 0.0415560, 0, 0.0556434, -0.2040259, 1.0572252, 0, 0, 0, 0, 1]}
19:43
troy_s
That of course assumes a strictly D65 sRGB scene linear reference space
19:43
Bertl
pastebin
19:44
troy_s
http://www.pasteall.org/62621
19:44
Bertl
tx
19:44
troy_s
Bertl: Easy to view in Blender if you add that stanza.
19:44
troy_s
Then load the tif / png at 16 bit and flag the image as Space - Apertus.
19:44
troy_s
I reused my existing Adobe RGB stanza, so the description is obviously wrong.
19:45
troy_s
That is D50 by the way
19:45
troy_s
I probably should have made the synthetic white D65 but alas.
19:46
troy_s
Let me knock out a D65. GIve me a few moments to do the XYZ math.
19:47
dmjnova
left the channel
19:52
troy_s
Bertl: http://www.pasteall.org/62622
19:52
troy_s
That's with an appended syntehtic D65 on it.
19:53
troy_s
(I can't give a more accurate matrix without knowing the illuminant.)
19:55
troy_s
(So that's basically an absolute colorimetric representation in D65, meaning it will look "Warmish" on a D65 display.
19:55
troy_s
(Your reference would need to be chromatically adapted D50 sRGB primaries for it to look neutral white.)
20:02
troy_s
Here's three stanzas, with the last not having any synthetic white appended http://www.pasteall.org/62623
20:03
troy_s
(And a reference JPG as to how it looks http://www.pasteall.org/pic/show.php?id=96340)
20:04
troy_s
(That is with a synthetic D65 appended. Probably not the wisest choice, but alas.)
20:06
troy_s
(No synthetic JPG here http://www.pasteall.org/pic/show.php?id=96342)
20:06
troy_s
Bertl: Image looks like a great starting point though. Much, much, much better than the previous Alpha efforts it seems.
20:07
troy_s
Bertl: I guess irieger's tweaking of the registers had a pretty huge yield.
20:07
Bertl
yes, we are very happy with the progress
20:07
troy_s
Bertl: Would be nice to see a shot with skintones and that matrix.
20:07
troy_s
Bertl: Pretty sure the results would be a very solid entry.
20:08
Bertl
I'm pretty sure se6astian/max will do that in the next few days
20:08
troy_s
se6astian: ^^ have a peek
20:08
troy_s
se6astian: Not a horrible result given the context
20:08
slikdigit_
joined the channel
20:09
troy_s
Bertl: That's also with a suboptimal colour chart as wel
20:09
slikdigit_
left the channel
20:09
troy_s
Bertl: We can do much better obviously.
20:10
Bertl
yeah, of course
20:10
Bertl
but I thought it would be better than no image at all :)
20:10
troy_s
Bertl: Hard to know how that matrix would hold up as there isn't a huge bit of variation in the subject matter to really test it's limits.
20:11
troy_s
Bertl: But for a 24 chart patch, I have to say that the simple matrix holds up pretty well across all of the swatches - much better than the previous Alpha.
20:11
troy_s
Bertl: Is it just me or is there odd flaring going on there?
20:13
Bertl
there was no specific lighting, it is just sitting on a pedestal in the office under flourescent
20:14
Bertl
so, conditions are primitve, we need images under well defined conditions to evaluate that
20:21
troy_s
Bertl: It would be most excellent if you can give me an idea of the linearization lut.
20:21
troy_s
That is, I'd be able to create a proper OCIO configuration if we can get a sense of the LUT for values to radiometric values
20:21
troy_s
(ratios)
20:21
troy_s
Right now, it's display referred.
20:23
Bertl
for raw data the linearization LUT in the Beta is off
20:23
Bertl
(currently)
20:23
Bertl
i.e. the data you got is the raw sensor data without any modification
20:25
troy_s
Bertl: So that is 'just roughly linear'
20:25
irieger
troy_s: will shoot some exposure chart tomorrow to analyse the signal further. can throw it in here
20:25
troy_s
irieger: Would lvoe it.
20:25
troy_s
irieger: I'd be able to craft a scene linear LUT then, which would give us a much better idea of the dynamic range as well as make it useful for post.
20:26
irieger
that's what I planned for tomorrow ;-)
20:27
irieger
after some further play with the black offset and fpn-stuff ...
20:27
alexML
troy_s: if it helps, I can give you the offset that gives consistent color in the gray patches
20:28
alexML
for this test chart, the black level that does this is 18
20:28
alexML
(so, subtract 18 from all values)
20:28
troy_s
alexML: That should be a byproduct of the basic XYZ transform actually
20:28
troy_s
alexML: You can't just offset
20:29
troy_s
irieger: The delta e wasn't super, but we can't expect much given the circumstances.
20:31
troy_s
alexML: Make sense?
20:31
troy_s
(No shame if it doesn't, we are all just bumbling clowns here.)
20:31
alexML
troy_s: raw data usually has some constant offset on it (on Canons it's 2048)
20:31
alexML
you subtract it before you apply the matrix stuff
20:31
troy_s
alexML: Sure, but that offset is related to the noise floor.
20:32
troy_s
alexML: But you can't rely on an offset to balance.
20:32
alexML
yes, and I just tried to guess that offset for this particular file
20:32
alexML
on Canons, if the offset is wrong, you get a color cast
20:32
troy_s
I'm pretty sure that LMS will properly calculate the XYZ coords regardless.
20:32
troy_s
Because the offset would be consistent.
20:33
troy_s
I'd need to triple check that though.
20:33
alexML
so, I picked the offset that minimizes this color cast on the gray patches (as in, all of them would give basically the same color)
20:33
troy_s
alexML: But you don't know what the colour space is
20:33
troy_s
alexML: So your guess is wrong.
20:33
troy_s
alexML: You are inferring that R=G=B=Achromatic, which is absolutely false in this instance.
20:34
troy_s
alexML: Because we do not know the colour space of the camera, so the RGB values are arbitrary.
20:34
Oscar___
joined the channel
20:34
troy_s
There is no color cast.
20:34
troy_s
Either.
20:34
alexML
nope, I don't assume that
20:34
troy_s
What you are looking at is basically a "hey here's some data" dumped randomly to a (typically) sRGB screen
20:34
troy_s
There is absolutely nothing that you can infer about colour from that image.
20:34
troy_s
Nothing.
20:35
alexML
I only assume that, from a radiometrically linear raw data, if red/green and blue/green ratio are constant, they all give the same hue on the output (whatever that might be)
20:35
troy_s
The only reference point is that colour chart, and that is wound up with the XYZ positions for the various swatches (which in the case of a low quality chart such as a passport, you don't even get a spectro measured one)
20:35
troy_s
You don't know the primaries.
20:35
troy_s
You can't assume that about the ratios
20:35
alexML
so, I find the black level that minimizes the stdev of these ratios
20:36
troy_s
The _only_ time that applies is if you are in a colour space that has been rationalized with an achromatic axis where R=G=B=achromatic
20:36
troy_s
Which takes plenty of care to craft.
20:36
troy_s
Given that sensor, there's exactly zero chance that the ratios do that.
20:40
troy_s
(I believe that Canon adds that offset so you don't get corndogged on the transform and keep more or less positive values always. Some footage will deliver negative values after the transform, which can be a problem in compositing or other things if one doesn't take care to assert that the negative values are dealt with correctly.)
20:53
Oscar___
left the channel
21:28
troy_s
Bertl: Please remember that is a D50 aligned matrix. I haven't done the math to convert it to D65.
21:31
morrigan1
joined the channel
22:10
se6astian
I am off to bed
22:11
se6astian
changed nick to: se6astian|away
23:16
Bertl
off now ... bbl
23:16
Bertl
changed nick to: Bertl_oO
23:20
irieger
changed nick to: irieger|away
23:43
pozitron
left the channel