Current Server Time: 06:41 (Central Europe)

#apertus IRC Channel Logs

2015/12/08

Timezone: UTC


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