HDRI spherical map to cubemap converter

cube-map
hdr
converter
#21

@mrdoob Thank you :smile: , I don’t plan to come back to this project any time soon, but I’ll keep your suggestion in mind!

@fancyrainbow Yes I meant “-Y” :grin: , thanks!

2 Likes
#22

Agree this is a fantastic implementation, I hope you do keep it going.

  • for separate layout I could be wrong but the name convention I’ve seen is/was nx, ny, nz etc instead of xn, yn ,zn, for me this would save renaming all my files after adjusting the output.
3 Likes
#23

I’ve switched the seperate names :grinning:
Now they save as nx, ny, nz, px, py, pz

3 Likes
#24

Just like to add another vote for RGBM16 support! That would make this really useful :grin:

1 Like
#25

@mrdoob I’ve checked the links once again and I think that it may be easier than I initially thought. I could probably render the output to a canvas and simply save the canvas as png.
I thought that 16 stands for 16 bit, but its not, right? The example RGBM16 maps are 32bit (RGBA_8888).

I’ll do some tests on the weekend :slight_smile:

3 Likes
#26

Yes, this should be easy. Just use a render target and set the target’s encoding.

#27

Hmm… Interesting… How much smaller can you get a HDR/EXR by converting to RGBM16 PNG?.. Let’s say you had a HDRHaven 2k hdr that is normally 7.5MB, roughly what size would this be as RGBM16 PNG?

#28

Probably quite a bit smaller. The RGBM16 Pisa cubemap example on the three.js repo is about 30% smaller than the RGBE (.hdr) version. But I think the main advantage is that you can use the browser’s built-in PNG decoder which is likely to be much faster than the three.js RGBELoader.

3 Likes
#29

I think i need some help with the convertion shader

I’m using functions from encodings_pars_fragment.glsl.js

void main() {

  vec4 texelColor = texture2D( tDiffuse, vUv );

  texelColor = RGBEToLinear(texelColor);

  texelColor = LinearToGamma(texelColor, 2.2);

  texelColor = LinearToRGBM(texelColor, 6.0);

  // color test
  // texelColor = RGBMToLinear(texelColor, 6.0);

  gl_FragColor = texelColor;
}

My fragment shader

the output of this shader is saved to .png

Result: https://codepen.io/matheowis/pen/XOGKzz

My guess is that values that i use for gammaFactor(2.2) and maxRange(6.0) are wrong.

Any suggestions?

#30
//input: 
// initial .hdr texture, texelColor is in RGBE space

// RGBE -> linear
texelColor = RGBEToLinear(texelColor);

// texelColor now in linear space 

// linear -> gamma 2.2
texelColor = LinearToGamma(texelColor, 2.2);

// texelColor is now in gamma 2.2 space

// linear -> RGBM (!!! expects texelColor to be in linear space !!! )
texelColor = LinearToRGBM(texelColor, 6.0);

So it looks like the LinearToGamma(texelColor, 2.2) transform is not needed.

#31

Without LinearToGamma the result is full of artefacts, also 2nd link from @mrdoob suggested to convert space to gamma before RGBMEncoding function

#32

2nd link from @mrdoob suggested to convert space to gamma before RGBMEncoding function

From the link:

I should also note that it is best to convert the colors from linear to gamma space before encoding. If you plan to use them again in linear a simple additional sqrt and square will work fine for encoding and decoding respectively.

Hmm, well the fact that the three.js function is called LinearToRGBM suggests that we are using them in linear space, so that would mean we need that additional sqrt for encoding.

You could try to use the function from that article rather than the three.js function?

float4 RGBMEncode( float3 color ) {
  float4 rgbm;
  color *= 1.0 / 6.0;
  rgbm.a = saturate( max( max( color.r, color.g ), max( color.b, 1e-6 ) ) );
  rgbm.a = ceil( rgbm.a * 255.0 ) / 255.0;
  rgbm.rgb = color / rgbm.a;
  return rgbm;
}

rather than

vec4 LinearToRGBM( in vec4 value, in float maxRange ) {
	float maxRGB = max( value.r, max( value.g, value.b ) );
	float M = clamp( maxRGB / maxRange, 0.0, 1.0 );
	M = ceil( M * 255.0 ) / 255.0;
	return vec4( value.rgb / ( M * maxRange ), M );
}

Or try modifying either function to put in the “additional sqrt”, wherever that is meant to go.

#33

Awesome tool indeed!
A little bit off-topic but why should one prefer a cubemap over a spherical map? As far as I know cubemaps distort a view at certain angles.