3 ms·

Very impressive, and it's of course quite clear that the OP didn't just walk off the street into Blender HQ. Many years of experience at Unity is probably quite

by unwind 3y ago

Very impressive, and it's of course quite clear that the OP didn't just walk off the street into Blender HQ. Many years of experience at Unity is probably quite helpful when it comes to knowing the domain. :) This change [1] was my favorite, optimizing an image processing step by removing lots (and I do mean lots) of table-based "optimizations" and replacing them with just straight up floating point calculation, and making it ~4X faster on the OP's machine. Fantastic! [1]: https://projects.blender.org/blender/blender/pulls/115801/files https://projects.blender.org/blender/blender/pulls/115801/fi...

celegans25 3y ago
> and replacing them with just straight up floating point calculation Not only that, the diff replaces 100-150 lines of code with 3. That's the kind of pull request I can only dream of making
- mwkaufma 3y ago
  Hardcoding gamma=2 is doing the heavy lifting, though.
  - olddustytrail 3y ago
    Gamma always equals 2, so it's a natural optimization. Assuming of course you are 0 indexing the alphabet.
nnevatie 3y ago
Yeah a nice optimization, but is "return c * c;" really a good approximation of sRGB gamma?
- aras_p 3y ago
  No it's not. But, the previous code was already effectively doing "c * c" for the last 15 years. So for now, just keep doing that, a bit faster. A more proper way would be to do proper color-space aware luma calculation. Which under default settings is sRGB indeed, but not necessarily so (VSE can be set to operate in some other color space). Someday!
  - nnevatie 3y ago
    Yes, it's weird they used 2.0 in the original code too. Doing proper gamma for any regular space (sRGB, YUV Rec.705, etc.) isn't actually that heavy (even without LUTs).
    - aras_p 3y ago
      My guess is that the code was written by someone in 1995 back when no one understood color spaces, or something (it's hard to track down who and when wrote it exactly due to all file moves and refactors etc.)

by unwind 3y ago

celegans25 3y ago

> and replacing them with just straight up floating point calculation Not only that, the diff replaces 100-150 lines of code with 3. That's the kind of pull request I can only dream of making

mwkaufma 3y ago
Hardcoding gamma=2 is doing the heavy lifting, though.
- olddustytrail 3y ago
  Gamma always equals 2, so it's a natural optimization. Assuming of course you are 0 indexing the alphabet.

nnevatie 3y ago

Yeah a nice optimization, but is "return c * c;" really a good approximation of sRGB gamma?

aras_p 3y ago
No it's not. But, the previous code was already effectively doing "c * c" for the last 15 years. So for now, just keep doing that, a bit faster. A more proper way would be to do proper color-space aware luma calculation. Which under default settings is sRGB indeed, but not necessarily so (VSE can be set to operate in some other color space). Someday!
- nnevatie 3y ago
  Yes, it's weird they used 2.0 in the original code too. Doing proper gamma for any regular space (sRGB, YUV Rec.705, etc.) isn't actually that heavy (even without LUTs).
  - aras_p 3y ago
    My guess is that the code was written by someone in 1995 back when no one understood color spaces, or something (it's hard to track down who and when wrote it exactly due to all file moves and refactors etc.)