Discrepancy of text brightness/sharpness Supersplat viewer and Sparkjs

[meditation-error]

I have this scene using sparkjs: https://voluma.mediamarc.nl/embed/jack/x/watch
and this one is in supersplat viewer: https://rr3d.dk/Upload/3dgs/watch/Watch_MCMC_1M_150KSteps_Compressed/index.html

Supersplat does seem to do some custom color correction I assume, but I was wandering, how could the text be so bright ?
Especially the numbers around the edge, but also the text 'Alpha slowmaster Professional' is very bright. Almost as if it has a higher sh level with more/different data. I tried asjusting, blur, brightness, contrast in spark, but the text stays in much lower contrast with the backplate.

Mkkellogg's viewer is showing roughly the same as sparkjs, and maybe it's just some custom improvement by the supersplat viewer, but I wander if anyone has any insight how this brightness is achieved and could it maybe be recreated in spark ?

The file: https://assets.voluma.ai/rr3d/scene/Watch_MCMC_1M_150KSteps_Compressed.ply

[dmarcos]

Thanks for providing details. We’ll look into it

[dmarcos]

@meditation-error we are investigation. By any chance you have access to the images / video used to train the splat? Thanks

[mrxz]

The difference in brightness seems to stem from the way the RGB values from the .ply file are handled. Both spark and mkkellogg decode the colour values and quantize the 0-1 range into 8-bit values. Supersplat on the other hand does the decoding in the shader and as a result can use values outside of the 0-1 range (brighter colours).

To illustrate, here's a comparison showing Supersplat without modification and with the same clamping applied. Note how this results in the same muted look:

[meditation-error]

Thanks for looking into it @mrxz that sounds plausible.
Do you think Spark can support color decoding in the shader too at some point ?

@dmarcos Not sure if still needed, but here is the source material: https://drive.google.com/drive/folders/1btktki1IdDnHmiX0c-HzLn1FDpw8n7Cp?usp=sharing

(Note: this was made using a camera array tool addon in Blender from Olli Huttunen - there are 3 files for the COLMAP export generated: "cameras.txt", "images.txt" and "points3D.txt", which are also in the folder, along with the PostShot file and the uncompressed and compressed PLY.)

[asundqui]

Screen.Recording.2025-07-01.at.10.16.06.AM.mov

So I modified Spark to encode RGB values -0.5..3.5 range, which covers 99.7% of the RGB values present in the watch. The image shows red regions flashing to indicate >1.0 values for R/G/B, representing super-bright areas. It corresponds exactly to the brighter regions in the SuperSplat clamped images.

Here's the GLSL functions I use for encoding/decoding:

float encodeWideComp(float x) {
    return max(0.0, min(1.0, 0.25 * (x + 0.5)));
}
float decodeWideComp(float x) {
    return 4.0 * x - 0.5;
}

What should Spark do with values that are >1.0 for R/G/B? When rendering in the fragment shader I assume they get clipped to 1.0 anyway, so they wouldn't end up "super bright". Is there some other blending mode it should be using? I looked at SuperSplat with Spector.js and it looked like it was blending to a plain RGBA8 buffer, no extra precision that I could tell.

Not sure what to do here, you guys have any ideas?

[mrxz]

What should Spark do with values that are >1.0 for R/G/B? When rendering in the fragment shader I assume they get clipped to 1.0 anyway, so they wouldn't end up "super bright". Is there some other blending mode it should be using?

@asundqui The clipping of the fragment shader output is done on a per-channel level. Since SuperSplat uses pre-multiplied alpha it's possible to have RGB values > alpha value. The precision remains the same, but the contribution of a single splat can exceed what it could do with normal blending.

[dmarcos]

@meditation-error #134 addresses the color issues you’ve seen. Do you have some time to give it a try and let us know if it works for you? Thanks

[meditation-error]

Thanks @dmarcos and @asundqui

Looking at the screencapture, this change really makes a difference!

But I think I am doing something wrong, because I can't activate the extended rgb mode in my viewer code yet, using the most recent main branch.

I tried it using het following settings:

const splatEncoding = { rgbMin: -1.0, rgbMax: 4, sh1Min: -6.0, sh1Max: 6.0, sh2Min: -6.0, sh2Max: 6.0, sh3Min: -6.0, sh3Max: 6.0 }
...
const splatMesh = new SplatMesh({ packedSplats, splatEncoding });
...
sparkRenderer = new SparkRenderer({
        renderer: webGlRenderer,
        splatEncoding
})

It definitly did something (see screenshot), but I must be missing something.

I deducted the settings from the sceencapture in #134
Removing the splatEncoding from the SparkRenderer makes it a little less over saturated, but still far from the desired result.
Removing the splatEncoding from the splatMesh (keeping it on sparkRenderer) removes all saturation, but just renders the splat as before, without the extra brightness in the details.

[mrxz]

Removing the splatEncoding from the SparkRenderer makes it a little less over saturated, but still far from the desired result.
Removing the splatEncoding from the splatMesh (keeping it on sparkRenderer) removes all saturation, but just renders the splat as before, without the extra brightness in the details.

@meditation-error The packedSplats have an associated splatEncoding. When you pass both packedSplats and splatEncoding to the SplatMesh constructor, you're taking the packed splats but overriding their encoding. Instead you'd want to make sure the splats are loaded with the desired splatEncoding.

This can be done by passing the splatEncoding to the class that loads the splat file, either:

const packedSplats = new PackedSplats({ url: "./clone.ply", splatEncoding })

Or directly to the SplatMesh:

const splatMesh = new SplatMesh({ url: "<your-url-here>", splatEncoding });

Hope this helps. It's a bit unintuitive that the splatEncoding can both mean "use this encoding when loading/parsing splat files" and "reinterpret the splats as using this encoding" depending on the options used. Maybe it'd be better to disallow passing both packedSplats and splatEncoding to SplatMesh. Users can still override the encoding by adjusting the packedSplats.splatEncoding directly.

[meditation-error]

const packedSplats = new PackedSplats({ url: "./clone.ply", splatEncoding })
This works perfectly, thanks!

I was using the following method to load splats and show donaload progress:
const packedSplats = await loader.loadAsync(url, (event: any) => { ... }

Thats why I could not find a way to pass the splatEncoding, but I wonder is there a way to still get the download progress, when creating a PackedSplats from a url ? or is there another way top load a splat with splatEncoding and still get updates on the download progress ?

[mrxz]

Thats why I could not find a way to pass the splatEncoding, but I wonder is there a way to still get the download progress, when creating a PackedSplats from a url ? or is there another way top load a splat with splatEncoding and still get updates on the download progress ?

That is still possible, though the DX is a bit unwieldy:

// Provide loader with target PackedSplats with desired encoding
loader.packedSplats = new PackedSplats({ splatEncoding });

// Call loader (return value is the same as `loader.packedSplat`)
const packedSplats = await loader.loadAsync(url, (event: any) => { ... })

// (Optional) clear packedSplats for future usage of loader
loader.packedSplats = undefined

[meditation-error]

That works, thanks again!