3 ms·

> washed out when filming in log That's only because it's not viewed in the right color space? (I'm using color space in the ICC sense to also include the tra

> washed out when filming in log That's only because it's not viewed in the right color space? (I'm using color space in the ICC sense to also include the transfer function). For some reason video folks seem really intent on creating their own terms for everything that photographers already standardized with ICC. And to make things worse they decided to make the EOTF and OETF not be inverses of each other. Of course things will look off if you display a log-encoded image on a display that uses a power-gamma. You have to linearize the input (invert the log-encoding) then delinearize (inverse power) before sending it to the display. With ICC-aware tools (that most photographer uses) this conversion is done automatically for you (e.g. colorsync on mac). But for some reason video workflows are not icc color managed. As I understand the oetf is basically unused entirely: since edits are made under bt1886 conditions, effectively baking in this bt1886 assumption on the viewer side as well. This seems to be the exact opposite of how ICC workflows work, where regardless of the monitor color profile the editor uses, all edits are transferred to the underlying source color profile of the image. The only page I've ever seen which actually acknowledges that "log encoding" is just an alternative to gamma encoding is https://imatest.atlassian.net/wiki/spaces/KB/pages/11416142124/Gamma+Tonal+Response+Curve+and+related+concepts#Logarithmic-encoding https://imatest.atlassian.net/wiki/spaces/KB/pages/114161421..., as I discussed in an earlier rant https://news.ycombinator.com/item?id=37877599 https://news.ycombinator.com/item?id=37877599

CaptainOfCoit 2y ago
> That's only because it's not viewed in the right color space? It's like that because it's the log encoding is not in a display-ready color space. Many modern cameras can apply LUT directly in the viewfinder though, so it's less of a nuisance today. In reality, it isn't an issue, just beginners get surprised when they see it the first time. > For some reason video folks seem really intent on creating their own terms for everything Which to me makes sense. If I'm looking for terms that can apply to many areas, it becomes harder to find the right thing. I much prefer separated terms than the approach than one term being used in many areas, so it gets easier to search and talk about. > actually acknowledges that "log encoding" is just an alternative to gamma encoding Not sure they are 100% alternatives though, but I'm much more familiar with log encoding than gamma encoding. As far as I understand, log encoding uses a logarithmic curve to capture a wide dynamic range, preserving detail in shadows and highlights for extensive post-production grading. In contrast, gamma encoding applies a non-linear curve that approximates human vision, producing footage with natural contrast and color suitable for immediate viewing and minimal post-processing. But, I could also misunderstand the differences, and would be happy to be told otherwise :)
- krackers 2y ago
  >gamma encoding applies a non-linear curve that approximates human vision IIUC it's a similar bit optimization scheme to allocate bits fairly across the entire dynamic range. The only difference is the curve used (log vs gamma). You are right in that "log" is probably more uniform from a physics perspective (something about each f-stop getting same # of bits) while "gamma" is supposedly more uniform from a perceptual perspective (something about steven's power rule). Note that even storing things in floating point is also effectively a form of log encoding since density of floating point numbers halves when you double the range. To me they feel more similar than they are different, which is why it's annoying that there's this completely parallel set of terminology used for photography vs video-editing and I haven't been able to find a rosetta stone to translate between the two (part of this is undoubtedly because icc color management requires digital computers, while film making existed as a field long before that) * log-encoding :: gamma encoding * EOTF/OETF :: Gamma/transfer function (n.b. eotf not necessary inverse of oetf, unlike gamma) * LUT application :: ICC color space conversion * Video-workflow (make edits directly in target color space) :: Photo workflow (transfer edits to source color space) * NCLC tag :: ICC color profile

CaptainOfCoit 2y ago

> That's only because it's not viewed in the right color space? It's like that because it's the log encoding is not in a display-ready color space. Many modern cameras can apply LUT directly in the viewfinder though, so it's less of a nuisance today. In reality, it isn't an issue, just beginners get surprised when they see it the first time. > For some reason video folks seem really intent on creating their own terms for everything Which to me makes sense. If I'm looking for terms that can apply to many areas, it becomes harder to find the right thing. I much prefer separated terms than the approach than one term being used in many areas, so it gets easier to search and talk about. > actually acknowledges that "log encoding" is just an alternative to gamma encoding Not sure they are 100% alternatives though, but I'm much more familiar with log encoding than gamma encoding. As far as I understand, log encoding uses a logarithmic curve to capture a wide dynamic range, preserving detail in shadows and highlights for extensive post-production grading. In contrast, gamma encoding applies a non-linear curve that approximates human vision, producing footage with natural contrast and color suitable for immediate viewing and minimal post-processing. But, I could also misunderstand the differences, and would be happy to be told otherwise :)

krackers 2y ago
>gamma encoding applies a non-linear curve that approximates human vision IIUC it's a similar bit optimization scheme to allocate bits fairly across the entire dynamic range. The only difference is the curve used (log vs gamma). You are right in that "log" is probably more uniform from a physics perspective (something about each f-stop getting same # of bits) while "gamma" is supposedly more uniform from a perceptual perspective (something about steven's power rule). Note that even storing things in floating point is also effectively a form of log encoding since density of floating point numbers halves when you double the range. To me they feel more similar than they are different, which is why it's annoying that there's this completely parallel set of terminology used for photography vs video-editing and I haven't been able to find a rosetta stone to translate between the two (part of this is undoubtedly because icc color management requires digital computers, while film making existed as a field long before that) * log-encoding :: gamma encoding * EOTF/OETF :: Gamma/transfer function (n.b. eotf not necessary inverse of oetf, unlike gamma) * LUT application :: ICC color space conversion * Video-workflow (make edits directly in target color space) :: Photo workflow (transfer edits to source color space) * NCLC tag :: ICC color profile