Confusion about the range of opengl Pixelformats

OpenGL OpenGL: Advanced Coding
1

Hi,

I worked alot with opengl 8 bit per channel formats (which are clamped from 0-1 as far as I know) and also with floating point formats like GL_RGB16F_ARB. I am sure that the ranges there are not clamped and should be somewhat from - biggest_possible_float to + biggest_possible_float. Anyways here is what I don’t understand. Does that mean that - biggest_possible_float becomes black and +biggest_possible_float becomes red/green/blue? Until now I still had the feeling that <= 0 was black and >= 1.0 was highest r/g/b. Maybe I am misunderstanding the concept of floating point formats in general, but where is the benefit in terms of color range if the colours are still clamped from 0-1 when they are displayed.

lets do a little example:

glTexImage2D(..., 0, GL_RGB8, 100, 100, 0, GL_RGB, GL_UNSIGNED_BYTE, myPixels);

then I would know, that a pixel channel with the value 0 would the smallest possible value, and 255 the biggest one.

glTexImage2D(..., 0, GL_RGB16F_ARB, 100, 100, 0, GL_RGB, GL_FLOAT, myPixels);

What is the smallest, what is the biggest possible value? As stated before i am pretty certain that it should be somewhat like -biggest_possible_float to +biggest_possible_float, but still why is everything smaller than 0 black, and everyting bigger or equal to one full red/green/blue?

I still understand the benefits of floating point textures for other things like HDR or other more precise calculations in a shader. The reason I am trying to figgure this out right now is that I am working on a simple colour class in c++ that should similarily handle different internal formats.

Thanks!

edit:
Okay, I just read a paper about openEXR, I think it’s defined beaviour that the range 0-1 is what todays displays can display and everything else is basically your processing margin, so you don’t loose anything after havy postprocessing?
Can anybody confirm that?

2

Does that mean that - biggest_possible_float becomes black and +biggest_possible_float becomes red/green/blue?

No. Values in floating-point textures generally do not have a meaning that can be described as a color. These values typically represent things like HDR light intensity or simply arbitrary user-defined values.

You cannot display a floating-point texture without modifying its values to fit in a standard clamped RGB colorspace. This process is call tone mapping, and can be done pretty much however you want it to be done.

The reason I am trying to figgure this out right now is that I am working on a simple colour class in c++ that should similarily handle different internal formats.

Really that’s unnecessary.

3

Well the idea is that you load images and then can do the following:

PixelGridRGB8 & pixels = myImage.getPixelGrid();
for(uint32 x=0; x<myImage.getWidth(); ++x)
{
        for(uint32 y=0; y<myImage.getHeight(); ++y)
        {
                ColorRGB8 & pixel = pixels.get(x, y);
                // do something
        }
}

basically I want to be able to deal with the image data in a more readable fashion, insted of working with a byte array. Especially if you have formats not using bytes that can be quite a pain. In the example above you should also be able to easily cast/transform one format into another, thats where my confusion comes from. If you have a better idea about how to achieve that, let me know! Thanks for your reply!

4

As Alfonse wrote, floating point data in GPU memory space is not understood for rendering purposes. Most devices have only RGB8 output.

If you need to access some data on the CPU, and it’s not GPU-created data (e.g. rendered), it’s better to do all that before uploading it.

As for not working with a (byte-)array, the data is just that - a single region of memory.

Unless I completely misunderstood OP, this is not an advanced OpenGL issue but an intermediate C problem.

5

no you are right, the actual question is answered, I was just explaining where my thoughts came from. Imagine having an image using a byte array internally which represent floats. I want to achieve some sort of readable way to iterate over those pixels to read and/or modify them. Anyways this is most likely not the place to answer that :slight_smile: