Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  sRGB textures  (Read 8895 times)
0 Members and 1 Guest are viewing this topic.
Offline integeruser

Junior Devvie


Medals: 11



« Posted 2012-03-03 13:47:19 »

Hi, i'm having some troubles with sRGB textures. Here's my code to create the texture:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
...
g_gammaTexture = glGenTextures();
glBindTexture(GL_TEXTURE_2D, g_gammaTexture);

for (int mipmapLevel = 0; mipmapLevel < pImageSet.getMipmapCount(); mipmapLevel++) {
   SingleImage image = pImageSet.getImage(mipmapLevel, 0, 0);
   Dimensions dims = image.getDimensions();

   glTexImage2D(GL_TEXTURE_2D, mipmapLevel, GL_SRGB8, dims.width, dims.height, 0,
      GL12.GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, image.getImageData());
}

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, pImageSet.getMipmapCount() - 1);
glGenerateMipmap(GL_TEXTURE_2D);

glBindTexture(GL_TEXTURE_2D, 0);

If you want to see the rest of the code: https://github.com/rosickteam/OpenGL/blob/master/rosick/mckesson/IV/tut16/GammaCheckers02.java

This http://www.arcsynthesis.org/gltut/Texturing/Tut16%20Mipmaps%20and%20Linearity.html is the tutorial i am rewriting using LWJGL, i suggest to quickly read it to understand my problem.
Now i'm asking you any advice you can give me for using sRGB...am i generating mipmaps in the correct way?
I think the problem is i am not loading the texture correctly...could the error be caused by a wrong bytebuffer(image.getImageData())?
I've checked it a lot of times and it seems correct to me...

To summarize, here is what i get:

and here is what the texture should be:


Any help is greatly appreciated.
Offline Danny02
« Reply #1 - Posted 2012-03-03 13:51:12 »

i heard, that there is something like gamma correct scaling of images.
I never used srgb textures, but perhaps the genMipmaps function doesn't work well with linear textures.
what do you get when you generate the mipmaps with an external tool, like from nvidia or amd
Offline Spasi
« Reply #2 - Posted 2012-03-03 15:24:35 »

glGenerateMipmap is not required to perform filtering in linear space, unless EXT_texture_sRGB_decode is supported. So that is most likely the problem.

The best option is to perform your own mipmap generation. This is advisable even for non-sRGB textures, because a) you get to control the filtering algorithm (can use bicubic or more advanced algorithms) and b) most artist-made textures are in sRGB space anyway and downsampling in linear space is the only proper way to generate mipmaps.

The process is simple: read sRGB -> convert to a linear fp format -> downsample using fp arithmetic -> convert back to sRGB. It can also be very easily translated to GLSL or OpenCL, so it's fast for both offline generation and in real-time for dynamic textures.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd

« JGO Bitwise Duke »


Medals: 365
Projects: 2
Exp: 8 years



« Reply #3 - Posted 2012-03-03 16:50:02 »

Why is getting gray surprising? I admit it looks kind of weird though. Anyway, try enabling anisotropic filtering:
1  
2  
3  
4  
5  
if(GLContext.getCapabilities().GL_EXT_texture_filter_anisotropic){
   float max = glGetFloat(EXTTextureFilterAnisotropic.GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT);
   System.out.println("Enabling " + max + "x anisotropic filtering");
   glTexParameterf(GL_TEXTURE_2D, EXTTextureFilterAnisotropic.GL_TEXTURE_MAX_ANISOTROPY_EXT, max);
}


What's a SRGB texture?

Myomyomyo.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #4 - Posted 2012-03-03 17:55:14 »

Standard RGB, as in pre-corrected for the basic standard "monitor gamma".  I don't think it makes a lick of difference when it comes to to scaling though, as the above checkerboard demonstrates.  Anisotropic filtering should help somewhat though.
Offline integeruser

Junior Devvie


Medals: 11



« Reply #5 - Posted 2012-03-03 17:58:59 »

Thanks for the responses.
I'm new at programming OpenGL, and this is my first code on mipmaps, srgb and so on...sorry if i'll say something wrong.

@Danny02, Spasi
In the original tutorial (which is written in c++) there isn't glGenerateMipmap(), i had to add it otherwise the textures would be black.
Perhaps this is the problem..? How can i check if mipmaps were generated with other tools? Are they stored in the texture data?

@theagentd, sproingie
The problem isn't getting gray, but getting a 'darker' gray then the expected one. And yes, with anisotropic filter the texture 'propagates' correctly, but this is not my problem Smiley
For srgb texture see the link i write in the first post, basically is a texture with color differents from 'normal' RGB

Offline Spasi
« Reply #6 - Posted 2012-03-03 18:42:51 »

In the original tutorial (which is written in c++) there isn't glGenerateMipmap(), i had to add it otherwise the textures would be black.
Perhaps this is the problem..? How can i check if mipmaps were generated with other tools? Are they stored in the texture data?

I haven't seen the code, but most likely the mipmaps come from the texture data, which have been generated offline. The tutorial even suggests a couple of tools for that purpose:

Quote
The DDS plugin for GIMP is a good, free tool that is aware of linear colorspaces. NVIDIA's command-line texture tools, also free, are as well.

Standard RGB, as in pre-corrected for the basic standard "monitor gamma".  I don't think it makes a lick of difference when it comes to to scaling though, as the above checkerboard demonstrates.  Anisotropic filtering should help somewhat though.

It makes a big difference actually. Try comparing a texture in Photoshop, as the artist designed it, with how it looks in a game without gamma-correct rendering, it won't match. The result will get worse, depending on how many linear filtering operations have been performed on the non-linear texture data. The issue is not that hard to solve, but you'd be surprised how many games get this wrong.

The 3 most common sources of filtering error are: 1) mipmap generation 2) texture sampling 3) lighting calculations. Every time you perform an addition between a texel value and something else, the texel has to be in linear space. You can fix 1) with custom mipmap generation 2) with sRGB textures and 3) with sRGB textures or simple pow() functions in the shader.

There's no way around 2), the texture sampling hardware has to know that it's dealing with non-linear data. It first has to convert from gamma-space to linear, perform the linear/mipmap/anisotropic filter and then return the texture color to the shader. Older hardware cannot do this, but this tends to be the weakest source of error.

edit: Some games use a 2.0 gamma exponent instead of 2.2, an approximation that allows them to use sqrt(x) and x*x in the shader, instead of pow(x, 1.0/2.2) and pow(x, 2.2) which are more expensive. I wouldn't recommend it these days.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2012-03-03 19:36:59 »

http://riven8192.blogspot.com/2009/08/image-gamma-corrected-scaling.html

You might want to change the Math.sqrt(...) to Math.pow(..., 1.0/gamma)
I modified the post to handle arbitrary values of gamma correctly, with some hints from Spasi.

This is where the magic happens:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
   public static int[] half(int[] argbFull, int w, double gamma)
   {
      int h = argbFull.length / w;
      int w2 = w/2;
      int h2 = h/2;

      int[] argbHalf = new int[argbFull.length >>> 2];

      for (int y = 0; y < h2; y++)
      {
         for (int x = 0; x < w2; x++)
         {
            int p0 = argbFull[((y << 1) | 0) * w + ((x << 1) | 0)];
            int p1 = argbFull[((y << 1) | 1) * w + ((x << 1) | 0)];
            int p2 = argbFull[((y << 1) | 1) * w + ((x << 1) | 1)];
            int p3 = argbFull[((y << 1) | 0) * w + ((x << 1) | 1)];

            int a = gammaCorrectedAverage(p0, p1, p2, p3, 24, gamma);
            int r = gammaCorrectedAverage(p0, p1, p2, p3, 16, gamma);
            int g = gammaCorrectedAverage(p0, p1, p2, p3,  8, gamma);
            int b = gammaCorrectedAverage(p0, p1, p2, p3,  0, gamma);

            argbHalf[y * w2 + x] = (a << 24) | (r << 16) | (g << 8) | (b << 0);
         }
      }
      return argbHalf;
   }

   static int gammaCorrectedAverage(int a, int b, int c, int d, int shift, double gamma)
   {
      double x = Math.pow(((a >> shift) & 0xFF) / 255.0, gamma);
      double y = Math.pow(((b >> shift) & 0xFF) / 255.0, gamma);
      double z = Math.pow(((c >> shift) & 0xFF) / 255.0, gamma);
      double w = Math.pow(((d >> shift) & 0xFF) / 255.0, gamma);

      return (int) Math.round(Math.pow((x+y+z+w) * 0.25f, 1.0 / gamma) * 255.0);
   }

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Spasi
« Reply #8 - Posted 2012-03-03 19:38:39 »

You can find much better explanations and pictures here:

- Gamma and Mipmapping
- Linear-Space Lighting

Half-way down in the second post, there's a comparison of two spheres, one with gamma-correct rendering and one without. That yellow-ish ring around the specular in the left image is the most obvious clue you can find in games that don't do gamma-correct rendering.
Offline integeruser

Junior Devvie


Medals: 11



« Reply #9 - Posted 2012-03-03 22:58:23 »

@Riven thank you for the code, i'll try it Smiley

@Spasi, thanks again for your attention, and for the links i will read tomorrow Smiley. Your words lead me to another questions:

I have used the same resources (.dds) that the original author uses in his project, and the compiled c++ runs perfectly on my pc so it's not an hardware problem...so why i had to add glGenerateMipmaps() to get the texture displayed? Are there some differences between c++ OpenGL and LWJGL?

And also, i opened the dds with gimp + plugin, i see only the texture, not texture + mipmaps (like the image on "Gamma and Mipmapping" post you write to me) so i think the mipmap are generated on the go, am i right? How are they generated without glGenerateMipmaps()?

These two points are not clear to me  Huh


Last thing i want to highlight, the tutorial divides the 'textures srgb' part from the 'gamma correction' part:
-the 'G' key switches between a lRGB checkerboard and the sRGB one (which is 'brighter', but not in my lwjgl application - my problem);
-the 'A' key switches between the 'no gamma' shader (which does nothing) and the 'gamma' shader, which perform this correction:
1  
2  
3  
4  
5  
6  
void main()
{
   vec4 gamma = vec4(1.0 / 2.2);
   gamma.w = 1.0;
   outputColor = pow(texture(colorTexture, colorCoord), gamma);
}

(which makes the textures even brighter - and it works perfectly)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #10 - Posted 2012-03-03 23:41:06 »

If this is the source you're porting, then all mipmap levels should come from the texture. I'll check the .dds file tomorrow. There's no difference between C++ OpenGL and LWJGL, so it's either a problem of your DDS loader or you have the wrong .dds file.

The only difference between a normal RGB and an sRGB texture is in the texture sampling. When you sample an RGB texture, you get the raw data unchanged. When you sample an sRGB texture, you get the texture data in linear space. That means, you get the result of pow(texture(tex, coord), 2.2). Well, not exactly, hopefully the pow is done before linear/mipmap filtering, but in any case the end result is in linear space. So, you use that texture sample however you like (add lighting etc), then you need to output the final color. The problem is that, unless you're doing HDR rendering, you need to go back to sRGB space. This can be achieved in two ways:

- Do an explicit pow(color, 1.0 / 2.2) in the shader and write the result to the output color. This is what the shader code you posted does.
- Use an sRGB framebuffer. That way you can output the linear-space color from the shader and the GPU will do the gamma-correction for you. An sRGB framebuffer basically provides the inverse functionality of an sRGB texture.
Offline integeruser

Junior Devvie


Medals: 11



« Reply #11 - Posted 2012-03-04 00:07:47 »

Yes, that is the source Smiley
I thought the fault could be my dds loader (which is itself a part of the port of the same project), but i have debugged together the java and c++ code, and all the variables i could check had the same values...and the textures are working for previous tuts (but always with glGenerateMipmaps()), so i have no more ideas, and decided to ask for help here. I´ll be waiting for your reply on the .dds file Smiley
Offline Spasi
« Reply #12 - Posted 2012-03-04 14:51:02 »

OK, I checked the files. Both checker_linear.dds and checker_gamma.dds in the gltut/Tut 16 Gamma and Textures/data folder contain mipmaps. The checker_gamma one has been generated with gamma-correction. So, you shouldn't need to use glGenerateMipmaps and using checker_gamma.dds + the above shader should result in gamma-correct rendering.
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2012-03-04 16:45:58 »

Good grief, nobody has ever told me about this stuff before :/ Another bunch of things to learn about. Fortunately has a bit less effect in 2D games.

Cas Smiley

Offline Roquen
« Reply #14 - Posted 2012-03-04 17:24:15 »

I've mentioned this elsewhere, but a good free book that covers alot of ground is: "Principles of Digital Image Synthesis" (download).  It's a little old, but the fundamentals don't change.
Offline integeruser

Junior Devvie


Medals: 11



« Reply #15 - Posted 2012-03-04 22:21:34 »

@princec, Roquen
I've googled for some time before posting here, and i haven't found many resources on this topic...so thanks for the link Smiley

@Spasi i downloaded the nVidia texture tool and check the textures, and it says they have mipmaps. So i re-debugged the dds loader, and found the error Smiley i was confused because of gimp didn't show mipmaps to me, so i though it was some sort of sRGB problem. Now the mipmaps are correct, and they are loaded from the texture data, as you told to me. Thank you for your time and your explanations, now i understand both mipmaps and sRGB Smiley
Offline theagentd

« JGO Bitwise Duke »


Medals: 365
Projects: 2
Exp: 8 years



« Reply #16 - Posted 2012-03-05 02:47:48 »

I'm sorry if I sound like a complete idiot here, but I completely fail to see the point in hacking around a user-specific hardware problem with software. Doesn't gamma-correction effectively reduce the quality of the texture since the non-linear gamma color is put in a byte? Doesn't this screw up (additive only?) blending badly? Isn't it better to let the user apply gamma correction in his monitor or his graphics drivers, since if he want gamma correction, wouldn't he want it on everything? Why why why???

Myomyomyo.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2012-03-05 03:06:00 »

You might wonder why the monitor actually performs this gamma correction, well, if you render a gradient from black to white (or any other pair of colors) in RGB space, only after the gamma correction, it looks like a linear gradient. This compensates the non-linear perceived luminance by the human eye. The same effect can be found in analogue photographs, where increased exposure to light yields a non-linear decrease in remaining pigment in the picture. The non-linearity allows humans to view scenes where light intensities wildly vary (up to factor 10,000) without adjusting the diameter of the pupil.

You might find this an interesting read:
http://en.wikipedia.org/wiki/Gamma_correction

These pages can help you to adjust the gamma of your monitor:
http://www.lagom.nl/lcd-test/ (i'm watching this on a dual-monitor setup and 1 monitor is surprisingly perfect, and the other is horribly off)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Roquen
« Reply #18 - Posted 2012-03-05 04:48:28 »

Gosh and you young-en's have it easy.  Monitor responses are much more uniform than they used to be.  But you still see radical differences between say LCD camera/phone displays and your average computer/TV screen (other than just luminance).  To slightly derail the thread, RGB is always (even properly gamma corrected) non-uniform.  Which means than if you think of a color as being some vector is 3D space, then moving some fixed distance does not produce a uniform change in perceived color.  You have to move further in some directions than in others to be just noticeably different.  Specifically the eye is more sensitive to luminance changes than chromatic.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #19 - Posted 2012-03-05 07:34:49 »

My comment on creating a gradient between arbitrary colors was indeed a bit misleading. I think moving linearly through HSL color space will solve that (or at least give much better results).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline theagentd

« JGO Bitwise Duke »


Medals: 365
Projects: 2
Exp: 8 years



« Reply #20 - Posted 2012-03-05 09:31:24 »

But what the hell is the point of doing that IN A PROGRAM, let alone precalculated in a texture?! It's a limitation of the hardware, so it should be solved either by the hardware, or more realistically by drivers! I know how to adjust gamma correction, I just don't see any reason at all for doing it myself!

I'm on a laptop, and the monitor sucks balls. The top of the monitor needs one gamma setting and the bottom needs another due to the viewing angle, so I can't even get a good image with gamma correction! I did increase the gamma slightly since it made gradients look better, specifically anti-aliased geometry in motion, but this caused INSANE banding for darker colors which was simply ridiculous, so I immediately disabled it again. Driver gamma correction for antialiasing gradients also looked like shit in motion, but that might be mainly because you can't tweak it at all. So WHY?! Just tell me a single reason for only gamma-correcting a single texture instead of the whole screen.

Myomyomyo.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #21 - Posted 2012-03-05 09:37:11 »

Because the gamma-correction is already backed into the texture (unless it's sRGB).
You can't do (correct) calculations with it, until you reverted the gamma-correction.

It's not a limitation of the hardware, it's a feature to adjust output for humans.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline theagentd

« JGO Bitwise Duke »


Medals: 365
Projects: 2
Exp: 8 years



« Reply #22 - Posted 2012-03-05 09:50:06 »

Wait wait wait! So it's to LOAD quality-ruined gamma-corrected textures into normal color space textures, or what?

It's not a limitation of the hardware, it's a feature to adjust output for humans.
If it's a device made by humans for humans and it's not doing what it should (display linear colors when fed linear colors) it sure is a limitation in my book... >_>

Myomyomyo.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #23 - Posted 2012-03-05 10:02:25 »

If it's a device made by humans for humans and it's not doing what it should (display linear colors when fed linear colors) it sure is a limitation in my book... >_>
No, it's a way to convert a linear gradient (black to white in RGB space) into a non-linear gradient (on monitor) to get the retina to make chemical reactions that the brain interpretes as a linear gradient.

(If you had a monitor emitted a specific amount of light for '128,128,128' and half of those photons when displaying '64,64,64', it wouldn't look half as bright, for the human eye)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Roquen
« Reply #24 - Posted 2012-03-05 10:09:44 »

@theagentd: download the book I linked.  I'm pretty sure all of this is covered.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 81
Projects: 15


★★★★★


« Reply #25 - Posted 2012-03-05 12:48:12 »

Example/Tutorial of a rather simple pixel shader to correct the gamma can be found here, might help.
Offline Spasi
« Reply #26 - Posted 2012-03-05 13:05:05 »

Wait wait wait! So it's to LOAD quality-ruined gamma-corrected textures into normal color space textures, or what?

It's not a limitation of the hardware, it's a feature to adjust output for humans.
If it's a device made by humans for humans and it's not doing what it should (display linear colors when fed linear colors) it sure is a limitation in my book... >_>

You fail to understand that this has nothing to do with hardware. Unless you're using floating point textures, there's no way you could use linear-space with an 8-bit per channel texture without a severe impact on quality. You can think of sRGB as a lossy compression method for packing more "dark" info into 8-bit RGB textures. That's because the human eye is more sensitive to dark details than bright details. And this compression comes for free, you don't even have to do anything to make it happen. When an artist works on a texture inside Photoshop, they make it so that it looks pretty on their monitor. But that monitor works in gamma 2.2 space, so the RGB texture they just made is in gamma space by definition. There's nothing you can do about it and there's no need to. The same is true for most other kinds of images, photographs you take with your phone for example.

Now, when you want to manipulate that texture, specifically when that data participates in additions, the math fails unless it's first converted to linear-space. It's math, it's not a hardware problem.
Offline Spasi
« Reply #27 - Posted 2012-03-05 13:49:45 »

I also want to clarify that gamma setting you see in your graphics driver. That's the gamma function applied to the incoming RGB values before being displayed on the monitor. That's the inverse of the texture's gamma encoding. Specifically, the texture looks nice in Photoshop because:

linear RGB -> texture sRGB = pow(RGB, 1.0 / 2.2) -> monitor RGB = pow(sRGB, 2.2) = pow(pow(RGB, 1.0 / 2.2), 2.2) = RGB, so your eyes see the original linear gradients.

Now, things change a bit in your engine. You have:

sRGB -> [FANCY RENDERER] -> monitor.

You have inverse gamma data coming in, the monitor expects inverse gamma data coming out. This implies that no matter what your renderer does, it has to output inverse gamma data. Some examples:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
// RGB texture pass-through
// No correction needed, the texture is in inverse gamma by definition!
// That's the reason most simple sprite engines look fine.
out = texture(tex, coord);

// sRGB texture pass-through
// The GPU has converted the sample from inverse gamma to linear for us, we need to correct.
out = pow(texture(tex, coord), 1.0 / 2.2);

// RGB + lighting
// We're adding something, need to go linear, then gamma correct.
out = pow(pow(texture(tex, coord), 2.2) * diffuse + specular, 1.0 / 2.2);

// sRGB + lighting
// The sample is already linear (and even has correct linear/mipmap filtering).
out = pow(texture(tex, coord) * diffuse + specular, 1.0 / 2.2);

The final observation that should also be interesting to you is that I said "no matter what". This means that even if you use floating point textures exclusively and you perform linear HDR rendering all the way, you STILL have to do gamma-correction during tone-mapping. Your tone-mapping operator needs to be gamma-aware or you simply go from linear to gamma-space as the last step in the tone-mapping shader.
Offline theagentd

« JGO Bitwise Duke »


Medals: 365
Projects: 2
Exp: 8 years



« Reply #28 - Posted 2012-03-05 20:37:03 »

Let me see if I got this straight:

 - Artists create images, but since they are making them with a monitor they will make it look good with the gamma correction.
 - When we, the game makers, load those images we need to undo the gamma correction from the textures to be able to do correct calculations.

And I still don't get it. Why are the artists making incompatible textures? Why are we doing this correction when loading the texture instead of preprocessing the texture?

And why the f*ck does monitors expect inverse gamma data? That makes just as much sense as saying that you have to add Pi to each color channel or multiply each channel by 10 or something just because "the monitor expects it". Maybe I'm just being stupid... ._.

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2012-03-05 22:56:39 »

It's because the human eye has massive sensitivity in low light intensities compared to high light intensities. The scale is logarithmic, and you'd need to store a huge range of numbers if you wanted to store enough intensities of light such that you could get smooth darker gradients and also see black and white. Unfortunately when you've got 8 bits you've only got 256 values to play with. If you want to see smooth gradients in the darks, you'd need all 256 values just to cover, say, the first third of the available range in the monitor. So the output from the computer is encoded using this power scale thing, which basically gives you exponentially more as you get higher, just so you can get to white by the time you reach 255, but also see a consistent difference on the screen between each 1 point of difference.

The end result is, all the data is usually stored in ram as this exponentially encoded RGB stuff, which means when you come to mipmap it using simple linear maths, eg. (a + b) / 2, you get completely the wrong answer. You need to convert the log scale into linear scale first, then do the sum, then turn it back again. This goes for pretty much all blending operations in OpenGL, and that's why there are a bunch of extensions for dealing with this stuff, and why computer graphics are suddenly getting more realistic looking, because finally the GPUs have the actual power to be able to do this in realtime, and also why mostly nobody knows about it outside of hardcore engine coding Smiley Or that's my guess anyway.

Cas Smiley

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (48 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!