| 01:31 | dimaursu16 | left the channel |
| 01:40 | illwieckz | joined the channel |
| 01:40 | illwieckz | left the channel |
| 01:40 | illwieckz | joined the channel |
| 04:46 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 04:46 | Bertl_oO | changed nick to: Bertl_zZ
|
| 05:34 | dimaursu16 | joined the channel |
| 05:34 | dimaursu16 | left the channel |
| 05:34 | dimaursu16 | joined the channel |
| 05:45 | jucar | joined the channel |
| 07:05 | jucar | left the channel |
| 09:05 | Spirit532 | joined the channel |
| 09:26 | dimaursu16 | left the channel |
| 09:31 | ItsMeLenny | joined the channel |
| 09:58 | se6astian|away | changed nick to: se6astian
|
| 11:44 | Bertl_zZ | changed nick to: Bertl
|
| 11:45 | Bertl | morning folks!
|
| 12:12 | RexO | joined the channel |
| 12:47 | danieel | left the channel |
| 12:48 | danieel | joined the channel |
| 13:16 | tezburma | joined the channel |
| 13:20 | illwieckz_ | joined the channel |
| 13:22 | illwieckz | left the channel |
| 13:39 | ItsMeLenny | left the channel |
| 13:40 | ItsMeLenny | joined the channel |
| 14:39 | ItsMeLenny | left the channel |
| 15:05 | dimaursu16 | joined the channel |
| 15:11 | Bertl | off for now ... bbl
|
| 15:11 | Bertl | changed nick to: Bertl_oO
|
| 15:24 | pusle | left the channel |
| 15:25 | niemand | joined the channel |
| 15:27 | pusle | joined the channel |
| 15:30 | dimaursu16 | left the channel |
| 15:44 | jucar | joined the channel |
| 16:06 | niemand | left the channel |
| 16:07 | niemand | joined the channel |
| 16:11 | jucar | left the channel |
| 17:11 | niemand | left the channel |
| 17:11 | niemand | joined the channel |
| 17:16 | RexO | left the channel |
| 17:44 | niemand | left the channel |
| 18:05 | jucar | joined the channel |
| 18:06 | illwieckz_ | left the channel |
| 18:19 | illwieckz_ | joined the channel |
| 18:24 | jucar | left the channel |
| 19:21 | illwieckz_ | left the channel |
| 19:22 | illwieckz | joined the channel |
| 19:27 | arpu | left the channel |
| 19:42 | arpu | joined the channel |
| 21:21 | illwieckz | left the channel |
| 21:25 | dimaursu16 | joined the channel |
| 21:25 | dimaursu16 | left the channel |
| 21:25 | dimaursu16 | joined the channel |
| 21:33 | troy_s | joined the channel |
| 21:34 | troy_s | @Bertl_oO Ping.
|
| 21:34 | troy_s | @Bertl_oO Been on a long adventure. Have some interesting colorimetry stuffs to report.
|
| 21:37 | dimaursu16 | left the channel |
| 22:02 | illwieckz | joined the channel |
| 22:21 | se6astian | troy_s: welcome back!
|
| 22:21 | se6astian | share your adventure stories with us soon!
|
| 22:21 | se6astian | and the colorful treasures you found on the path
|
| 22:21 | troy_s | se6astian: Not really "back" per se. Just have been on a long deep dive into desaturation explorations.
|
| 22:21 | troy_s | se6astian: Has there been any progress on the colorimetry front at all?
|
| 22:22 | se6astian | not much happened on that front in recent times
|
| 22:23 | tezburma | left the channel |
| 22:27 | troy_s | That's depressing.
|
| 22:38 | jucar | joined the channel |
| 22:54 | se6astian | off to bed now
|
| 22:54 | se6astian | lets chat again soon
|
| 23:03 | se6astian | changed nick to: se6astian|away
|
| 23:12 | Bertl_oO | hey troy_s! how's going?
|
| 23:12 | Bertl_oO | changed nick to: Bertl
|
| 23:13 | troy_s | Bertl: Good thanks. You?
|
| 23:14 | Bertl | relatively fine ... the water cooling on my work system failed on saturday (as usual) and I have to wait till tomorrow to fix it
|
| 23:15 | Bertl | what was your adventure and what is the interesting stuff?
|
| 23:18 | troy_s | Bertl: It has to do with some interesting compression along the saturation domain in some higher end cameras.
|
| 23:19 | troy_s | Bertl: I was invited to some private discussion forums with some very top tier colourimetry folks and learned a little about what some of the higher end cameras are doing at the hardware level.
|
| 23:21 | troy_s | Bertl: Here's a consumer grade DSLR demonstration that shows the issue largely: http://pasteall.org/pic/show.php?id=111281
|
| 23:22 | troy_s | Bertl: Notice anything there?
|
| 23:22 | troy_s | Bertl: That is a simple two stop differential of exposure.
|
| 23:23 | Spirit532 | I see weird.
|
| 23:23 | Spirit532 | And all the colors areway off
|
| 23:23 | troy_s | Spirit532: Correct.
|
| 23:24 | Spirit532 | Sucks to be them, I shoot B&W! https://www.youtube.com/watch?v=ewjZmd1AcZo
|
| 23:24 | Spirit532 | cries because he wants a color HS camera
| | 23:24 | Spirit532 | Surprisingly, the curves on B&W are still extremely complex in some cases.
|
| 23:25 | Spirit532 | What's the cause of the problem in the comparison above?
|
| 23:25 | Spirit532 | Surely that wouldn't be there in a raw image.
|
| 23:28 | troy_s | Spirit532: You realize that B&W is anchored in colorimetry right? You can't avoid the issue.
|
| 23:29 | Spirit532 | B&W is not very anchored
|
| 23:29 | troy_s | Spirit532: The root cause of the problem is in handling device referred encodings.
|
| 23:29 | Spirit532 | Ah.
|
| 23:29 | Spirit532 | pretends to understand
| | 23:29 | troy_s | Spirit532: The camera has a limited range from minimum to maximum of sensitivity (aka output / device / display referred)
|
| 23:29 | troy_s | Spirit532: The scene has an unlimited range of encoding (aka scene referred)
|
| 23:29 | troy_s | Spirit532: with me?
|
| 23:29 | Spirit532 | What does unlimited range mean?
|
| 23:30 | Spirit532 | It's still n bits per channel, be it RGB or just brightness
|
| 23:30 | troy_s | Meaning that if you look out your window with a spot meter and measure values, you'd have anything from "Error" (we can call this some infinitely low value for the sake of argument)
|
| 23:30 | troy_s | Spirit532: To an infinitely large value (there might be a maximum in your scene, including the sun, but if we imagine, we can visualize that there are forever larger and more intense potential realities, so our upper end is infinite)
|
| 23:31 | Spirit532 | sure
|
| 23:31 | troy_s | Spirit532: So when attempts to encode the scene into a device referred context, transforms have to take place that anchor those values.
|
| 23:32 | Spirit532 | so, setting the absolute min & max values for the frame?
|
| 23:32 | troy_s | Spirit532: In the case of a colour camera, we have issues at the higher end of the values. That is, if we consider each photosite is gathering up an arbitrary bunch of wavelengths that end up being the "green" filter, the "red" filter, and the "blue" filter, we define our colours based on ratios of those accumulator wells.
|
| 23:32 | Spirit532 | which is 1:2:1
|
| 23:32 | Spirit532 | for simplicity's sake
|
| 23:33 | Spirit532 | ignoring QE & filter curves
|
| 23:33 | troy_s | Spirit532: But at high intensities, our wells fill up and can't record any further information. That data becomes "non data" because we are no longer recording the scene.
|
| 23:33 | Spirit532 | saturation, yes
|
| 23:33 | troy_s | Spirit532: But the lower well totals continue to accumulate. Hence the wrong ratios. Hence the wrong colours.
|
| 23:33 | Spirit532 | I see.
|
| 23:34 | troy_s | Spirit532: The more correct approach would be for the hardware to implement a carefully designed 3D LUT transform that would, at a certain point, begin to compress the values such that the colorimetry of the scene is preserved in terms of the correct "hue" of the scene's object.
|
| 23:34 | troy_s | Spirit532: Albeit migrating towards the achromatic axis.
|
| 23:34 | troy_s | Spirit532: That way, while the actual chromaticity cannot be preserved (the xy position of the colour of the object at a lower exposure), we can preserve the axis that the colour lives on if you will.
|
| 23:35 | Spirit532 | But what can you compress if the pixel is saturated?
|
| 23:35 | Spirit532 | you can't apply different gains to pixels
|
| 23:35 | troy_s | Spirit532: You would know that the sensel is full or nearing full, and transform the other values upwards synthetically filling the wells.
|
| 23:35 | Spirit532 | oh.
|
| 23:36 | troy_s | Spirit532: This would result in a more precise bit of colourimetry at the higher end.
|
| 23:36 | Spirit532 | That makes sense.
|
| 23:36 | troy_s | So the colour ends up precise along the achromatic to original colour axis, at reduced chroma.
|
| 23:36 | Spirit532 | And where is that implemented?
|
| 23:36 | Spirit532 | VLSI?
|
| 23:36 | troy_s | At the hardware level in the labyrinthine chain somewhere.
|
| 23:37 | Spirit532 | Is this implemented in any codecs on PCs?
|
| 23:37 | troy_s | Pardon?
|
| 23:38 | Spirit532 | I'm picking up a raw CMV2000-based camera(basically LVDS to USB converter, lol)
|
| 23:38 | troy_s | It's somewhat impossible to implement at a codec level as the horses have already left the barn.
|
| 23:38 | troy_s | It would be theoretically plausible to implement for something like that.
|
| 23:38 | Spirit532 | So I'm going to have access to absolute raw data and all sensor controls
|
| 23:38 | Spirit532 | At a few hundred frames per second
|
| 23:39 | troy_s | Assuming that some work has been done to stabilize the raw data and get a good solid photosite filter to XYZ transform.
|
| 23:39 | troy_s | (Which is a *large* assumption of course, given that there was epic failure on that front previously)
|
| 23:39 | Spirit532 | Probably. Think of it as if it's the Axiom. Except it's not, and it's USB3.
|
| 23:40 | Spirit532 | I'm looking forward to shooting fully raw, but I'm also not looking forward to shooting raw.
|
| 23:41 | Spirit532 | The problem you've explained to me(which I didn't know the name for) is one of my main concerns. That, and having to grade everything.
|
| 23:45 | troy_s | Grading is pretty typical. Technically speaking, if you just want to point and shoot, there's a trivial transform for that as well.
|
| 23:46 | Spirit532 | The biggest scare for me at the moment is that it *only* shoots raw. Compression has to be done on the (thankfully beefy) PC.
|
| 23:47 | Spirit532 | Granted, I'm not going to be shooting at 170 fps all the time, but it's still >100MB/s of data to crunch
|
| 23:48 | troy_s | Once proper profiling is done, to transform the sensor data to "aesthetic" bits, it is a very simple transform.
|
| 23:48 | Bertl | troy_s: I don't see how a LUT could help with compensating an overflow
|
| 23:49 | troy_s | Bertl: In terms of ratios, the chromaticity coordinates of a given colour are a byproduct of the native "primaries" (albeit artificial) of the photosites expressed as a ratio.
|
| 23:49 | Spirit532 | Or, as I understand it, putin simple terms: if it's blown the hell out, bump the others a bit too.
|
| 23:50 | Spirit532 | put in*
|
| 23:50 | troy_s | Bertl: At a given fill level, you'd synthetically ramp the other channels (3D LUT) to have the resultant triplet hold chromaticity correctly.
|
| 23:50 | troy_s | Bertl: It's sort of "well duh" obvious, but something that has been elusive for a few years to me.
|
| 23:50 | troy_s | Bertl: And, to no surprise, the two leading cameras in terms of preferential work for grading, Sony's F65 / F55 and Arri's Alexa, both perform this. :)
|
| 23:51 | Bertl | well, maybe I don't see it ... let's do an example with sensel values
|
| 23:51 | troy_s | Bertl: Have a look at the sample GIF I posted.
|
| 23:51 | Bertl | let's assume raw linear values in 8 bit
|
| 23:51 | troy_s | Bertl: It doesn't take a rocket surgeon to realize that the orange of the bowl is *gravely* broken in the overexposed version.
|
| 23:51 | troy_s | Sure.
|
| 23:52 | Bertl | let's assume we get RGB (64 128 32)
|
| 23:52 | troy_s | Right.
|
| 23:52 | Bertl | now let's double the amount of light
|
| 23:52 | Spirit532 | 128, 255, 64
|
| 23:52 | Bertl | we will end up with (128 255 64)
|
| 23:53 | Spirit532 | 255 can't go higher
|
| 23:53 | Bertl | that is almost correct, except it goes to magenta
|
| 23:53 | troy_s | Right. So in this case you'd set a well total value at say 90%.
|
| 23:53 | troy_s | So as a value creeps up to the G channel say, 240 or 230 or whatever
|
| 23:53 | Bertl | what is a well total value?
|
| 23:53 | troy_s | Fully saturated.
|
| 23:53 | troy_s | (assuming you've unbotched all of the bits and we are dealing with proper information and not non-data)
|
| 23:54 | Bertl | okay, so 240 is assumed to be fully exposed
|
| 23:54 | troy_s | Fully exposed at 8 bit let's assume is correctly mapped to full saturation.
|
| 23:54 | troy_s | 255
|
| 23:54 | troy_s | (Again, for the sake of discussion to keep things clear)
|
| 23:54 | troy_s | So at 230 say, or 220, you have the transform begin.
|
| 23:55 | Bertl | I have no idea what you are talking about to be honest
|
| 23:55 | troy_s | You have a colour recorded in the camera.
|
| 23:56 | troy_s | Let's call it in terms of chromaticity coordinates.
|
| 23:56 | Bertl | the raw linear data will be correct up to a point where one primary gets overexposed
|
| 23:56 | Bertl | at this point, nothing will help you
|
| 23:56 | troy_s | That is, you've properly profiled the camera and we know that RGB combination = colourA.xy
|
| 23:56 | Spirit532 | the data is not linear unless you've fully built the QE & bayer curves into the hardware
|
| 23:56 | troy_s | OMFG please.
|
| 23:57 | Spirit532 | just kidding
|
| 23:57 | troy_s | RGB combination for a given colour, say our bowl gif, is ColourA.xy (it's the orange colour) based on the Camera.RGB triplet (via XYZ transform)
|
| 23:57 | troy_s | Now as that exposure goes up, you'd take your max() and realize that you are nearing saturation.
|
| 23:58 | troy_s | Which means transforming the other two channels such that the peaking channel remains, but the other two are adjusted such that you raise the values so that you end up with ColourA.xy moving *directly* along the axis towards the achromatic white point.
|
| 23:58 | troy_s | Instead of recording the other two channels.)
|
| 23:59 | Spirit532 | In simple words: if one channel is coming closer to saturation, bump the other two
|
| 23:59 | Spirit532 | right?
|
| 23:59 | troy_s | In simple terms yes.
|
| 23:59 | Bertl | doesn't make sense to me
|