(author here) I think yes and no -- while it is true that the "MOP" quick test I tried does not allow to access/decompress individual EXR channels, it does allow to access "chunks" of the image. Unlike say EXR ZIP that splits up image into 16 scanline chunks where each is independent, this splits up into 16K pixel chunks where each is completely independent from each other. So you can access a chunk without decompressing the whole image.
That said, if someone were to investigate ideas like this furher, then yes, making "layers" within EXR be able to get decompressed independently would be a thing to look at. Making individual "channels" perhaps not so much; it is very likely that if someone needs say "indirect specular" layer, then they need all the channels inside of it (R, G, B).
Yes, within VSE (and elsewhere in Blender) almost (*) everything uses premultiplied alpha, directly or indirectly. 8bit/channel images are stored non-premultiplied, but any math done on them does premultiplication, the math, then reverses back into un-premultiplied form (reason being, that w/ premultiplication 8bit/channel is not enough precision). Float/channel images are always premultiplied.
(*) I have found one or two VSE effects that do not do the correct premultiplication within their calculations. Someone(tm) should fix them at some point. But also a good question, whether there should be an option to keep previous "broken" behavior.
wrt color spaces, VSE by default does not do blending in linear color space. Default is sRGB, and variuous blending operations are done directly on sRGB values, i.e. "what four decades of photoshop has taught us to accept as expected results". VSE can be set to operate in some other color space, optionally.
wrt filtering of images, the pixel values are "just" filtered without color space awareness. So for 8bit/channel images (usually sRGB), they get "slightly incorrectly" filtered. If you want proper linear space filtering, can force images to be to floating point (any floating point images wihtin Blender are in "scene linear").
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.)
Most of actual research I've seen (i.e. papers) are not Unity/Unreal, they rather are CUDA/Python.
The "Unity Gaussian Splatting" is not a research per se, just integration of that existing technique into Unity. As for why Unity, well yeah that's because I have experience with it, and am comfortable using it.
There's many other people experimenting with in in web ecosystem (WebGL, WebGPU, three.js, aframe etc.), that you can say is properly open source.
Blender as is right now is lacking certain functionalities to efficiently do gaussian splatting. However, for upcoming Blender 4.1 several pieces are landing - I have extended PLY file importer to be able to import custom attributes (as needed by gaussian splats), someone else contributed APIs to be able to write compute shaders from a Python addon. Once various pieces like that are in place, someone could indeed make a decently performant gaussian splat add-on or something.
Thanks for your response and incredible work, and also to learn people are using different toolsets. Its great to hear Blender 4.1 is also shaping up to be a landmark release. Compute shaders are a new interest of mine so hopefully I can do some playing around with it.
Do you think we will see Gaussian splatting integrated into a game in the (near or not near) future?
I looked at that in the previous post (https://aras-p.info/blog/2023/09/13/Making-Gaussian-Splats-s...) and while there's some nearby correllations in positions & colors (for colors I actually (ab)use that by doing BC7 compression on that data), the rotations & scales are "pretty much random". Which makes sense; if they were not random the GS optimizer would probably have represented them as smaller amount of larger splats.
I can't comment on the linked github issues, but looking at the turbopfor icapp.c sources, it looks like the blosc2 bytedelta is not used correctly there: the expected order is "shuffle, then bytedelta", but icapp.c does "bytedelta, then shuffle". That might explain the poor result you get :)
Thanks for your response. Unfortunatelly blosc benchmark data is not easy accessible and you're not publishing the exact numbers in your survey. This makes it difficult to compare the results. The data in my benchmarks are directly downloadable and is a proposal from academia covering diverse distrutions.
I've now reverted the order to "shuffle, then bytedelta".
It looks better but still inferior to TurboPFor floating point compression and is also 35% slower in decompression.
TurboPFor FP with lz4 instead of zstd,15 has similar ratio than blosc+bytedelta+zstd,15, but again it is a lot faster.
Please, publish the exact numbers of your survey at least those with zstd,15.
The zfp results in my benchmark don't look good. Are the numbers similar to yours?
Yeah I was considering whether to include TurboPFor at some point or not. It looks really good, but for my particular use case is not applicable due to GPL license.
I have a new post (https://aras-p.info/blog/2023/02/03/Float-Compression-5-Scie...) comparing zfp, fpzip, spdp, ndzip, streamvbyte libraries for compressing this same data set. All in lossless, single threaded mode so far (just like all the other experiments before).
zfp performance is... "underwhelming" to say the least :( (fpzip is pretty good though, if only a bit slow at decompression). Maybe zfp is much better on 3D or 4D data, and/or in lossy mode. Which might be a topic for a future post.
"Kind of". My understanding is that block floating point actually makes a bunch of numbers have the same exponent (probably the largest among the group). That's not exactly the same as reordering bytes where exponents can be different (but maybe similar).
So "block" is not a lossless transformation/compression.
That said, if someone were to investigate ideas like this furher, then yes, making "layers" within EXR be able to get decompressed independently would be a thing to look at. Making individual "channels" perhaps not so much; it is very likely that if someone needs say "indirect specular" layer, then they need all the channels inside of it (R, G, B).