6 ms·

The concept of Log seems needlessly confusing from (still) digital image processing perspective, which I have some experience. Firstly the name is called "Log"

The concept of Log seems needlessly confusing from (still) digital image processing perspective, which I have some experience. Firstly the name is called "Log" (for logarithmic) but isn't that what gamma does in color spaces like sRGB since forever? "Normal" video standards like BT.709 also have non-linear transfer functions. I don't get why "log" is stressed here. Maybe it just means a different/higher gamma coefficient (the author didn't talk much about the "log" part in the article). And the main feature of it, at least according to this article, is that it clips the black and white level less, so leaves more headrooms for post-processing. This is definitely very useful (and is the norm if you want to do something like, say, high quality scanning), but I failed to see how it warrants a new "format". You should be able to do that with any existing video format (given you have enough bit depth, of course).

dist-epoch 3y ago
> but I failed to see how it warrants a new "format". You should be able to do that with any existing video format It's about support. The .zip format supports LZMA/ZStandard compression and files larger than 4 GB. But if you use that, a lot of software with .zip support will fail to decompress them. The same way with log. While in theory you could probably make .mp4 or .mkv files with H264 encoded in log, I bet a lot of apps will not display that correctly if at all.
- deleted 3y ago
  [deleted]
jlouis 3y ago
The transfer functions in your (rec.709) color space is non-linear indeed. However, the pixel values you store are in a linear relationship with each other. The difference between values 20 and 21 are the same as the difference between values 120 and 121, assuming an 8bit signal. I.e., the information is the same for all pixels. Further down the chain, these values are then mapped onto a gamma curve, which is non-linear. What the "log"-spaces are doing is to use a non-linear relationship for the pixel values, as a form of lossy compression. If the signal has to factor through 8bit values, using a compression scheme before it hits the (final) gamma curve is a smart move. If we retain less precision around the low and high pixel values and more precision in the middle, we can get more information from the camera sensor in a certain region. Furthermore, we can map a higher dynamic range. It often looks more pleasing to the eye, because we can tune the setup such that it delivers a lot of precision and detail where our perception works the best. In short: we are storing (8bit/10bit) pixel values. The interpretation of these values are done in the context of a given color space. In classic (rec.709) color spaces, the storage is linear and then mapped onto a non-linear transfer function. In the "log" spaces, the storage is non-linear and is then mapped onto a non-linear transfer function. In essence we perform lossy compression when we store the pixel in the camera.
- thrdbndndn 3y ago
  Thanks for the technical details. I think I get what you mean (in term of implementation), but can't we just alter the transfer function further so there are more values used for the mid-range colors? The two-step process you said (the storage is non-linear and is then mapped onto a non-linear) is basically equivalent to a singular transfer function which is the combination of two curves, since the sampling process itself is lossy.
  - jlouis 3y ago
    Yes, you can combine the steps to make it more efficient. In that view, it's "just" a different gamma curve. It's far harder to "split" a curve than combining two steps though.
- weebull 3y ago
  > The transfer functions in your (rec.709) color space is non-linear indeed. However, the pixel values you store are in a linear relationship with each other. The difference between values 20 and 21 are the same as the difference between values 120 and 121, assuming an 8bit signal. I.e., the information is the same for all pixels. Difference on what scale? ... because (hint hint) it's not number of photons that hit the sensor. Nor is it photons emitted from the display. The truth is, it's a linear measure of the voltage which drives the electron beam of a CRT. Not a very useful measure anymore, but we've encoded this response curve into all of our images and, now, this is proving to be a mistake. Working with images would be so much easier if we stored values that represent linear light (i.e. proportional to photons entering/leaving a device) with no device curves baked in. Log formats do this, but because the order of magnitude of light is more important than the absolute value, it takes the log of the value. It's a more efficient use of bits in the storage / transmission.
  - thrdbndndn 3y ago
    Gamma curve is needed due to the fact human eyes are more sensitive to darker areas than the brighter areas (Stevens' power law), so with gamma you can get away with lower bit width without (perceptually) introducing noticeable banding. The fact it somewhat matched with a response curve of CRT seems to be a historical coincidence, based on multiple sources I've read in these years. I do agree we should have get rid of it at this point as it introduces many errors in color blending. > Log formats do this, but because the order of magnitude of light is more important than the absolute value, it takes the log of the value. It's a more efficient use of bits in the storage / transmission. It literally is what gamma curve does, ina slight different but mathematically equivalent way. "Order of magnitude of light is more important than the absolute value" is exactly what Stevens' power law describes.
jlouis 3y ago
> This is definitely very useful (and is the norm if you want to do something like, say, high quality scanning), but I failed to see how it warrants a new "format". This warrants a separate answer. Cameras are getting to the point where they can capture far more information than we can display. Hence, we need a lot of bit depth to accurately store this added precision. But adding bits to the data signal requires a lot of extra bandwidth. In principle, we should just store all of this as 16/32bit FP, and many modern NLEs use such a pipeline, internally. But by creating a non-linear curve on integer data, we can compress the signal and fine-tune it to our liking. Hence we can get away with using the 8-12bit range, which helps a lot in storage. With log-curves, 12bit is probably overkill given the current sensor capabilities. There's a plethora of log-formats out there, typically one for each camera brand/sensor. They aren't meant for delivery, but for capture. If you want to deliver, you'd typically transform to a color space such as rec.709 (assuming standard SDR, HDR is a different beast). The log-formats give you a lot of post-processing headroom while doing your color grading work.
- BlueTemplar 3y ago
  Why would you still assume SDR, aren't we talking about amateur photography here ? But yeah, I've been wondering why nonlinear formats would use integer values for a while now ?!?
  - jlouis 3y ago
    I'm suggesting rec.709 because it's what is a currently expected default for a screen. In your typical setup, your working color space is something like ACEScct or DWG, so you can map to several possible output formats with a little extra work if needed. The integer values are nice because existing video formats encode things as integers. So we can just stuff our stuff inside a codec we already have rather than having to reinvent the wheel on the codec side as well. Re-purposing existing toolchains for new uses tend to a thing that gets a lot of traction compared to building a new one from scratch. Even if the newly built toolchain is far better.
    - BlueTemplar 3y ago
kllrnohj 3y ago
For some reason you're getting a lot of wrong or just bad replies. But the answer to your question is yes both sRGB/gamma2.2 & log are non-linear, but almost in the opposite direction. gamma2.2 is exponential not logarithmic. As in, it's spending all its bits on the lower half of the brightness range, whereas log is actually spending more bits in the highlights. It actually looks more like HLG in this way. https://www.artstation.com/blogs/tiberius-viris/3ZBO/color-space-management-srgb-linear-and-log https://www.artstation.com/blogs/tiberius-viris/3ZBO/color-s... has some plots of the curves to compare visually
- deleted 3y ago
  [deleted]
- bscphil 3y ago
  > almost in the opposite direction I think you're mixing up OOTFs and EOTFs here. sRGB or HLG can refer to either the stored gamma, but more often means the EOTF "reversed" gamma that is used to display an image. When we refer to "log", this is almost always means a camera gamma - an OOTF. So the reason it's "in the opposite direction" is that it's designed to efficiently utilize bits for storing image data, whereas the EOTF is designed to reverse this storage gamma for display purposes. As you can see from the graph in [1], Sony's S-Log does indeed allocate more bits to dark areas than bright areas. (Though the shape of the curve becomes more complicated if you take into account the non-linear behavior of light in human vision.) [1] https://www.enriquepacheco.com/blog/s-log-tutorial https://www.enriquepacheco.com/blog/s-log-tutorial
  - mdwrigh2 3y ago
    > When we refer to "log", this is almost always means a camera gamma - an OOTF. Wouldn't this be the OETF? OOTF would include the EOTF, which is typically applied on the display side (as you noted).
    - bscphil 3y ago
      You're right, looks like I got the acronym wrong. I'm referring to OETF.
ben7799 3y ago
RAW formats on digital cameras are also storing data in a log format. RAW conversion process is normally converting that to a color space along with (for most cameras) doing the De-Bayer algorithm. The built in converter that produces JPG files in the camera does this too. Our eyes perceive light as linear when it's really logarithmic. There is really no difference between video and still here, it's just that it's more normalized at the consumer level to deal with RAW formats at this point for stills.
- Manouchehri 3y ago
  > There is really no difference between video and still here, it's just that it's more normalized at the consumer level to deal with RAW formats at this point for stills. Fun trick: convert ProRes RAW to cDNG. You now have 59.94 raw DNGs per second to choose a photo from.
alok-g 3y ago
From the article: >> ... in DaVinci Resolve ... choose Apple Log for the Input Gamma ... Indeed, it just sounds to be a different choice of the curve, perhaps more suited for the HDR capabilities available today. PS: I did not read the article in detail. My first reaction was to just search there for 'gamma' in the article to see how 'log' is being compared to it.

dist-epoch 3y ago

> but I failed to see how it warrants a new "format". You should be able to do that with any existing video format It's about support. The .zip format supports LZMA/ZStandard compression and files larger than 4 GB. But if you use that, a lot of software with .zip support will fail to decompress them. The same way with log. While in theory you could probably make .mp4 or .mkv files with H264 encoded in log, I bet a lot of apps will not display that correctly if at all.

deleted 3y ago
[deleted]

jlouis 3y ago

The transfer functions in your (rec.709) color space is non-linear indeed. However, the pixel values you store are in a linear relationship with each other. The difference between values 20 and 21 are the same as the difference between values 120 and 121, assuming an 8bit signal. I.e., the information is the same for all pixels. Further down the chain, these values are then mapped onto a gamma curve, which is non-linear. What the "log"-spaces are doing is to use a non-linear relationship for the pixel values, as a form of lossy compression. If the signal has to factor through 8bit values, using a compression scheme before it hits the (final) gamma curve is a smart move. If we retain less precision around the low and high pixel values and more precision in the middle, we can get more information from the camera sensor in a certain region. Furthermore, we can map a higher dynamic range. It often looks more pleasing to the eye, because we can tune the setup such that it delivers a lot of precision and detail where our perception works the best. In short: we are storing (8bit/10bit) pixel values. The interpretation of these values are done in the context of a given color space. In classic (rec.709) color spaces, the storage is linear and then mapped onto a non-linear transfer function. In the "log" spaces, the storage is non-linear and is then mapped onto a non-linear transfer function. In essence we perform lossy compression when we store the pixel in the camera.

thrdbndndn 3y ago
Thanks for the technical details. I think I get what you mean (in term of implementation), but can't we just alter the transfer function further so there are more values used for the mid-range colors? The two-step process you said (the storage is non-linear and is then mapped onto a non-linear) is basically equivalent to a singular transfer function which is the combination of two curves, since the sampling process itself is lossy.
- jlouis 3y ago
  Yes, you can combine the steps to make it more efficient. In that view, it's "just" a different gamma curve. It's far harder to "split" a curve than combining two steps though.
weebull 3y ago
> The transfer functions in your (rec.709) color space is non-linear indeed. However, the pixel values you store are in a linear relationship with each other. The difference between values 20 and 21 are the same as the difference between values 120 and 121, assuming an 8bit signal. I.e., the information is the same for all pixels. Difference on what scale? ... because (hint hint) it's not number of photons that hit the sensor. Nor is it photons emitted from the display. The truth is, it's a linear measure of the voltage which drives the electron beam of a CRT. Not a very useful measure anymore, but we've encoded this response curve into all of our images and, now, this is proving to be a mistake. Working with images would be so much easier if we stored values that represent linear light (i.e. proportional to photons entering/leaving a device) with no device curves baked in. Log formats do this, but because the order of magnitude of light is more important than the absolute value, it takes the log of the value. It's a more efficient use of bits in the storage / transmission.
- thrdbndndn 3y ago
  Gamma curve is needed due to the fact human eyes are more sensitive to darker areas than the brighter areas (Stevens' power law), so with gamma you can get away with lower bit width without (perceptually) introducing noticeable banding. The fact it somewhat matched with a response curve of CRT seems to be a historical coincidence, based on multiple sources I've read in these years. I do agree we should have get rid of it at this point as it introduces many errors in color blending. > Log formats do this, but because the order of magnitude of light is more important than the absolute value, it takes the log of the value. It's a more efficient use of bits in the storage / transmission. It literally is what gamma curve does, ina slight different but mathematically equivalent way. "Order of magnitude of light is more important than the absolute value" is exactly what Stevens' power law describes.

jlouis 3y ago

> This is definitely very useful (and is the norm if you want to do something like, say, high quality scanning), but I failed to see how it warrants a new "format". This warrants a separate answer. Cameras are getting to the point where they can capture far more information than we can display. Hence, we need a lot of bit depth to accurately store this added precision. But adding bits to the data signal requires a lot of extra bandwidth. In principle, we should just store all of this as 16/32bit FP, and many modern NLEs use such a pipeline, internally. But by creating a non-linear curve on integer data, we can compress the signal and fine-tune it to our liking. Hence we can get away with using the 8-12bit range, which helps a lot in storage. With log-curves, 12bit is probably overkill given the current sensor capabilities. There's a plethora of log-formats out there, typically one for each camera brand/sensor. They aren't meant for delivery, but for capture. If you want to deliver, you'd typically transform to a color space such as rec.709 (assuming standard SDR, HDR is a different beast). The log-formats give you a lot of post-processing headroom while doing your color grading work.

BlueTemplar 3y ago
Why would you still assume SDR, aren't we talking about amateur photography here ? But yeah, I've been wondering why nonlinear formats would use integer values for a while now ?!?
- jlouis 3y ago
  I'm suggesting rec.709 because it's what is a currently expected default for a screen. In your typical setup, your working color space is something like ACEScct or DWG, so you can map to several possible output formats with a little extra work if needed. The integer values are nice because existing video formats encode things as integers. So we can just stuff our stuff inside a codec we already have rather than having to reinvent the wheel on the codec side as well. Re-purposing existing toolchains for new uses tend to a thing that gets a lot of traction compared to building a new one from scratch. Even if the newly built toolchain is far better.
  - BlueTemplar 3y ago

kllrnohj 3y ago

For some reason you're getting a lot of wrong or just bad replies. But the answer to your question is yes both sRGB/gamma2.2 & log are non-linear, but almost in the opposite direction. gamma2.2 is exponential not logarithmic. As in, it's spending all its bits on the lower half of the brightness range, whereas log is actually spending more bits in the highlights. It actually looks more like HLG in this way. https://www.artstation.com/blogs/tiberius-viris/3ZBO/color-space-management-srgb-linear-and-log https://www.artstation.com/blogs/tiberius-viris/3ZBO/color-s... has some plots of the curves to compare visually

deleted 3y ago
[deleted]
bscphil 3y ago
> almost in the opposite direction I think you're mixing up OOTFs and EOTFs here. sRGB or HLG can refer to either the stored gamma, but more often means the EOTF "reversed" gamma that is used to display an image. When we refer to "log", this is almost always means a camera gamma - an OOTF. So the reason it's "in the opposite direction" is that it's designed to efficiently utilize bits for storing image data, whereas the EOTF is designed to reverse this storage gamma for display purposes. As you can see from the graph in [1], Sony's S-Log does indeed allocate more bits to dark areas than bright areas. (Though the shape of the curve becomes more complicated if you take into account the non-linear behavior of light in human vision.) [1] https://www.enriquepacheco.com/blog/s-log-tutorial https://www.enriquepacheco.com/blog/s-log-tutorial
- mdwrigh2 3y ago
  > When we refer to "log", this is almost always means a camera gamma - an OOTF. Wouldn't this be the OETF? OOTF would include the EOTF, which is typically applied on the display side (as you noted).
  - bscphil 3y ago
    You're right, looks like I got the acronym wrong. I'm referring to OETF.

ben7799 3y ago

RAW formats on digital cameras are also storing data in a log format. RAW conversion process is normally converting that to a color space along with (for most cameras) doing the De-Bayer algorithm. The built in converter that produces JPG files in the camera does this too. Our eyes perceive light as linear when it's really logarithmic. There is really no difference between video and still here, it's just that it's more normalized at the consumer level to deal with RAW formats at this point for stills.

Manouchehri 3y ago
> There is really no difference between video and still here, it's just that it's more normalized at the consumer level to deal with RAW formats at this point for stills. Fun trick: convert ProRes RAW to cDNG. You now have 59.94 raw DNGs per second to choose a photo from.

alok-g 3y ago

From the article: >> ... in DaVinci Resolve ... choose Apple Log for the Input Gamma ... Indeed, it just sounds to be a different choice of the curve, perhaps more suited for the HDR capabilities available today. PS: I did not read the article in detail. My first reaction was to just search there for 'gamma' in the article to see how 'log' is being compared to it.