Issue

For a long time developers have wanted 3D textures for shaders, more bit depth, or values below 0 or over 1 in their textures.

There isn't a portable file type that's a drop in solution for this type of problem, but for shader applications we don't always need portable image types. We're expecting very specific data hopefully, we know the resolution, we know the bit depth, and everything is expected in many use cases. To name a few: baking the sky using a combination of 2D and 3D luts, 3D color grading luts (some file types exist for this technically), bre-baked 1D binary trees to accelerate Ray tracing, and even clouds, both for the noise and lighting. This is just barely scratching the surface for what's possible to pre-bake I'm sure people will get creative with it as well.

The solution however is pretty simple and elegant, it does requires a bit of extra information when loading the file such as the value format, resolution, along with the file location though.

The file is a direct pixel dump from opengl. Identical a classic C array of values, no separation, no terminators, just the values bits stacked next to each other. Each value is a configurable type, which are then repeated to represent pixels, pixels are then repeated into colums or slices if needed, however it's all stacked in a single dimensional array, then saved to disk.

The file can support any combination of what glTexImage#D can support.

Formats:
GL_RED, GL_RG, GL_RGB, GL_BGR, GL_RGBA, GL_BGRA, GL_RED_INTEGER, GL_RG_INTEGER, GL_RGB_INTEGER, GL_BGR_INTEGER, GL_RGBA_INTEGER, GL_BGRA_INTEGER, GL_STENCIL_INDEX, GL_DEPTH_COMPONENT, GL_DEPTH_STENCIL...

and types
GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_HALF_FLOAT, GL_FLOAT...

I have supplied functions for both the saving and loading in cpp and modern opengl adapting to other languages and older versions of opengl should be clean and easy as well, just with the additional step that 3D texturing must be enabled.

Loading such data is extremely trivial, and generating is just as so, the only thing you lose is the ease of manipulation of the file in the progress and you must know the data type stored, and the dimensions of the image otherwise the reconstruction will fail.

Here's the C++ code for loading the example lut, which is a 3D lut consisting of 64x64x64 RGBA32F values (easily converted to Java)

std::vector read_file(const std::string &path, size_t size)
std::ifstream file(path, std::ios::binary);
if(!file.good()) {
return {};
}

std::vector<float> buf(size);
file.read(reinterpret_cast<char *>(buf.data()), size * sizeof(float));
file.close();

return buf;
}

//Then taking that lut and passing it to opengl as follows
glEnable(GL_TEXTURE_3D);
auto lut_data = read_file_as_float_vec(SHADER_SOURCE_DIR "/inversion_lut.dat", 64 * 64 * 64);

glActiveTexture(GL_TEXTURE0);
glCreateTextures(GL_TEXTURE_3D, 1, &lut_texture_id);
glBindTexture(GL_TEXTURE_3D, lut_texture_id);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, GL_REPEAT);
glTexImage3D(GL_TEXTURE_3D, 0, GL_RGBA, 64, 64, 64, 0, GL_RGBA, GL_FLOAT, lut_data.data());

lut_uniform_id = glGetUniformLocation(program_id, "inversionLut");

//Then in the render loop
glBindTexture(GL_TEXTURE_3D, lut_texture_id);
glUniform1i(lut_uniform_id, 0);
`
inversion_lut.zip

To test it simply use the normalized fragment color [0-1] as coordinates to lookup the 3D lut, it should perform a 1.0- on the color, mapping 0,0,0 to 1,1,1 or 0.25 to 0.75.

in vec2 texcoord;

uniform sampler2D colortex0;
uniform sampler3D inversion lut;

void main() {
vec3 colorCoord = texture(colortex0, texcoord);
fragColor = texture(inversion lut, colorCoord.xyz);
}