Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/fi...



> 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


Hardcoding gamma=2 is doing the heavy lifting, though.


Gamma always equals 2, so it's a natural optimization. Assuming of course you are 0 indexing the alphabet.


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


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!


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).


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.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: