00:01 | SashaC | joined the channel | |
01:30 | Bertl | off for a nap ... bbl
| |
01:31 | SashaC | rest well Bertl
| |
03:35 | troy_s | Bertl: FANTASTIC Bertl !!!
| |
03:35 | troy_s | Bertl: I have been slugging on the Axiom lab app... no matrix yet. :(
| |
03:35 | troy_s | Bertl: 12 mean error is crap. You can use profcheck to get DE values
| |
03:36 | troy_s | Bertl: DE 1.0 is undetectable. (less than)
| |
03:36 | troy_s | Bertl: Use DE2000
| |
03:36 | troy_s | (our current matrices are probably de 14 :))
| |
03:36 | troy_s | (as in crap)
| |
05:51 | Bertl | back now ...
| |
05:53 | Bertl | so you've been giving me crap all the time :)
| |
06:08 | troy_s | Bertl: Always.
| |
06:08 | Bertl | appreciate it, but seriously, any idea what the problem with the calibration is?
| |
06:09 | Bertl | gabe hat similar issues with similar results (like 12-15%)
| |
06:09 | troy_s | Bertl: To be fair, all Gabe and I do is take the crap you two give us and reshape it into different crap. Lulz.
| |
06:09 | troy_s | Bertl: Well he and I were using your shot
| |
06:09 | troy_s | Bertl: Which is inconsistently lit (top to bottom) and sub exposed.
| |
06:09 | Bertl | okay, so let's say that one is crap, no problem with that, why don't we get better results with new shots?
| |
06:10 | troy_s | Bertl: Se6's are very exhaustive
| |
06:10 | troy_s | Bertl: But I haven't seen them debayered with VNG yet. I was going to kill two birds and use the lab.
| |
06:10 | Bertl | and as you say, uneven lighting, could this be the main issue?
| |
06:11 | troy_s | Bertl: Because Gabe didn't see them yet (I remember Se6 taking the shots, but I hadn't looked)
| |
06:11 | troy_s | Bertl: It is also a scanner image.
| |
06:11 | troy_s | Bertl: So we may be fighting a few things.
| |
06:11 | Bertl | okay, we haven't found a 'camera' chart yet
| |
06:11 | troy_s | Bertl: 1) Lack of daylight shot. We couldn't do it previously as the prototype was hard mounted.
| |
06:12 | Bertl | IIRC, somebody suggested to send us one, but then didn't
| |
06:12 | troy_s | 2) Chart might be decayed and likely sub optimal due to scanner.
| |
06:12 | troy_s | (I think Se6 bought a new one)
| |
06:12 | Bertl | sebastian has a new IT8 chart, yes
| |
06:12 | troy_s | 3) I haven't twiddled enough yet.
| |
06:12 | Bertl | it is again a 'scanner' chart, as they do not sell anything else AFAIC
| |
06:13 | Bertl | *AFAIK
| |
06:13 | troy_s | Hrm. Wolf had a camera chart I thought.
| |
06:14 | Bertl | maybe but please double check with sebastian, I had a quick look at the ITU docu, and it doesn't really differentiate between scanner or camera
| |
06:14 | troy_s | C1
| |
06:14 | troy_s | http://www.targets.coloraid.de
| |
06:14 | Bertl | they only have reflective and non-reflective charts
| |
06:14 | troy_s | Yep
| |
06:14 | Bertl | and IIRC, your suggestion was to take the reflective one
| |
06:14 | troy_s | I am unsure. I suspect the camera charts have some anti-yellowing twinges to pull the illuminant to more neutral
| |
06:15 | Bertl | on the page you linked: Wolf Faust is manufacturing reflective and transmissive scanner calibration targets
| |
06:15 | troy_s | Well a glossy chart has a wider gamut, but more difficult to shoot.
| |
06:15 | troy_s | Yes look at C1
| |
06:15 | troy_s | Bertl: But again, we are miles away from a high grade calibration
| |
06:16 | troy_s | Bertl: Eventually a Hutch or something would probably be something to aim for.
| |
06:16 | troy_s | Bertl: I just want to get to a 2de zone
| |
06:16 | Bertl | yes, I agree, but it annoys me that we do not even have a basic 'working' calibration
| |
06:16 | troy_s | Which is more than satisfactory for me.
| |
06:16 | troy_s | Bertl: Part of it is me. I need to do calibs on the new images.
| |
06:16 | troy_s | Bertl: If you can tiff 16 that link se6 sent us
| |
06:16 | Bertl | btw, the matrix you gave last time has coefficients up to 12
| |
06:17 | troy_s | I will do some more tests tomorrow
| |
06:17 | troy_s | Bertl: Exposure proble.
| |
06:17 | Bertl | that looks somewhat fishy to me with 'red' around 2 or so
| |
06:17 | troy_s | I had one that had correct exposure, but the mean error was 13.9
| |
06:17 | troy_s | Which is bad
| |
06:17 | Bertl | i.e. first, I presume it needs to be inverted/transposed
| |
06:17 | troy_s | Basically our chart shot stinks
| |
06:18 | troy_s | But seb's new ones look exhaustibe
| |
06:18 | troy_s | exhaustive
| |
06:18 | Bertl | but still, that means that green/red or red/green is a factor of 6, which is almost a magnitude higher?
| |
06:18 | troy_s | With well noted color temp etc. I want to generate a neutral (as in color temp is achromatic equal channel)
| |
06:18 | troy_s | Well the curves are wonk
| |
06:19 | troy_s | Relatively smooth, but wonk
| |
06:19 | troy_s | which I _think_ is because our chart shot sucked
| |
06:19 | troy_s | Linear 16 bit TIFFs of the new batch would be excellent
| |
06:20 | troy_s | The software lab is still a ways off.
| |
06:20 | troy_s | (much dickery to get things working for forward thinking items)
| |
06:20 | troy_s | (EG: An image cache for multiple frames, scrubbing, scrobbling image, etc.)
| |
06:21 | troy_s | I have about 98% of that done, just need to cooy / paste some code.
| |
06:21 | troy_s | Then I can do up some OCIO configs and we are home free.
| |
06:21 | troy_s | A viewer app that will spit out TIFFs and EXRs and DPXs with full color management.
| |
06:21 | Bertl | just use the raw16 and convert them like this:
| |
06:22 | Bertl | convert \( -size 4096x3072 -depth 16 gray:IT8_incand.raw16 \) \( -clone 0 -crop -1-1 \) \( -clone 0 -crop -1+0 \) \( -clone 0 -crop +0-1 \) -sample 2048x1536 \( -clone 0,1 -average \) -delete 0,1 +swap -combine IT8_incand.tiff
| |
06:22 | troy_s | Crappers.
| |
06:22 | troy_s | What does sample do?
| |
06:22 | troy_s | That is some IM fu there.
| |
06:22 | Bertl | reduce the pixels to separate the bayer pattern
| |
06:23 | troy_s | How does it interp the RGGB mosaic?
| |
06:23 | Bertl | this is a simple/primitive debayer, we have it on the wiki since I came up with that
| |
06:23 | Bertl | i.e. it overlays R,(g1+g2)/2,B
| |
06:23 | troy_s | Genius boy.
| |
06:24 | troy_s | Are the greens at the same gain?
| |
06:24 | Bertl | there is a small variation if you have flipped images
| |
06:24 | troy_s | Ok I will do that now.
| |
06:24 | Bertl | convert \( -size 4096x3072 -depth 16 gray:colors_500ms.raw16 \) \( -clone 0 -crop -1-1 \) \( -clone 0 -crop -1+0 \) \( -clone 0 -crop +0-1 \) -sample 2048x1536 \( -clone 2,3 -average \) -delete 2,3 -swap 0,1 +swap -combine colors_500ms.tiff
| |
06:25 | Bertl | this is for flipped ones, which should be the default now as it gives 'normal' looking images :)
| |
06:25 | Bertl | i.e. if the first one looks wrong, take the second one :)
| |
06:25 | troy_s | Which ones are flipped?
| |
06:25 | troy_s | And why?
| |
06:25 | troy_s | (Haven't been following the transitions.)
| |
06:25 | Bertl | the sensor can do image flipping, horizontal and vertical
| |
06:26 | troy_s | Does that change the RGGB alignment?
| |
06:26 | Bertl | in the beginning, I turned that off, so the early images are not flipped
| |
06:26 | troy_s | (Asking because my debayer will obviously need to know)
| |
06:26 | troy_s | Need a bash script to do that.
| |
06:26 | troy_s | Hrm...
| |
06:26 | Bertl | yes, the pattern is flipped as well, i.e. RGGB becomes GBRG
| |
06:26 | troy_s | Ok. I guess I'll include all debayers then
| |
06:27 | troy_s | Is there a simple bash script on the wiki?
| |
06:27 | troy_s | I'm going to decode them all.
| |
06:27 | Bertl | bash script for what exactly?
| |
06:27 | troy_s | (Does Imagemagick try to apply a tone curve to the data or does it dump the raw linear values?)
| |
06:27 | troy_s | To convert the images.
| |
06:27 | Bertl | well, the lines I pasted here are all you need
| |
06:28 | Bertl | they are listed here for reference: https://wiki.apertus.org/index.php?title=Axiom_Alpha_Software#Simple_debayer_with_ImageMagick:
| |
06:28 | troy_s | Converting batch 3 now.
| |
06:28 | troy_s | (Not sure the difference in batches.)
| |
06:28 | SashaC | left the channel | |
06:28 | Bertl | and AFAIK, imagemagic doesn't apply anything unless you specify extra spaces
| |
06:28 | Bertl | which you can easily do
| |
06:29 | Bertl | (e.g. with -colorspace)
| |
06:30 | troy_s | Well that thing was riddled with bugs
| |
06:30 | Bertl | a good way to check is with the test pattern
| |
06:30 | troy_s | I can't count the number of forum posts.
| |
06:30 | Bertl | let me see if I have that uploaded somewhere
| |
06:30 | troy_s | I only care about linear
| |
06:30 | troy_s | If you can do a quick test that'd be awesome.
| |
06:30 | Bertl | yes, the test pattern is 0 1 2 3 4 5 ... 127, then 1 2 3 4 5 ... 128 ...
| |
06:30 | troy_s | (The PNGs I have _no_ way of knowing, but I do know that PNGs are enforced sRGB so any tool should actually be assuming a transfer curve.
| |
06:31 | Bertl | so it should be easy to check with a histogram on the resulting tiff
| |
06:31 | troy_s | With the test pattern raw data sample?
| |
06:31 | Bertl | yep
| |
06:31 | troy_s | Where's the tester?
| |
06:32 | troy_s | (Is the Hist tool listed on the wiki?)
| |
06:32 | troy_s | (By the way, OIIO has some image buffer algos that are at least as effective, plus OIIO is specifically crafted for scene referred images - a great toolset for this project.)
| |
06:33 | troy_s | (I did a test with a DNG by loading it as a tiff (rename) then resaving it as a TIFF. Worked great. In fact, probably the easiest way to get to a DNG by supplying tags. Yet to test this though)
| |
06:33 | troy_s | I see the hist command on the wiki
| |
06:33 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/RAW/test_pattern.raw16.xz
| |
06:34 | Bertl | if you like, I can also create an artificial one with full gray range
| |
06:34 | Bertl | (this one is the actual built in sensor test pattern)
| |
06:35 | troy_s | Damn. Looks full frame
| |
06:35 | troy_s | But something is wrong methinks.
| |
06:35 | troy_s | (Slightly rotated, but Argyll can deal with that)
| |
06:35 | troy_s | Colors look whack. Green. Would that be wrong flip?
| |
06:36 | Bertl | probably, try the other line
| |
06:37 | Bertl | since a few days I've been playing with the HDMI output now, and I've added a shuffle unit to rearrange the bit pattern, you wouldn't believe how 'good' wrong colors can look :)
| |
06:37 | troy_s | That's it.
| |
06:38 | troy_s | Should write a quickie bash script that does both commands and toggles based on a CLI param.
| |
06:38 | troy_s | Shuffle does what Bertl?
| |
06:38 | Bertl | you could actually figure out the right one from the register dump at the end
| |
06:39 | Bertl | @shuffle, do you want a technical explanation or a simple one?
| |
06:42 | troy_s | Bertl: How about a middle ground.
| |
06:43 | troy_s | Bertl: A technical explanation for someone with an IQ of about 40.
| |
06:43 | Bertl | okay, let's try: it cuts a packed 64bit word into 4bit pieces and rearranges the order according to a configureable scheme
| |
06:45 | Bertl | so for example, 0123456789ABCDEF -> 01245689ACDE37BF
| |
06:46 | Bertl | this allows to accomodate the different formats the HDMI chip understands, but it also allows to swap channels
| |
06:47 | Bertl | so for example, swapping one green with the red channel gives really cool images :)
| |
06:48 | Bertl | pure green becomes yellow, red becomes green, yellow gets more orange, blue stays the same
| |
06:48 | troy_s | Damn. Having an error with scanin
| |
06:56 | troy_s | Odd
| |
06:56 | troy_s | Rotate is sucking
| |
06:56 | troy_s | convert foo.tiff -rotate 10 foobar.tiff
| |
06:56 | troy_s | is giving me tif_dirwrite.c TIFFWriteDirectoryTagCheckedRational: Assertion 'value>=0.0' failed.
| |
06:57 | Bertl | try with png? :)
| |
06:57 | troy_s | Again, PNG is junk. Argyll won't read it and it cannot be linear.
| |
06:57 | troy_s | :)
| |
06:58 | Bertl | try with .png, then convert it to tiff
| |
06:58 | Bertl | I presume imagemagick tries to be smart and not rotate the image at all
| |
06:58 | troy_s | And what's betting Imagemagick will convert the transfer curve?
| |
06:58 | Bertl | i.e. just specify a magic tiff tag that it is rotated
| |
06:58 | troy_s | Huh?
| |
06:58 | troy_s | I don't get it.
| |
06:58 | troy_s | WriteDirectoryTag is an odd one.
| |
06:59 | Bertl | I presume, one of the many tiff tag says, rotate this image by N degree
| |
06:59 | Bertl | and so, imagemagick being lazy does not want to rotate it at all, just sets a flag, this image needs to be rotated by N degree
| |
07:00 | Bertl | and as this is not well tested/your tools are out of date, it causes an obscure error
| |
07:03 | Bertl | it should be simple to check the transfer curve theory, by converting a tiff to png and back to tiff, then comparing the two tiff images (original and converted one)
| |
07:03 | troy_s | GRRRRR WHY is it failing loading the IT8 reference chart values in the Argyll dir????
| |
07:03 | troy_s | Grr.
| |
07:24 | troy_s | About to give up
| |
07:24 | troy_s | Bertl: I can't seem to crop the blasted images down to the chart only and get the rotate decent
| |
07:24 | troy_s | Imagemagick is a gongshow nightmare of segfaults
| |
07:24 | Bertl | what version/OS do you use?
| |
07:25 | troy_s | I'm on a Linux
| |
07:25 | troy_s | And god I hate it.
| |
07:25 | Bertl | and why not process it in steps as suggested and only convert the image at the end to tiff?
| |
07:25 | troy_s | (I've come to hate Imagemagick. So crap)
| |
07:25 | troy_s | I've been trying that.
| |
07:26 | troy_s | But the crop function is crap
| |
07:26 | Bertl | maybe you use it wrong or misinterpret what it does?
| |
07:26 | troy_s | -crop 1841x1305+149+116
| |
07:26 | troy_s | No. It's pretty much crap.
| |
07:27 | troy_s | Crop should give you a window (if you follow it with a !) that is widthxheight+xoffset+yoffset
| |
07:27 | Bertl | maybe add +repage ?
| |
07:27 | Bertl | http://www.imagemagick.org/Usage/crop/
| |
07:28 | Bertl | also be careful with unescaped '!' on a (ba)sh
| |
07:29 | Bertl | http://www.imagemagick.org/Usage/crop/#crop_repage
| |
07:29 | troy_s | Done the repage
| |
07:29 | troy_s | Keeps telling me no image is left
| |
07:29 | troy_s | (and I always escape it)
| |
07:30 | Bertl | okay, can you give me the complete command you are trying?
| |
07:30 | Bertl | note that the command you used before might have left an image with offsets
| |
07:30 | Bertl | check that with 'file <image>'
| |
07:31 | Bertl | (because you were missing the +repage before)
| |
07:32 | Bertl | no, sorry, check with:
| |
07:32 | Bertl | identify <image>
| |
07:32 | Bertl | it might show you an offset +x+y on the input image
| |
07:32 | Bertl | thus the specified crop region might be outside the actual image data
| |
07:33 | troy_s | Hold.
| |
07:33 | troy_s | First I did a crap dump to PNG because ImageMagick sucks donkey ween.
| |
07:33 | troy_s | Then I cropped using:
| |
07:33 | troy_s | convert ./out.png -crop 181x135+149+116\! +repage ./test-crop.png
| |
07:33 | troy_s | and that shits the bed
| |
07:34 | troy_s | (I actually wanted a much larger image, but it too shits the bed in ways only Imagemagick can)
| |
07:34 | troy_s | convert ./out.png -crop 1841x1305+149+116\! +repage ./test-crop.png
| |
07:34 | troy_s | Super Bed Shit.
| |
07:34 | troy_s | So frustrating.
| |
07:36 | troy_s | Format: TIFF (Tagged Image File Format)
| |
07:36 | troy_s | Class: DirectClass
| |
07:36 | troy_s | Geometry: 2084x1584+0+0
| |
07:36 | troy_s | So the resolution is larger than my crop window.
| |
07:41 | troy_s | God. I. Hate. The. Tools.
| |
07:43 | troy_s | Yay bugs
| |
07:43 | troy_s | I think I have negotiated it
| |
07:43 | troy_s | What junk
| |
07:45 | troy_s | Spoke. Too. Soon.
| |
07:45 | Bertl | well, I can't complain here, it works just fine for me, it is not one of the most intuitive tools out there but in my experience it gets the job done
| |
07:45 | Bertl | so maybe upload a complete script from .raw16 to your problem then I can take a look
| |
07:47 | troy_s | And ARGYLL BUG
| |
07:47 | troy_s | This is so awesome.
| |
07:47 | troy_s | Good luck... Here's what I've tried to do:
| |
07:48 | troy_s | (I got the buggy shitbag of IM to finally crop and rotate the image)
| |
07:48 | Bertl | btw, if you just want to cut out the chart, it is simple to do with the perspective transform
| |
07:48 | troy_s | Take seb's 3rd set of images
| |
07:48 | Bertl | just find the 4 corner points and use them as input
| |
07:48 | troy_s | 1) I randomly picked the 15ms
| |
07:49 | troy_s | 2) Rotate it and crop it or use the perspective tool.
| |
07:49 | troy_s | 3) Generate a tiff.
| |
07:49 | troy_s | (linear)
| |
07:49 | troy_s | then try scanin -v -G1.0 ./test.tiff /usr/share/color/argyll/ref/it8.cht ~/Develop/raws/R100604.txt
| |
07:49 | Bertl | can you do an md5sum <image> for me?
| |
07:49 | Bertl | so that we have the same source .raw16 image
| |
07:50 | troy_s | 7ffcf417c906fccaf180d739a9d484af
| |
07:50 | troy_s | ls
| |
07:51 | troy_s | scanin will either segfault (using repository Argyll) or bail out.
| |
07:51 | troy_s | Which is... well wrong.
| |
07:51 | Bertl | 7ffcf417c906fccaf180d739a9d484af IT8-tungsten-halogen-Run03-9.1.2014/IT8-tungsten-halogen-Run03-9.1.2014-15ms.raw16
| |
07:51 | troy_s | That's the one.
| |
07:51 | troy_s | 15ms.
| |
07:55 | troy_s | Bertl: Perspective is top left, top right bottom left bottom right?
| |
07:59 | Bertl | yes
| |
07:59 | Bertl | -distort Perspective '254,144 48,48 1876,188 2000,48 233,1242 2000,1488 1854,1275 48,1488' should work
| |
08:00 | Bertl | nope, sorry
| |
08:00 | troy_s | Why 48,48?
| |
08:00 | troy_s | Why not just scale it to original size?
| |
08:01 | Bertl | -distort Perspective '254,144 48,48 1876,188 2000,48 1854,1275 2000,1488 233,1242 48,1488'
| |
08:01 | Bertl | because that gives the correct source for the perfect chart :)
| |
08:01 | troy_s | at 2000x1488?
| |
08:02 | Bertl | yes, I wanted a border reference of 48 pixels
| |
08:02 | troy_s | read_line is erroring for me on scanin
| |
08:03 | troy_s | ARRGGGHHHHHHHFFHFHFHFHFFUFUUUU
| |
08:04 | troy_s | scanin: Error - CGATS file '/home/aphorism/Develop/raws/R100604.txt' read error : Read line got symbol
| |
08:04 | troy_s | '��������������������������������¿����������ü��������������������������������������������������������������������������������������������������������
| |
08:04 | troy_s | ��������������������������������������������������������������������������Ŀ�������������������������������������������������������������������������
| |
08:04 | troy_s | ���������������������������������������������������������������������������������������������������������������������������������������������������ï¿
| |
08:04 | troy_s | ½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï
| |
08:04 | troy_s | ¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½
| |
08:04 | troy_s | ���������������������������������������������������������������������������������������������������������������������������������������������������ï¿
| |
08:04 | troy_s | ½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½' that's too long
| |
08:04 | troy_s | That's a great error.
| |
08:04 | Bertl | convert \( -size 4096x3072 -depth 16 gray:IT8-tungsten-halogen-Run03-9.1.2014/IT8-tungsten-halogen-Run03-9.1.2014-15ms.raw16 \) \( -clone 0 -crop -1-1 \) \( -clone 0 -crop -1+0 \) \( -clone 0 -crop +0-1 \) -sample 2048x1536 \( -clone 0,1 -average \) -delete 0,1 +swap -combine +repage -distort Perspective '254,144 48,48 1876,188 2000,48 1854,1275 2000,1488 233,1242 48,1488' IT8-tungsten-halogen-Run03-9.1.2014/IT8-tungsten-halogen-Run03-9.1.2014-15ms_c
| |
08:05 | Bertl | here, that gives the tiff you want without any problems
| |
08:06 | troy_s | apparently a bugger on larger images
| |
08:06 | troy_s | Trying smaller.
| |
08:06 | troy_s | Still bombing.
| |
08:07 | Bertl | and scanin runs fine, results are here:
| |
08:07 | troy_s | Good god.
| |
08:07 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/RAW/IT8-tungsten-halogen-Run03-9.1.2014-15ms_cut.ti3
| |
08:07 | troy_s | All of my Argyll's die
| |
08:07 | troy_s | Now try this on that result:
| |
08:08 | Bertl | http://pastebin.com/wnnYJs94
| |
08:08 | troy_s | colprof -v -D"Berts Camera Matrix" -qh -am -u tungsten-halogen-RunBLAHBLAHBLAH (without the ti3)
| |
08:09 | Bertl | Matrix = 0.107625 1.044939 -0.850347 -0.150982 1.577119 -1.062272 -0.256328 0.420066 1.000908
| |
08:09 | Bertl | Profile check complete, peak err = 58.453423, avg err = 17.580975
| |
08:09 | troy_s | Error
| |
08:09 | troy_s | Fuuuuuu
| |
08:09 | troy_s | I'd need to check on how underexposed it is.
| |
08:09 | troy_s | That's the quickie version.
| |
08:10 | troy_s | If you batch that on all of the images
| |
08:10 | troy_s | I'd be interested in the lowest mean
| |
08:12 | troy_s | Bertl: This is the command to generate meaningful delta e's - which again, 1.0 or less is the discernable to average standard observer
| |
08:13 | troy_s | Bertl: profcheck -v 2 -k input.ti3 outputicc.icc
| |
08:13 | troy_s | and you can plot the curves using
| |
08:13 | troy_s | xicclu -g -f b output.icc
| |
08:14 | troy_s | -U in the colprof will apply a linear multiplier to get to 100 L
| |
08:14 | troy_s | (Which is basically needed to 'stretch' the values to the full range)
| |
08:14 | troy_s | a near perfect profile will show you three curves
| |
08:15 | troy_s | from 100 to 100
| |
08:19 | troy_s | Odd how fanned out the blasted curves are (Got mine to work)
| |
08:20 | troy_s | Likely due to the Tungsten source methinks.
| |
08:21 | troy_s | Average DE 10.5
| |
08:21 | troy_s | LOL
| |
08:21 | troy_s | That's ... uh... not good.
| |
08:25 | troy_s | Bertl: I'm going to bed it. You can also plop the values into Calc and read them (start at the row with the values and use spaces to separate)
| |
08:25 | troy_s | Bertl: That will give you some idea as to the readings.
| |
08:25 | Bertl | http://pastebin.com/FjHgjt8A
| |
08:26 | Bertl | so you already picked the best one :)
| |
08:26 | troy_s | Fluke
| |
08:26 | troy_s | Egads.
| |
08:26 | troy_s | I think we desperately need a Daylight shot to really figure out what is going on.
| |
08:27 | troy_s | (Properly exposed)
| |
08:27 | troy_s | I was JUST looking at the RGB values
| |
08:27 | guest | if that chart made a curve in blue or what i have noticed you talked about, then with linear matrix you are getting big errors, or does the error relate to a 3d lut ?
| |
08:27 | troy_s | and coincidentally the Greens are coming in at 99.977 which was a flukey guess
| |
08:27 | troy_s | Did you plot them using xicclu?
| |
08:27 | troy_s | You can see three fanned out curves
| |
08:27 | troy_s | I suspect our lighting sucks ass.
| |
08:28 | Bertl | guest: yes that would definitely explain the error, but nobody could explain those error values to me (yet)
| |
08:28 | troy_s | Bertl: Again, use profcheck
| |
08:28 | guest | what about running calibration on my chart, to see how much does it differ (e.g. problem of a source/exposure)
| |
08:28 | troy_s | Bertl: DE is a known idea of value - where < 1.0 is not discernable. > 1.0 is.
| |
08:29 | troy_s | guest: I have a hunch it's crap lighting or a decayed chart or... who knows.
| |
08:29 | guest | troy_s: but the number is linear (e.g. %) or logarithmic (like bits / dB)
| |
08:29 | guest | that is the most interesting question about DE
| |
08:29 | philippej | joined the channel | |
08:29 | Bertl | profcheck gives me a usage message
| |
08:30 | troy_s | guest: Google DE2000 or DE76
| |
08:30 | troy_s | Bertl: Using the commands I listed?
| |
08:30 | Bertl | ah, it needs the icc, where do I get the icc from?
| |
08:30 | troy_s | profcheck -v2 -k foo.ti3 foo.icc
| |
08:30 | troy_s | Bertl: Look in the directory
| |
08:31 | troy_s | Bertl: It will have created the ICC (matrix format) in there after colprof.
| |
08:31 | troy_s | :)
| |
08:31 | troy_s | scanin reads the chart
| |
08:31 | troy_s | colprof creates the color profile
| |
08:31 | Bertl | http://pastebin.com/5rBxi7W6
| |
08:31 | troy_s | xicclu is an xwindows icc look up
| |
08:31 | troy_s | and profcheck we.... profile checkers
| |
08:32 | troy_s | try -v2
| |
08:32 | troy_s | no space
| |
08:32 | Bertl | nice
| |
08:32 | troy_s | ?
| |
08:32 | Bertl | yep, that does it
| |
08:33 | troy_s | Your average Delta-E 2000 is 10.529ish
| |
08:33 | troy_s | Si?
| |
08:33 | Bertl | give really nice curves
| |
08:33 | troy_s | I _think_ that is largely due to the Tungsten
| |
08:33 | troy_s | And perhaps the metamerism is causing a nightmare for the chart.
| |
08:34 | Bertl | red starts on 200 wossname, and goes down to zero on whatnot
| |
08:34 | troy_s | I don't recall it being that bad with pure tungsten light.
| |
08:34 | troy_s | But that tungsten is pretty damn warm
| |
08:34 | troy_s | Yes
| |
08:34 | troy_s | And a well behaved profile should have smooth curves like that
| |
08:34 | Bertl | blue around 75 wossname and also down to 0 whatnot
| |
08:34 | troy_s | but closer together
| |
08:34 | troy_s | not stacked
| |
08:34 | troy_s | and about 100 to 100
| |
08:34 | troy_s | guest: Delta-E 2000 is more perceptual based
| |
08:35 | troy_s | guest: Meaning that the errors are biased toward perception and particular hue ranges
| |
08:35 | Bertl | no idea, what does that plot tell me?
| |
08:35 | troy_s | That the curves are decent
| |
08:35 | troy_s | (as in the curve responses aren't abnormal aside from the values they are showing)
| |
08:35 | Bertl | okay, so that is the profile curve, yes?
| |
08:35 | troy_s | The color of the light illuminating the chart can cause the colors to reflect their saturation values wrongish.
| |
08:35 | troy_s | That's the profile curves.
| |
08:36 | philippej | would it be related to the fact that the sensor seems to provide better daylight images without correction? That tungsteen creates too much distortion vs sensor "native" white balance (I know it's not the proper term), and that when daylight is done, you can compute tungsteen ?
| |
08:37 | troy_s | philippej: The sensor _always_ needs a profile
| |
08:37 | Bertl | tungsten should really be a 'smooth' spectral light, i.e. no fancy peaks anywhere
| |
08:37 | guest | where is the picture (jpeg is enough) of the chart you try to use ?
| |
08:37 | philippej | or said otherwise, that the chart should be done with daylight
| |
08:37 | troy_s | philippej: What you are seeing is in fact random when you view the data dumped directly to a near-sRGB display.
| |
08:37 | troy_s | philippej: There is no such thing as meaningful RGBs - RGB by definition is a relative color model.
| |
08:37 | guest | philippej: unless the values are clipped, it is fine even if it is warm
| |
08:37 | troy_s | philippej: Meaning that you _must_ account for the primaries. Always.
| |
08:38 | Bertl | guest: it is a normal IT8 chart
| |
08:38 | troy_s | guest: Normally. But again, malformed light can twist the values into what amounts to what humans see as metamerism - some colors lose their color due to white point / color of the source.
| |
08:38 | philippej | still it looks more correct (or needing less corection) when it's daylight. What you call "damn warmish" :-)
| |
08:38 | troy_s | philippej: That's just the wrong way to think of color.
| |
08:38 | troy_s | philippej: It's why I prefer to show people in XYZ
| |
08:38 | troy_s | philippej: Because the models mean nothing. RGB is just Foo, Bar, Blick.
| |
08:39 | guest | Bertl: i meant the shot you pass to the color detector.. export it please to quickly viewable form
| |
08:39 | troy_s | philippej: Because it HAPPENS to sort of kind of look sort of kind of like a reddish tint
| |
08:39 | troy_s | philippej: Means nothing.
| |
08:39 | troy_s | philippej: That's just random chance garbage.
| |
08:39 | troy_s | guest: Hold.
| |
08:39 | troy_s | bear in mind this is a literal dump of the image to sRGB so what you are seeing is random
| |
08:40 | guest | i know, i want to check for other things for which i have made my calibs to take a week (in terms of exposing the chart correctly , and I still have no perfection in that )
| |
08:40 | guest | -i
| |
08:40 | troy_s | guest: It's not that hard.
| |
08:41 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/RAW/IT8-tungsten-halogen-Run03-9.1.2014-15ms.jpg
| |
08:41 | troy_s | guest: and the most ideal
| |
08:41 | troy_s | guest: Is to tweak the values using a spradsheet
| |
08:41 | Bertl | I also uploaded the profile results
| |
08:41 | troy_s | to 'idealize' the scales
| |
08:41 | troy_s | I can explain that if you'd like, but likely tomorrow
| |
08:41 | troy_s | (You effectively will end up creating an achromatic white - perfectly scaled RGB)
| |
08:41 | troy_s | http://www.pasteall.org/pic/show.php?id=66837
| |
08:43 | guest | bad exposure, col 15 is mostly 0xFF
| |
08:43 | guest | in reds
| |
08:46 | troy_s | Shiiit
| |
08:46 | troy_s | Bertl: -i
| |
08:46 | troy_s | dammit
| |
08:46 | troy_s | colprof can take the illuminant
| |
08:46 | Bertl | guest: gives different values when sampled manually
| |
08:47 | troy_s | guest: scanin samples across mean
| |
08:47 | Bertl | troy_s: okay, so what command now?
| |
08:48 | troy_s | IIRC
| |
08:48 | troy_s | -i A
| |
08:48 | guest | those patches are clipped, so you cant do a calibration with that shot
| |
08:48 | troy_s | (Which SHOULD be illuminant A)
| |
08:48 | troy_s | (Aka 2848k)
| |
08:48 | troy_s | guest: They are NOT clipped
| |
08:48 | troy_s | guest: That's an 8 bit dump
| |
08:48 | troy_s | and I have no idea where you are seeing clips
| |
08:49 | troy_s | That's also a linear dump.
| |
08:49 | guest | split the image to R/G/B planes, and check in the red, col. 15
| |
08:49 | troy_s | guest: That's an 8 bit dump.
| |
08:49 | guest | except few bottom patches, they all are full
| |
08:49 | troy_s | HUH?
| |
08:56 | Bertl | http://vserver.13thfloor.at/Stuff/AXIOM/RAW/IT8-tungsten-halogen-Run03-9.1.2014-15ms_perfect.png
| |
08:57 | troy_s | Some patches suck ass
| |
08:57 | troy_s | pastelink.me/dl/a8778e
| |
08:57 | troy_s | that's the ODS of the data
| |
08:57 | Bertl | the 'tiff' version is still uploading (slightly larger :)
| |
08:57 | troy_s | you can see the swatches and the readings
| |
08:57 | troy_s | Bertl: Is there a 12 ms?
| |
08:57 | troy_s | guest: pastelink.me/dl/a8778e
| |
08:57 | troy_s | guest: CHANGE YOUR HANDLE TO YOUR DAMN NAME
| |
08:57 | troy_s | guest: YOU AREN'T A GUEST ANY MORE
| |
08:57 | troy_s | Lulz.
| |
08:57 | guest | :)
| |
08:58 | Bertl | yes, there is a 12ms version :)
| |
08:58 | troy_s | Bertl: Check out that ODS. Guest _does_ have a point with the heavy exposure on the red channel, but that said, the others worry me more (the higher DE versions)
| |
08:59 | guest | so lets see if it helps, reconnect
| |
08:59 | guest | left the channel | |
08:59 | troy_s | Ideally we'd love to see a 5400k
| |
08:59 | daniel | joined the channel | |
08:59 | daniel | thats luck
| |
09:00 | daniel | changed nick to: Guest32211
| |
09:00 | Guest32211 | ahh
| |
09:00 | Guest32211 | changed nick to: danieeel
| |
09:00 | Bertl | weeelcome danieeel! :)
| |
09:00 | danieeel | hello :)
| |
09:01 | troy_s | Greets
| |
09:01 | Bertl | I have to leave for a little, grab my snail-mail, bbs
| |
09:01 | troy_s | danieeel: http://trumpetpower.com/photos/Exposure#Normalizing_exposure
| |
09:01 | troy_s | That's also a useful linky on normalizing.
| |
09:04 | danieeel | troy_s: can metamerism happen with tungsten?
| |
09:04 | troy_s | In humans. :)
| |
09:05 | troy_s | But it adversely impacts reproduction of all colours to some extent as I understand it.
| |
09:05 | troy_s | (Shooting a red swatch in a blue light for example)
| |
09:05 | danieeel | but tungsten is not blue light.. is shall have all wavelenghts (unless those shots lack true blue)
| |
09:06 | danieeel | i did my calibration on cloudy sunlight
| |
09:07 | danieeel | what are the column names in the ODS file ?
| |
09:09 | troy_s | danieeel: Too blue
| |
09:09 | troy_s | danieeel: If you do it in cloud, your sky taints the kelvin.
| |
09:09 | troy_s | danieeel: ICCs are all based around D50
| |
09:10 | troy_s | danieeel: No matter what light you pick, you will bias the color swatches
| |
09:10 | danieeel | my point was rather to get correct images under skylight
| |
09:11 | troy_s | danieeel: Shoot in direct sun then, in a covered area
| |
09:11 | troy_s | danieeel: You want to eliminate the blue sky
| |
09:11 | troy_s | danieeel: And use only the 5400 sun.
| |
09:12 | jucar | left the channel | |
09:12 | troy_s | danieeel: XYZ RGB to answer your next question
| |
09:13 | danieeel | with that i can not yet find a location which is not colored - it would need to be some skate field or some grayins surroundins to do it correctly
| |
09:13 | danieeel | grayish
| |
09:18 | se6astian | joined the channel | |
09:35 | danieeel | se6astian: any chance to stop by in Prague for a quick image comparison ?
| |
09:36 | se6astian | good morning
| |
09:36 | se6astian | ah nice, I see you dont consider yourself a guest only anymore
| |
09:36 | se6astian | we can ask the pilot of our flight to berlin if he would mind a little detour ;P
| |
09:40 | danieeel | pull your camera and shout the correct words, they might instantly land :)
| |
09:42 | troy_s | Night all.
| |
09:42 | troy_s | danieeel: I'll step you through normalizing tomorrow
| |
09:42 | troy_s | danieeel: You basically take the XYZ values, figure out the multipliers and scale them all
| |
09:43 | troy_s | danieeel: Then add two sets of data for Black and White (reverse engineer 100, 0, 0 Lab to XYZ)
| |
09:43 | troy_s | Ok... nacht.
| |
09:55 | philippej | left the channel | |
09:59 | jucar | joined the channel | |
10:04 | jucar | left the channel | |
10:05 | jucar | joined the channel | |
10:09 | se6astian | left the channel | |
10:10 | jucar | left the channel | |
10:10 | jucar | joined the channel | |
10:28 | Bertl | back now ...
| |
10:40 | se6astian | joined the channel | |
11:02 | Bertl | wb se6astian!
| |
11:20 | se6astian | good morning :)
| |
15:23 | Bertl | off for a nap ... bbl
| |
15:39 | philippej | joined the channel | |
15:51 | se6astian | hey philippej
| |
15:58 | philippej | left the channel | |
16:14 | gwelkind | joined the channel | |
16:46 | philippej | joined the channel | |
16:53 | philippej | left the channel | |
17:16 | philippej | joined the channel | |
17:57 | se6astian | time to leave
| |
17:57 | se6astian | see you
| |
17:57 | se6astian | left the channel | |
18:12 | troy_s | Morning all.
| |
18:13 | troy_s | Bertl: Back for monkey work for a bit.
| |
18:13 | troy_s | Greets also to the regular peeps philippej danieeel gwelkind etc.
| |
18:21 | troy_s | danieeel: If you are around, I can try to explain how to normalize your whites (Essentially Wrong Von Kries AFAICT)
| |
18:21 | troy_s | danieeel: Which leads to exceptional profiles (even with WVK aka XYZ scaling)
| |
18:21 | danieeel | i do not need to (yet) - found another issue
| |
18:21 | troy_s | danieeel: I'd suggest at least trying it. You will A) learn much and B) end up with the 'best' profile you can manage from the given limitations.
| |
18:23 | danieeel | anybody else interested? or we let them to read back from logs?
| |
18:23 | troy_s | Bertl: As an aside, a ColorChecker 24 swatch shot (Aka Macbeth) would be excellent to baseline our issues against (as opposed to single point of failure on an IT8)
| |
18:24 | troy_s | danieeel: I suspect very few would be.
| |
18:24 | troy_s | danieeel: It's sort of ++ thinking.
| |
18:24 | troy_s | (and logs are decent.)
| |
18:24 | troy_s | You asked what was going on with that TI3 chart
| |
18:24 | danieeel | i thought of simpler charts too.. but I ended up with HCT
| |
18:24 | troy_s | It's basically what you were doing sample picking, only a little more reliable and a little more uniform
| |
18:24 | troy_s | HCT is ideal
| |
18:24 | troy_s | More swatches = Better idea
| |
18:25 | troy_s | But more swatches also will reveal more inconsistencies
| |
18:25 | danieeel | so hit me, i give up on rgb-ycbcr yet - lets continue with that later.
| |
18:25 | troy_s | (Making LUTs more considerate of inconsistencies, but also more prone to potentail errors based on photograph of chart for example)
| |
18:25 | troy_s | LOL
| |
18:25 | troy_s | RGB YCbCr isn't nearly as complex as this.
| |
18:25 | danieeel | it is not working realtime with existing software :)
| |
18:26 | troy_s | (Two relative color models. Dead simple if you focus on that. One with by-the-book scaling if you are going to call it 709)
| |
18:26 | troy_s | Erf.
| |
18:26 | troy_s | Good times.
| |
18:26 | danieeel | i wanted to stream live.. its failing on this conversion
| |
18:26 | troy_s | So the TI3
| |
18:26 | danieeel | ok so..
| |
18:26 | troy_s | See that spreadsheet I posted?
| |
18:26 | danieeel | yes
| |
18:26 | danieeel | column names pleas
| |
18:26 | troy_s | Did I include the column names?
| |
18:26 | danieeel | no
| |
18:26 | troy_s | Do you have Calc handy or another spreadsheet?
| |
18:27 | danieeel | oocalc
| |
18:27 | danieeel | line 1 is A01 patch
| |
18:27 | danieeel | what is that patch/swatch difference?
| |
18:29 | troy_s | danieeel: Have you done any scanin or colprof?
| |
18:29 | troy_s | danieeel: Because when you do a scanin, you get a ti3 file
| |
18:29 | troy_s | I can post one if you don't have one.
| |
18:29 | danieeel | no
| |
18:30 | troy_s | danieeel: Save this and label it as TI3.
| |
18:30 | danieeel | ok
| |
18:30 | troy_s | http://pastebin.com/JXmZWnJ8
| |
18:31 | troy_s | danieeel: And to be clear, you are aware of the differences between RGB and XYZ (relative vs absolute and unscaled)
| |
18:31 | danieeel | sort of
| |
18:32 | troy_s | (XYZ is technically a "scene referred" absolute color model. See J. Selan's PDF on cinematic color if you still don't quite understand scene referred versus display referred (http://cinematiccolor.com))
| |
18:32 | troy_s | RGB is always relative.
| |
18:32 | troy_s | Taking values is meaningless.
| |
18:32 | danieeel | we have discussed that last time - and I have managed to make a xyz to sRGB converter to visualize my chart
| |
18:32 | troy_s | If I give you any display referred RGB values, you cannot replicate the color without asking what the primaries are (which is part of defining a color space)
| |
18:32 | troy_s | Clear?
| |
18:33 | troy_s | So when someone says "I have RGB values 1.0, 0.324, and 0.4333" it means _nothing_
| |
18:33 | danieeel | relative as - you need the specific color of color filters (primaries) on the display to make up the absolute color
| |
18:33 | troy_s | (Similar to saying some other stupid statement like "This is in linear color space!" Linear is an _attribute_ of a color space, not a color space. RGB is an attribute of a color space (the _model_) not a color space.)
| |
18:33 | danieeel | i think we are clear
| |
18:34 | troy_s | display referred = places special meaning on a 'maximum' value - generally 1.0 (or whatever the bit depth permits). Sometimes called output referred.
| |
18:35 | troy_s | scene referred = places no special value on the data range. Represents the 'reality' of the physics of the environment. Range is 0 to theoretical infinity.
| |
18:35 | danieeel | that is ok
| |
18:35 | troy_s | scene referred will be _linear_ data, meaning that if you want to go up a stop, double the values. Down a stop, halve them.
| |
18:36 | danieeel | display referred is before or after the transfer curve?
| |
18:36 | troy_s | display referred values _may_ be linearized. If you linearize display referred data, you are _always_ trapped in the 'max' range, and will arrive at linearized values by inverting the tone response / transfer curve.
| |
18:36 | troy_s | display referred is an attribute of the data
| |
18:36 | troy_s | 0..1 is always display referred
| |
18:37 | troy_s | device referred. display referred. output referred.
| |
18:37 | troy_s | All the same essentially
| |
18:37 | troy_s | they have a minimum and a maximum.
| |
18:37 | troy_s | So... quick tangent
| |
18:37 | danieeel | ok
| |
18:38 | troy_s | When we ship values to our display, are they display referred?
| |
18:38 | danieeel | yes
| |
18:38 | troy_s | Yes. And if we shipped display linear values to a display, will they display correctly?
| |
18:39 | danieeel | if you can set on it an linear input curve
| |
18:39 | troy_s | It won't.
| |
18:40 | troy_s | Because you are shipping linear values and your display is LDR.
| |
18:40 | danieeel | LDR?
| |
18:40 | troy_s | Low Dynamic Range.
| |
18:40 | troy_s | So your value .5 is not _half_ of the value output of 1.0 if you ship it directly.
| |
18:40 | troy_s | So your eye won't see it as the linearized values were in 'the real world'.
| |
18:41 | troy_s | Hence the need for a transfer curve.
| |
18:41 | troy_s | To 'cheat' the values
| |
18:41 | troy_s | danieeel: Sense?
| |
18:42 | troy_s | IF we had some UberTV, and the level of luminance were Uber(tm), we could in theory ship linearized values directly to the display
| |
18:42 | troy_s | and they would display in the same ratios as real-world physics.
| |
18:43 | danieeel | we should make a real example - tell me if that is correct
| |
18:43 | troy_s | Here's a simple example
| |
18:43 | troy_s | You go out and manually make a real world image in greyscale
| |
18:43 | danieeel | we ship 0-255 to our displays, as this is how the "linear" scale is percieved
| |
18:43 | troy_s | so you take a spot meter and meter every single 'pixel'
| |
18:43 | troy_s | we record the results
| |
18:43 | troy_s | and we are going to use linearized values
| |
18:44 | troy_s | so say the side of the barn is f2.0
| |
18:44 | troy_s | and the grass is f2.4
| |
18:44 | troy_s | (one stop hotter)
| |
18:44 | troy_s | (the grass is)
| |
18:44 | troy_s | If we used value 0.3 for our barn side
| |
18:44 | troy_s | (arbitrary)
| |
18:44 | troy_s | grass is .6
| |
18:44 | troy_s | If we did this for every pixel in the scene, we'd have a greyscale image in theory.
| |
18:44 | troy_s | danieeel: With me so far?
| |
18:45 | danieeel | yes of course
| |
18:45 | troy_s | danieeel: If we record those to a file, and we decide 1.0 is our upper limit
| |
18:45 | danieeel | i have got my linear data, and used a lut to view them correctly, in terms of intensity
| |
18:45 | troy_s | We have a display linear greyscale image.
| |
18:45 | troy_s | If we dump that file to the display
| |
18:46 | troy_s | it will look 'dark' because the values will not
| |
18:46 | troy_s | (when they are displayed) maintain the physical real-world ratios
| |
18:46 | troy_s | and our eyes won't see it as the ratios were in reality.
| |
18:46 | troy_s | danieeel: Clear?
| |
18:46 | troy_s | so key points:
| |
18:46 | danieeel | of course, have experienced that
| |
18:46 | troy_s | 1) display linear vs scene linear
| |
18:46 | troy_s | 2) display referred versus scene referred
| |
18:47 | troy_s | 3) absolute color models (xyY, XYZ, etc.) versus relative color models (RGB, YCbCr, etc.)
| |
18:47 | troy_s | Clear on all those points?
| |
18:47 | danieeel | so scene linear: render of a lamp, with true values of big intensities
| |
18:48 | danieeel | display linear: trim/crop/clip that to some usable max value
| |
18:48 | danieeel | good?
| |
18:48 | troy_s | danieeel: A scene referred image of a typical landscape with sun in the frame would have ranges from extreme low levels in shadows, to extremely MASSIVE numbers of the sun itself.)
| |
18:48 | troy_s | bingo.
| |
18:48 | troy_s | You got it!
| |
18:48 | troy_s | And the reasons for noting these differences are large.
| |
18:48 | troy_s | As you will hopefully see in hindsight ages later.
| |
18:48 | troy_s | So
| |
18:48 | danieeel | now.. the referred - it points to two sides of the transfer curve?
| |
18:49 | troy_s | XYZ
| |
18:49 | danieeel | as a point of conversion between scene/linear to display/curved
| |
18:49 | troy_s | It is A) an absolute color model
| |
18:49 | troy_s | B) scene referred (and hence scene linear)
| |
18:49 | troy_s | (Correct, but also in more subtle ways I'll try to touch on if you remind me after this quickie TI3 investigation)
| |
18:50 | troy_s | Clear on XYZ?
| |
18:50 | troy_s | (or at least those two facets of it.)
| |
18:50 | danieeel | in scene linear, the Z is any number
| |
18:50 | troy_s | They are all any numbers
| |
18:50 | troy_s | :)
| |
18:50 | troy_s | As you increase intensity of a color, all three vectors grow.
| |
18:50 | troy_s | Clear?
| |
18:50 | danieeel | xy usually being 0..1 no? :)
| |
18:50 | troy_s | Whoa! DIFFERENT MODEL FRIEND!
| |
18:51 | troy_s | Clear on XYZ as per A and B above?
| |
18:51 | danieeel | "increase intensity of a color" is very unspecific what you mean - saturation / brightness?
| |
18:51 | troy_s | danieeel: No, increase intensity.
| |
18:51 | troy_s | The side of the barn
| |
18:51 | troy_s | if we increase the intensity of the side of the barn
| |
18:51 | troy_s | XYZ all grow
| |
18:52 | troy_s | Up to infinity
| |
18:52 | troy_s | Clear?
| |
18:52 | troy_s | Think of it as three vectors that grow upwards and outwards like a pyramid (infinitely large base) on its head.
| |
18:52 | danieeel | okay, assume that. (not used to it yet) so continue
| |
18:53 | troy_s | A straight line down to the tip of the pyramid in any direction is a 'color'. Increasing the intensity of the color (the scene referred ratio) will move the color up and outward (unless it is perfectly in the center of the pyramid)
| |
18:53 | troy_s | XYZ is a unique model
| |
18:53 | troy_s | Which was deduced in 1931 by the CIE
| |
18:53 | troy_s | Using three lights.
| |
18:53 | troy_s | A red light
| |
18:53 | troy_s | a green light
| |
18:53 | troy_s | and a blue light
| |
18:53 | troy_s | with SPECIFIC colors
| |
18:54 | troy_s | (RGB model is relative. The primaries are fixed when using lights.)
| |
18:54 | troy_s | (That is, for RED for example, the color does not CHANGE as it increases in intensity.
| |
18:54 | troy_s | likewise, red 0.0001 on our display is the SAME 'color' as it is at 1.0
| |
18:54 | troy_s | Clear?
| |
18:54 | danieeel | yes
| |
18:54 | troy_s | The CIE used three lights
| |
18:55 | troy_s | and showed swatches of colors in a 2 degree field
| |
18:55 | troy_s | observers tried to match the colors in the swatches
| |
18:55 | troy_s | The CIE also chose primaries such that equal amounts of light pulled directly away from the other color.
| |
18:55 | troy_s | This forms a TRIANGLE at the base
| |
18:56 | troy_s | extending up in a warped fashion if you tried to view it in 3D.
| |
18:56 | troy_s | SOME swatches however, could not be matched using the three lights.
| |
18:56 | troy_s | They were OUT OF THE GAMUT.
| |
18:56 | troy_s | And so the researchers added small amounts of the primaries to the swatch values (thereby decreasing their saturation INTO gamut)
| |
18:56 | troy_s | until the observer could find a reasonable match
| |
18:57 | troy_s | By figuring out how much the observer added AND paying attention to how much THEY added to the swatches, they could fix the 'actual' color position relative to the smaller gamut three RGB primaries.
| |
18:57 | troy_s | Is this clear?
| |
18:57 | troy_s | (the transform of color in the real world is a simple thing - it is just a transform because all the values are linear as per energy laws)
| |
18:58 | troy_s | Are you clear on this danieeel?
| |
18:58 | troy_s | Or something not quite clear?
| |
18:58 | danieeel | trying to visualize it
| |
18:58 | troy_s | See a swatch in front of you
| |
18:58 | troy_s | You have THREE lights, RED, GREEN and BLUE of FIXED chromaticity (color)
| |
18:58 | troy_s | you can dial up the lights
| |
18:58 | troy_s | or down the lights
| |
18:58 | troy_s | When I show you some colors, you can't reach them!
| |
18:59 | troy_s | (the greenest of green things simply isn't the same green as your light)
| |
18:59 | troy_s | So I can desaturate the swatch green
| |
18:59 | troy_s | by adding RED and BLUE of my lights
| |
18:59 | troy_s | until you can match it.
| |
18:59 | troy_s | Clear?
| |
18:59 | danieeel | so if i have a very green swatch, on a poor green light, it will be percieved poor
| |
18:59 | troy_s | By POOR we need to be explicit
| |
18:59 | troy_s | the color is not saturated
| |
19:00 | troy_s | We can make it deadly deadly bright
| |
19:00 | troy_s | and it will be the same green
| |
19:00 | troy_s | The more saturated green is simply unreachable.
| |
19:00 | troy_s | Clear?
| |
19:00 | troy_s | So your three lights can't replicate the green
| |
19:00 | troy_s | So we need to figure out a way to replicate it and figure out what the green was
| |
19:00 | danieeel | because they are poor :) the green is not enough greenish
| |
19:00 | troy_s | So I 'reel it in' by adding RED and BLUE
| |
19:00 | danieeel | so clear
| |
19:01 | troy_s | Ok
| |
19:01 | troy_s | So we gather up our data
| |
19:01 | troy_s | and we have our ORIGINAL three CIE RGB values
| |
19:01 | troy_s | which form a triangle and a strange looking mesh as we work upward to 'white'
| |
19:01 | troy_s | Clear on this?
| |
19:01 | troy_s | PLUS we have all of the 'outside' stuff
| |
19:01 | troy_s | Which extend beyond the legs of the triangle
| |
19:02 | danieeel | yes
| |
19:02 | troy_s | The problem is, our RGB values go from 0 to .... HEY THAT'S REALLY BRIGHT
| |
19:02 | troy_s | So we need to scale all the values
| |
19:02 | troy_s | When we scale them in
| |
19:02 | troy_s | We can create a finite 'map' of the colors
| |
19:02 | troy_s | Which would be again, our CIE RGB triangle
| |
19:03 | troy_s | AND the stuff that 'pours over' beyond it.
| |
19:03 | troy_s | And that forms... something... that ... looks like...
| |
19:03 | troy_s | https://www.google.ca/search?q=cie+rgb&client=ubuntu-browser&tbm=isch&imgil=EkYw_LbmADWVaM%253A%253Bhttps%253A%252F%252Fencrypted-tbn0.gstatic.com%252Fimages%253Fq%253Dtbn%253AANd9GcTnqnu6Wco6Bmw67wRIlQ_iiRqa-cMrReaTA2H-50PNmqzgWoF_IQ%253B325%253B345%253BSKRQ9HbFToIhFM%253Bhttp%25253A%25252F%25252Fen.wikipedia.
| |
19:03 | troy_s | org%25252Fwiki%25252FCIE_1931_color_space&source=iu&usg=__PVA0sud8qse4CMkY1BYQPrCrkdQ%3D&sa=X&ei=Ccj_UoWXHZDjoAToh4CgAw&ved=0CDAQ9QEwAQ&biw=1145&bih=786#facrc=_&imgdii=_&imgrc=EkYw_LbmADWVaM%253A%3BSKRQ9HbFToIhFM%3Bhttp%253A%252F%252Fupload.wikimedia.org%252Fwikipedia%252Fcommons%252Fthumb%252F6%252F60%252FCIE1931xy_CIERGB.svg%252F325px-CIE1931xy_CIERGB.svg.png%3Bhttp%253A%252F%252Fen.wikipedia.
| |
19:03 | troy_s | org%252Fwiki%252FCIE_1931_color_space%3B325%3B345
| |
19:03 | troy_s | Grr.
| |
19:03 | danieeel | display the final image and post its link
| |
19:03 | troy_s | http://upload.wikimedia.org/wikipedia/commons/thumb/6/60/CIE1931xy_CIERGB.svg/325px-CIE1931xy_CIERGB.svg.png
| |
19:04 | troy_s | The BIGGER map
| |
19:04 | troy_s | is 'scaled' RGB values (actually another model we are almost at.)
| |
19:04 | troy_s | the TRIANGLE are the CIE lights (the primaries)
| |
19:04 | troy_s | and the stuff that escapes
| |
19:04 | troy_s | are the out of CIE RGB gamut values that were transformed back to their original positions.
| |
19:04 | troy_s | So... see the bluey green area? That's escape
| |
19:04 | danieeel | okay so in practice:
| |
19:05 | troy_s | There is much more slight escape in magenta / orangey
| |
19:05 | troy_s | (look closely)
| |
19:05 | danieeel | if we were to take 3 (r/g/b) lasers, the triangle would extend to the side of the colored area
| |
19:05 | troy_s | The EDGES of that triangle
| |
19:05 | danieeel | but once we use 3 not so saturated lights or filters, the triangle is all inside
| |
19:05 | troy_s | are the mix points
| |
19:06 | troy_s | So equal intensity GREEN and RED are the MIDDLE of that line
| |
19:06 | troy_s | With NO blue
| |
19:06 | troy_s | that is the full line
| |
19:06 | troy_s | same goes for the other legs
| |
19:06 | troy_s | Sense?
| |
19:06 | danieeel | that is simple, my point was somewhere else
| |
19:06 | troy_s | Yes... but there's a tricky thing to that chart
| |
19:06 | troy_s | It is a SCALED version of the primaries
| |
19:06 | troy_s | the chart is like looking DOWN on that pyramid
| |
19:07 | troy_s | Which is a little bit of a mind warp, but stay with me.
| |
19:07 | danieeel | like - more up you are, smaller the triange?
| |
19:07 | troy_s | No
| |
19:07 | troy_s | The chart is like grabbing it in a scaling image app
| |
19:07 | troy_s | As we scale it downward, we approach black
| |
19:07 | troy_s | as we scale it upward, we approach infinite intensity
| |
19:07 | troy_s | The vectors grow TOWARDS your eye and OUTWARD
| |
19:08 | troy_s | Just like scaling the image
| |
19:08 | troy_s | No matter how much you increase the intensity of the three primaries
| |
19:08 | troy_s | the out of gamut is always outside it
| |
19:08 | troy_s | The 'intentisy' of the light grows upward and outward
| |
19:08 | troy_s | danieeel: Clear?
| |
19:08 | troy_s | (I'll link to a video after this to visualize it)
| |
19:08 | danieeel | okay, fine with that
| |
19:08 | troy_s | So the researchers had a dilemma
| |
19:09 | troy_s | They could use RGB and have negative R, G, and B values to represent human standard observer vision
| |
19:09 | troy_s | (Which is a nightmare as you can imagine)
| |
19:09 | troy_s | or they could 'normalize' them
| |
19:09 | troy_s | into a lovely consistent triangle
| |
19:09 | troy_s | So they did this
| |
19:09 | troy_s | The 'BLUE' however
| |
19:09 | troy_s | would be at 0 0 in that chart
| |
19:09 | danieeel | negative rgb meant that swatch after-painting when it could not be matched, right?
| |
19:09 | troy_s | the 'RED' would be at way the hell off the chart
| |
19:10 | troy_s | the GREEN is way up top off the chart
| |
19:10 | troy_s | Forming a unique triangle
| |
19:10 | troy_s | The issue with this system is that it creates "imaginary" primaries
| |
19:10 | troy_s | they don't exist in the real world
| |
19:10 | troy_s | we cannot craft any light that is of the color those 'fake' primaries are.
| |
19:10 | troy_s | danieeel: Clear?
| |
19:10 | troy_s | Look at that chart again to see the triangle I speak of.
| |
19:10 | danieeel | yes
| |
19:11 | troy_s | So... it isn't RGB... we need a new name for it...
| |
19:11 | troy_s | Let's call it XYZ
| |
19:11 | troy_s | Where X is our fake RED, Y is our fake GREEN, and Z is our fake BLUE
| |
19:11 | danieeel | ah
| |
19:11 | troy_s | And while we are making this model, we could bend the values a wee bit and isolate intensity across the board as purely Y
| |
19:11 | troy_s | (But remember, it isn't that simple, all colors grow UP and OUTWARD)
| |
19:12 | danieeel | so as the Z is the blue thing, the top of the pyramid gets finally white
| |
19:12 | troy_s | Nope
| |
19:12 | troy_s | A) no such thing as white
| |
19:12 | troy_s | B) the XYZ model is infinitely large
| |
19:12 | danieeel | that E point, is it for equivalence?
| |
19:12 | troy_s | C) Each X, Y, and Z are TWO coordinates
| |
19:12 | troy_s | (Well three technically)
| |
19:12 | troy_s | We are inside a 3D space, NOT a 2D.
| |
19:13 | troy_s | With me so far (I appreciate there are outstanding questions... hopefully it will become clearer)
| |
19:13 | troy_s | So we have a NEW system
| |
19:13 | danieeel | so 3D XYZ is not that image, that is clear
| |
19:13 | danieeel | how does it get mapped to 2D XY?
| |
19:13 | troy_s | XYZ that we can express ALL possible standard observer colors (last point is critical - change the observer and this model sucks)
| |
19:13 | troy_s | Now to TALk about color
| |
19:13 | troy_s | we can SCALE the model
| |
19:13 | danieeel | wait
| |
19:13 | troy_s | so that we can uniquely LOOK at it on paper like our chart here
| |
19:14 | danieeel | XYZ can represent any color of any intensity
| |
19:14 | troy_s | see the lowercase x and y?
| |
19:14 | troy_s | Yes.
| |
19:14 | troy_s | All color
| |
19:14 | troy_s | Absolutely.
| |
19:14 | troy_s | (as in 'absolute model' not 'yes absolutely)
| |
19:14 | danieeel | by color i usually understand chromacity
| |
19:14 | troy_s | If we SCALE the X and Y channels
| |
19:14 | troy_s | we can map all possible intensities to a finite chart
| |
19:14 | troy_s | (again, think scaling the image in a 2D processor)
| |
19:15 | troy_s | As we scale the image UP, that's our intensity increasing
| |
19:15 | troy_s | but the relative distances will always be the same
| |
19:15 | troy_s | so we can scale the X and Y axis
| |
19:15 | troy_s | !
| |
19:15 | troy_s | which leads us to the FIRST subset model
| |
19:15 | troy_s | xyY
| |
19:15 | troy_s | Which is SCALED X, SCALED Y, and UNSCALED Y
| |
19:15 | troy_s | (hence lowercase and uppercase)
| |
19:15 | troy_s | THAT is your answer.
| |
19:16 | troy_s | So the chart we are looking at is scaled x, scaled y, and unscaled Y (Growing upward to our face, which completely FLATTENS the 2D image we are looking at - there is no more 'pyramid' because we have scaled the XYZ model in a unique way)
| |
19:16 | troy_s | danieeel: PHEW is that clear?
| |
19:17 | danieeel | that is possible because XY keeps its shape limited to that outside curve (annotated by wavelengts)
| |
19:17 | troy_s | well kind of
| |
19:17 | troy_s | remember - the three vectors travel from a single point if we were looking down
| |
19:18 | danieeel | xy is decoupled from XY by the scale of Y ...
| |
19:18 | troy_s | UP towards our eye and OUTWARD
| |
19:18 | troy_s | Yes.
| |
19:18 | danieeel | so what is lost from XYZ -> xzZ ?
| |
19:18 | troy_s | Simple scale
| |
19:18 | troy_s | xyY
| |
19:18 | troy_s | Y is luminance.
| |
19:18 | troy_s | PUre
| |
19:18 | troy_s | you cannot do it any other way
| |
19:18 | danieeel | ah, i forgot
| |
19:18 | danieeel | no longer Z
| |
19:18 | troy_s | If you are looking at the pyramid, the overall intensity of the light grows UPWARD (toward the wide base)
| |
19:18 | troy_s | but not all colors are at the same luminance
| |
19:19 | troy_s | (Greens and yellows live higher up for example to reds and blues)
| |
19:19 | troy_s | but the chart lets you visualize the 'color' separate from the intensity.
| |
19:19 | troy_s | and by having xyY (where Y is unbounded in theory)
| |
19:19 | troy_s | we can easily get our Z and z back.
| |
19:19 | troy_s | (basic fill-in-the-blank algebra
| |
19:19 | troy_s | danieeel: This clear or muddy as hell?
| |
19:20 | danieeel | it is perfectly clear now
| |
19:20 | troy_s | Great
| |
19:20 | troy_s | So XYZ is a relative or absolute color MODEL?
| |
19:20 | danieeel | absolute
| |
19:20 | troy_s | xyY?
| |
19:20 | danieeel | should be absolute too
| |
19:21 | troy_s | Yep
| |
19:21 | danieeel | it is derived from XYZ wihout using any external constants/data
| |
19:22 | troy_s | RGB?
| |
19:22 | danieeel | which RGB? :))
| |
19:22 | danieeel | RGB is relative to what the actual R,G,B is
| |
19:22 | troy_s | Bingo
| |
19:22 | troy_s | How about... uh... CIE RGB?
| |
19:23 | danieeel | that can do all colors.. but does it mean it is absolute?
| |
19:23 | troy_s | danieeel: Simpler question
| |
19:23 | troy_s | Is CIE RGB relative or absolute?
| |
19:24 | troy_s | (worry not about range or gamut)
| |
19:24 | danieeel | relative to those lamps CIE used
| |
19:24 | troy_s | Absolute
| |
19:24 | danieeel | why is that
| |
19:24 | troy_s | the CIE primaries are well known and well documented
| |
19:24 | troy_s | So when I say CIE RGB values Foo, Bar, Bing
| |
19:24 | danieeel | that is cheating :)
| |
19:24 | troy_s | You know precisely what chromaticity the result is.
| |
19:24 | danieeel | sRGB primaries are also well documented
| |
19:24 | troy_s | How about sRGB?
| |
19:24 | troy_s | Indeed.
| |
19:25 | danieeel | okay, so absolute is anything specific
| |
19:25 | troy_s | and it too is an absolute (of course, intensity aside for all of these RGB models)
| |
19:25 | danieeel | relative is just a format
| |
19:25 | troy_s | Yes.
| |
19:25 | danieeel | like - YCbCr ... relative
| |
19:25 | troy_s | Bingo
| |
19:25 | danieeel | 709 / 601 / 2020 absolute
| |
19:25 | troy_s | Bingo.
| |
19:25 | troy_s | Exactly.
| |
19:25 | troy_s | Relative models until you state which one.
| |
19:25 | troy_s | Phew.
| |
19:25 | troy_s | Ok.
| |
19:25 | troy_s | Soooooo
| |
19:25 | troy_s | TI3
| |
19:25 | troy_s | Did you download that one?
| |
19:25 | danieeel | yes
| |
19:25 | troy_s | See the column headers?
| |
19:26 | danieeel | yes, filled in the ODS file
| |
19:26 | troy_s | FIRST three are XYZ
| |
19:26 | troy_s | SECOND three are RGB
| |
19:26 | troy_s | THIRD three are error calcs.
| |
19:26 | troy_s | danieeel: Clear?
| |
19:27 | troy_s | The FIRST TWO sets of THREE columns we care about.
| |
19:27 | troy_s | So... what are the primaries of the RGBs in the file?
| |
19:27 | troy_s | (Trickier questions... :) )
| |
19:27 | danieeel | cie?
| |
19:27 | troy_s | (What do you think the RGB values are measurements of?)
| |
19:27 | troy_s | LOL
| |
19:27 | troy_s | They are arbitrary.
| |
19:27 | troy_s | They are in fact literal values of the RGB from the file
| |
19:27 | troy_s | Which are unknown
| |
19:28 | danieeel | those are the values from the sensor?
| |
19:28 | troy_s | So how can scanin deliver XYZ values from them?
| |
19:28 | troy_s | Yep.
| |
19:28 | danieeel | strange to appear in the middle :)
| |
19:28 | troy_s | (Or photo or whatever)
| |
19:28 | troy_s | So how does scanin know XYZ values for the swatch then??????
| |
19:29 | danieeel | xyz can come from reference data of the chart by series
| |
19:29 | troy_s | Yes. And white point here is elephant in the room
| |
19:29 | danieeel | that are the 3 columns before RGB
| |
19:29 | troy_s | ICC illuminant is ALWAYS D50 in the PCS
| |
19:29 | troy_s | (Profile connection space)
| |
19:29 | troy_s | So the "What should this XYZ value be" is calculated based on D50 formulas.
| |
19:29 | troy_s | And XYZ is aboslute
| |
19:30 | troy_s | Absolute even.
| |
19:30 | troy_s | And the values are LINEARIZED
| |
19:30 | troy_s | so the ratios can be manipulated accordingly.
| |
19:30 | troy_s | (For the RGBs)
| |
19:30 | danieeel | seems to be in 0..100 range
| |
19:30 | troy_s | Yep.
| |
19:30 | troy_s | Because they have to have an upper limit
| |
19:30 | troy_s | (Sensor, display whatever.)
| |
19:31 | troy_s | Quick note
| |
19:31 | troy_s | The Horseshoe image
| |
19:31 | troy_s | It is NOT perceptually uniform
| |
19:31 | troy_s | Meaning that if you took a measuring stick
| |
19:31 | troy_s | and measured a color
| |
19:31 | danieeel | 100 is easy if you want to find the 18% gray paper... it should have 18 in it, as this is linear, right?
| |
19:31 | troy_s | in 'distance' away from another color
| |
19:31 | troy_s | is NOT an accurate measurement as to how different it will appear to a standard observer
| |
19:32 | troy_s | You would need MacAdams circles to figure out roughly how 'warped' the model is to a perciever
| |
19:32 | troy_s | (And yes, there are models that take the XYZ CIE research and 'warp' it to be perceptually uniform, see Lab for example.)
| |
19:32 | danieeel | that is clear
| |
19:32 | troy_s | So that the distance across the whole model represents (relatively) how 'different' a color is.
| |
19:33 | danieeel | the relative being to the 2 colors in question
| |
19:33 | danieeel | pretty useless information that distance then
| |
19:34 | troy_s | http://en.wikipedia.org/wiki/File:CIExy1931_MacAdam.png
| |
19:34 | troy_s | So you can sort of see that ranges of reds and greens look JND (just noticable difference)
| |
19:34 | troy_s | Which is a little deceptive
| |
19:35 | danieeel | okay
| |
19:35 | troy_s | because it is easier to see a change in kelvin at say 2000-2100 versus say, 6000-6100 (you couldn't see a difference in the blue)
| |
19:35 | troy_s | Part of the lovely complexity of luminance tied to color.
| |
19:36 | troy_s | danieeel: So the TI3 has the values for the swatches
| |
19:36 | troy_s | danieeel: And we can scale an achromatic one to give us a theoretical 'neutral' (in terms of RGB values)
| |
19:36 | troy_s | danieeel: As well as add a "perfect' black (0,0,0,0,0,0) and a perfect white
| |
19:37 | philippej | left the channel | |
19:37 | troy_s | which allows the profile generator to create a more idealized profile.
| |
19:37 | troy_s | And HOPEFULLY the basics of the ICC system are a little clearer.
| |
19:38 | troy_s | ICC is NOT color management, but rather a form of color management.
| |
19:38 | troy_s | And it has plenty of nuances and details that aren't perfectly obvious.
| |
19:38 | troy_s | If we take our white swatch patch (the one that should be 'bright white' in our display referred model scale)
| |
19:38 | troy_s | we can pipe the values to xicclu
| |
19:39 | troy_s | to get our "perfect" white values in RGB
| |
19:39 | troy_s | (which is interpolated)
| |
19:40 | danieeel | so icc is a matrix and a lut for transfer curve ?
| |
19:41 | troy_s | xicclu -v (verbose) -s 100 (scale it to 0..100) -f if (if is INVERTED and FORWARD) -p l (l is LAB model) -i a (ABSOLUTE colorimetric - no warping) INPUT.ICC
| |
19:41 | troy_s | danieeel: Can be. Can also be a matrix with a LUT for color etc.
| |
19:41 | troy_s | danieeel: Can be plenty of things.
| |
19:41 | troy_s | danieeel: ICCs wrap up the rather confusing FROM and TO assumptions of all color
| |
19:41 | jucar | left the channel | |
19:41 | troy_s | And always have a protocol (which is limiting if you are an artist trying to do things with models and color)
| |
19:42 | troy_s | They always go TO an absolute Profile Connection Space (often XYZ)
| |
19:42 | troy_s | and wrap up assumptions in the protocol (this is why you can have an sRGB ICC profile - it can manage any from and any to in the assumptions and the protocol of application)
| |
19:43 | troy_s | (OCIO on the other hand is like a lower level thing - it has no such assumptions. You can muck with more variables and control)
| |
19:43 | troy_s | danieeel: So did the above ridiculous dribble help in any way?
| |
19:44 | troy_s | (The useful part of the xicclu command is that you can take a theoretical L 100 for example (press 100 0 0 then enter) and it will spit out the 'theoretical' values for that according to your data
| |
19:44 | danieeel | the basics, yes
| |
19:44 | troy_s | Then you can go back and reverse engineer your values (scale them) such that you are getting a more accurate profile.
| |
19:44 | troy_s | (or profile estimation)
| |
19:44 | danieeel | do you know how to interpret icc and what A and B are, they appear in the dng specs too
| |
19:45 | troy_s | The PCS in ICC must be D50
| |
19:45 | troy_s | (long history, but it was designed for print so has this rather goofy thing baked into it)
| |
19:45 | troy_s | and white point scaling wasn't mandated until later too (Bradford now)
| |
19:45 | troy_s | So you can see some skips that are weird... sRGB goes to a D50 PCS for example.)
| |
19:46 | jucar | joined the channel | |
19:48 | danieeel | i have an icc which says PCS: Lab
| |
19:48 | troy_s | Yep
| |
19:48 | troy_s | It's another absolute space (based off of the original 1931 CIE work of XYZ)
| |
19:49 | troy_s | Once you understand XYZ, you understand all models that are derived from it.
| |
19:49 | danieeel | my question is rather, where to use the values from this icc
| |
19:49 | troy_s | And the difference between absolute models / relative, perceptuals versus non perceptuals.
| |
19:49 | troy_s | You can scale the values manually in a spreadsheet.
| |
19:49 | troy_s | So for example, if your white point results in non achromatic balance of RGB
| |
19:50 | troy_s | you can scale them
| |
19:50 | troy_s | and then feed the result back into colprof and get a nicely aligned 'neutral' profile.
| |
19:51 | danieeel | but when you get a profile, how do you actually use it?
| |
19:51 | troy_s | (neutral by ICC standards, which means it is balanced against the D50, which makes not a huge difference to whatever you go to from the PCS)
| |
19:51 | troy_s | Well you have to slug it into your color pipeline
| |
19:51 | troy_s | So in this case... if you have a profile for your camera
| |
19:51 | troy_s | We have three sort of phases for our pipeline:
| |
19:51 | danieeel | it has an illuminant (XYZ) and a whitepoint (XYZ) - with these, we can make a matrix which fixes the whitebalance ?
| |
19:51 | troy_s | 1) Input
| |
19:51 | troy_s | 2) Working / Manipulation
| |
19:51 | troy_s | 3) Output
| |
19:51 | troy_s | Our input might be a Camera
| |
19:52 | troy_s | our working might be... Foobar.
| |
19:52 | troy_s | our Output might be sRGB display
| |
19:52 | troy_s | So...
| |
19:52 | troy_s | When we load our data
| |
19:52 | troy_s | We transform the data into our Foobar
| |
19:52 | troy_s | So we need a Camera to Foobar transform
| |
19:52 | troy_s | 1) Camera -> Foobar
| |
19:52 | troy_s | Then when working, we work in foobar
| |
19:53 | troy_s | 2) Work in foobar
| |
19:53 | troy_s | 3) Foobar -> sRGB
| |
19:53 | troy_s | which actually adds a third instance here
| |
19:53 | troy_s | 4) sRGB -> DaniMonitor.
| |
19:53 | troy_s | If we do this with ICCs there's secret sauce in there
| |
19:53 | troy_s | 1 becomes:
| |
19:53 | troy_s | 1) Camera -> ICC PCS -> Foobar
| |
19:54 | troy_s | 2) Foobar
| |
19:54 | troy_s | 3) Foobar -> ICC PCS -> sRGB
| |
19:54 | troy_s | 4) sRGB -> ICC PCS -> DaniMonitor
| |
19:54 | troy_s | danieeel: Clear?
| |
19:54 | troy_s | In OCIO it could be much simpler
| |
19:54 | danieeel | yes, that is the outside.. i am rather after how can I code it :)
| |
19:55 | troy_s | Erm... actually I left out more crap... remember that the PCS is linearized and absolute
| |
19:55 | troy_s | So let's pretend the PCS is XYZ
| |
19:55 | troy_s | 1 looks more complex
| |
19:55 | troy_s | Let's pretend that the camera isn't linearized data format.
| |
19:56 | troy_s | 1) CameraSpace -> Linearize via inverse transfer curve -> XYZ -> Foobar Space (is it linearized?)
| |
19:56 | troy_s | 2) Work in Foobar
| |
19:56 | troy_s | (and all tools need to transform (think color pickers!)
| |
19:56 | danieeel | camera->linear ... is that a B curve in icc?
| |
19:57 | danieeel | i see it has a description: A curve -> multiLUT -> M curve -> matrix -> B curve ...
| |
19:57 | danieeel | A being the input color space (in case of camera, the linear RGB)
| |
19:57 | troy_s | 3) Foobar -> Linearized if needed via inverted curve -> XYZ -> sRGB display linear -> sRGB tone curve
| |
19:57 | danieeel | B being... LAB ?
| |
19:58 | troy_s | There's a transfer curve
| |
19:58 | danieeel | as icc PCS = LAB ?
| |
19:58 | troy_s | PCS _can_ be Lab
| |
19:58 | troy_s | I believe
| |
19:58 | troy_s | and it commonly is XYZ
| |
19:58 | troy_s | A B tables I'm unsure of role
| |
19:58 | troy_s | I know they exist, but they fit into that overall idea.
| |
19:59 | danieeel | that icc is maybe perfect, but just for a color picker.. if I want to run live, maybe 4k over it.. cant imagine it now how that would work
| |
20:00 | danieeel | how can we reduce that TI3 file to a single 3x3 matrix?
| |
20:01 | troy_s | If you use the TI3 to generate an ICC matrix
| |
20:01 | troy_s | You get the matrix.
| |
20:01 | troy_s | :)
| |
20:02 | danieeel | my icc does not have a matrix - i need to figure out how to reduce the luts to that
| |
20:03 | troy_s | colprof does that
| |
20:03 | troy_s | So do you have an image handy of a chart?
| |
20:03 | troy_s | danieeel: ?
| |
20:05 | troy_s | danieeel: I can quickly step you through it so you can generate your own TI3 and ICC.
| |
20:05 | danieeel | i already have an icc, i need to understand what its fields are meant for
| |
20:06 | troy_s | the ICC is probably sub optimal if you don't have a matrix
| |
20:06 | troy_s | Nor if you don't know how it was calculated.
| |
20:06 | troy_s | ICCs hide so much they are a mess for this sort of thing.
| |
20:06 | troy_s | takes two seconds to generate profiles etc.
| |
20:06 | troy_s | Not long.
| |
20:06 | danieeel | it uses luts insted of matrices
| |
20:07 | troy_s | Yes, which reveals how bunk your ICCs are.
| |
20:07 | troy_s | Matrices should give you a good idea how out of whack your shot is.
| |
20:07 | troy_s | Because the matrix is a strictly real world transform to XYZ effectively.
| |
20:07 | troy_s | LUTs can hide how whack your data is.
| |
20:07 | danieeel | so which tools are required?
| |
20:07 | troy_s | (Because everything looks 'good')
| |
20:07 | troy_s | danieeel: Hardly any. Have Argyll handy?
| |
20:08 | troy_s | It's two commands.
| |
20:08 | troy_s | Sorry... what raw format is the image in?
| |
20:08 | danieeel | this? media-gfx/argyllcms
| |
20:08 | danieeel | 16bit png or tiff
| |
20:10 | troy_s | You need Argyll yes.
| |
20:10 | troy_s | And you will need a raw linear TIFF (debayered)
| |
20:11 | danieeel | it is linear
| |
20:11 | troy_s | danieeel: TIFF? If you have Argyll and that, you are good.
| |
20:11 | troy_s | danieeel: Ready?
| |
20:12 | troy_s | The two commands:
| |
20:12 | troy_s | http://www.argyllcms.com/doc/scanin.html
| |
20:12 | troy_s | http://argyllcms.com/doc/colprof.html
| |
20:13 | troy_s | Let me know when you are ready and I'll step you through the two commands
| |
20:13 | danieeel | the tiff has to be rotated and cropped?
| |
20:13 | troy_s | (And how to check them inspect them)
| |
20:13 | troy_s | Not entirely if it is reasonably squareish
| |
20:13 | troy_s | You can try and use the evaluation diagnostics to evaluate it.
| |
20:15 | troy_s | danieeel: Good? (You will also need the text file that came with your chart with spectro readings)
| |
20:15 | danieeel | i have to fix the file, it is rotated
| |
20:16 | troy_s | Rotated?
| |
20:16 | troy_s | Flipped?
| |
20:17 | danieeel | rotated, like 15 degrees
| |
20:18 | danieeel | how do we evaluate it then?
| |
20:18 | troy_s | Argyll should do that
| |
20:18 | troy_s | I wouldn't worry about it.
| |
20:18 | troy_s | You can see from diagnostics
| |
20:18 | troy_s | Don't worry about rotation
| |
20:18 | troy_s | Ready?
| |
20:18 | danieeel | yes
| |
20:18 | troy_s | Okie...
| |
20:18 | troy_s | You need to locate the chart reference
| |
20:19 | troy_s | is it an it8?
| |
20:19 | danieeel | hct
| |
20:19 | danieeel | FUJI-57R-0583.txt: ASCII text, with CR line terminators
| |
20:19 | troy_s | What OS?
| |
20:19 | troy_s | Great.
| |
20:19 | danieeel | gentoo
| |
20:19 | troy_s | Ok.
| |
20:20 | troy_s | Use 'find / -name Hutchcolor.cht'
| |
20:20 | troy_s | (It is a Hutch yes?
| |
20:20 | danieeel | can you be more specific? :) there is like 20TB of stuff to search for / :)
| |
20:20 | troy_s | Try /usr/share
| |
20:20 | troy_s | (if you have a color, it should be in ther)
| |
20:20 | danieeel | /usr/share/argyllcms/ref/Hutchcolor.cht
| |
20:20 | troy_s | Ok.
| |
20:20 | troy_s | Great.
| |
20:21 | troy_s | And the path to your chart spectro readings?
| |
20:21 | danieeel | ./
| |
20:21 | danieeel | its that FUJI-57R-0583.txt
| |
20:22 | troy_s | scanin -G1.0 -dipn -vv -p /path/to/image.tiff /path/to/chart.cht /path/to/spectro/values.txt
| |
20:22 | troy_s | WHERE:
| |
20:22 | troy_s | G = estimate of gamma in the chart 1.0 here.
| |
20:22 | danieeel | there is no scanin
| |
20:23 | danieeel | argyll-scanin
| |
20:23 | troy_s | -dipn generate diagnostics and use b&w image (i) p (draw pixel areas sampled) n (draw sample box names) -vv double verbose -p perspective correct (also will show up in diag)
| |
20:23 | troy_s | No... just scanin
| |
20:24 | danieeel | running...
| |
20:24 | troy_s | And... ?
| |
20:24 | danieeel | which is a general output how good/bad it is?
| |
20:24 | troy_s | You end up with TWO files
| |
20:25 | troy_s | filename.ti3 (we've covered this)
| |
20:25 | troy_s | and diag.tif
| |
20:25 | troy_s | Which is worth looking at to evaluate how it 'looked' at the chart.
| |
20:25 | danieeel | nice
| |
20:26 | danieeel | pretty smart
| |
20:26 | troy_s | Does it look valid?
| |
20:26 | troy_s | (Should show angle correction and the swatch regions it sampled)
| |
20:27 | danieeel | yes
| |
20:27 | troy_s | Ok.
| |
20:27 | troy_s | So let's generate a profile.
| |
20:27 | danieeel | http://home.rozsnyo.com/diag.jpeg
| |
20:27 | troy_s | Bingo.
| |
20:27 | troy_s | Looks good here.
| |
20:27 | troy_s | and the swatch regions are pretty good.
| |
20:27 | troy_s | Nice eh?
| |
20:28 | danieeel | so what with the TI3
| |
20:28 | troy_s | danieeel: That's the conversion of values to XYZ
| |
20:28 | troy_s | as discussed
| |
20:28 | danieeel | yes
| |
20:28 | troy_s | That is that lovely little spreadsheetable text file
| |
20:28 | danieeel | and from there?
| |
20:28 | troy_s | with errors and such
| |
20:28 | troy_s | now we will generate a profile from that data
| |
20:28 | troy_s | ready?
| |
20:28 | danieeel | of course
| |
20:31 | troy_s | danieeel: Sorry checking
| |
20:31 | troy_s | danieeel: colprof -vv -am -D"test" -u -qu ./sample
| |
20:31 | troy_s | -vv verbose level 2
| |
20:31 | troy_s | (or v2)
| |
20:32 | troy_s | -am Matrix
| |
20:32 | troy_s | -D description
| |
20:32 | troy_s | -u Scale auto scale white point
| |
20:32 | troy_s | -qu quality ultra
| |
20:33 | troy_s | danieeel: Give it a run
| |
20:33 | troy_s | You do NOT put the ti3 on there.
| |
20:33 | troy_s | It will find it.
| |
20:33 | danieeel | Profile check complete, peak err = 33.259319, avg err = 6.316813
| |
20:34 | troy_s | That's not horrible. Could be better.
| |
20:34 | troy_s | Your peaks will reveal the errors when you run profcheck
| |
20:34 | danieeel | there are reflections in the chart
| |
20:34 | troy_s | You can see where things are whack
| |
20:34 | troy_s | http://www.argyllcms.com/doc/profcheck.html
| |
20:34 | troy_s | So
| |
20:35 | troy_s | profcheck -v2 -k data.ti3 iccprofile.icc
| |
20:35 | troy_s | and that will spit out the superior DE2000 values for each.
| |
20:35 | troy_s | (lots of them)
| |
20:36 | danieeel | Profile check complete, errors(CIEDE2000): max. = 13.986425, avg. = 3.836771, RMS = 4.445354
| |
20:36 | danieeel | can it draw some red/green lights into the chart to see where are the issues?
| |
20:37 | troy_s | danieeel: Look at your diagnostic tif
| |
20:37 | troy_s | danieeel: And look at the text output
| |
20:38 | troy_s | danieeel: The values where you are getting 33 are the ones to look at
| |
20:38 | troy_s | (the high ones)
| |
20:38 | troy_s | and figure out which squares are which)
| |
20:39 | danieeel | the 13.98 is the worse
| |
20:39 | troy_s | SO 13 is quite whack in terms of DE2000
| |
20:39 | troy_s | can you evaluate why?
| |
20:39 | troy_s | (sheen or darker or?
| |
20:40 | danieeel | all above 10 are the very dark patches
| |
20:40 | troy_s | Do me a favor
| |
20:40 | troy_s | Pastebin your ti3
| |
20:41 | troy_s | Okie?
| |
20:41 | troy_s | And tell me what swatch is 'bright white'
| |
20:41 | troy_s | on your hutch
| |
20:41 | troy_s | what swatch is bright white?
| |
20:42 | danieeel | L1 white
| |
20:42 | troy_s | Ok great hold.
| |
20:42 | troy_s | See your TI3?
| |
20:42 | troy_s | for L1?
| |
20:42 | danieeel | yes
| |
20:43 | troy_s | L14 L1 etc
| |
20:43 | troy_s | Look at the RGB column
| |
20:43 | troy_s | You can jack up the exposure a little from what I can see.
| |
20:43 | danieeel | what about evennness?
| |
20:44 | danieeel | the 4 corners shall be same, does argyll count with that?
| |
20:44 | troy_s | danieeel: The revealing set is L1 L14 and
| |
20:44 | troy_s | Where's K29?
| |
20:44 | danieeel | not defined
| |
20:45 | troy_s | Interesting.
| |
20:45 | troy_s | So we can see from A29
| |
20:45 | troy_s | to L1
| |
20:45 | troy_s | what?
| |
20:45 | troy_s | :)
| |
20:45 | danieeel | it is not evenly lit, that i know for sure
| |
20:45 | troy_s | :)
| |
20:45 | troy_s | That's a big one.
| |
20:46 | troy_s | So your light is middle of the card on the left
| |
20:46 | troy_s | :)
| |
20:46 | troy_s | Look at L
| |
20:46 | danieeel | so at the end, the tool is not that smart, to compensate for such things (i know.. one can argue if unevenness is linear or what shape)
| |
20:46 | troy_s | G (most sensitive to luminance (Y closest value))
| |
20:46 | troy_s | is 93 in the middle
| |
20:46 | troy_s | and lower at top (A1)
| |
20:46 | troy_s | Well it can't.
| |
20:46 | troy_s | If you start mucking too much with non-linearity across a chart
| |
20:47 | troy_s | You are fudging numbers
| |
20:47 | troy_s | And those might be valid
| |
20:47 | troy_s | It has no real idea of figuring out what is white
| |
20:47 | troy_s | So it can't excatly interpolate that.
| |
20:47 | troy_s | Get my point?
| |
20:47 | danieeel | yes
| |
20:47 | troy_s | danieeel: Needless to say, evenness will help you
| |
20:48 | troy_s | Because the chart is underexposed by and large
| |
20:48 | troy_s | But you can't increase exposure much in that setup
| |
20:48 | troy_s | because you'll blow out that left side white region
| |
20:48 | troy_s | But I can also see from V01 that you have some room too
| |
20:48 | troy_s | So even lighting would let you more heavily saturate the image.
| |
20:48 | danieeel | have to go
| |
20:48 | troy_s | and probably bring up the values in the darker swatches
| |
20:48 | troy_s | danieeel: Okie.
| |
20:49 | troy_s | One more thing
| |
20:49 | troy_s | Do a plot
| |
20:51 | troy_s | xicclu -g -fb ./iccprofile.icc
| |
21:11 | danieeel | done
| |
21:11 | danieeel | back for a sec, but i have to end today
| |
21:16 | troy_s | danieeel: I'm sure you have plenty to chew on now
| |
21:16 | troy_s | danieeel: Probably some ideas too.
| |
21:18 | danieeel | well, it definitely helps to reach rec.709
| |
21:19 | troy_s | reaching rec709 is easy once you have a matrix.
| |
21:19 | troy_s | You just have to A) go to D65, B) go to 709 via a single matrix.
| |
21:19 | troy_s | Then probably slap on 1886
| |
22:54 | Bertl | back now ...
| 22:56 | Bertl | is reading up ...
|