• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

BLP Color Space

Status
Not open for further replies.

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
Does someone know what color space BLP1 (Warcraft 3 BLP) images are in? Since they are used as mipmaps I would imagine linear RGB color space since pre D3D9 real time shaders apparently only really supported linear RGB. However since their data is not used by the GPU directly it is also possible the game automatically performs software gamma correction when loading meaning that they are in sRGB color space.

I assume it must be pretty common knowledge around here seeing how many skins and icons are produced each month.

I am fairly certain the skin and icon preview images on this site use sRGB, as most images do. However real time graphics usually use linear RGB. If the texture is not in the correct color space for how it is used then it will appear incorrectly.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
Regular BGR as far as I know.
I know the color model is BGRA (with possibly strange alpha channel if using indexed color) but I am asking what the color space is. Color space is how the color values translate into actual light intensities. In linear color space doubling the value doubles the light intensity. In sRGB space doubling the value can increase the intensity by approximately 4 times because it is approximately gamma corrected by a factor of 2.2.

This is important for blending operations because if you blend lineary then white (1.0) and black (0.0) become 0.5 which if put through sRGB is not half as bright as white. Hence why real time graphics use linear color space and then gamma correct at the end (the gamma setting in WC3, SC2, D3 etc). Since D3D9 you can use sRGB textures for real time graphics however they are still converted to linear color space for shading operations, although that conversion is hardware accelerated. As WC3 is D3D8 it obviously uses linear color space textures, so the question is if the BLP loading component converts them from sRGB to linear or if they are already linear to start with?

This book thing sort of explains why it makes a difference.

I wonder if hundreds of WC3 asset creators have been doing it wrong over the last decade?
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
Again, regular BGR, as far as I know. My viewer shows things exactly like they do in the editor, and there's nothing explicit in it.
Except the "regular" is sRGB for most images and devices with linear RGB only being used for image processing, eg shaders.

I assume you mean linear RGB? That would be the regular for shaders and what loaded textures will be assumed as unless specifically declared as sRGB (a feature added to graphics APIs after WC3 was made).

Here is an image to demonstrate the difference it makes.

Linear%20RGB%20v%20sRGB.jpg


Left is what the texture looks like if interpreted as Linear RGB and converted to sRGB while trying to correctly preserve intensity levels. Middle is what it looks like if treated as sRGB. Right is what it looks like according to "BLP Lab". Alpha channel has been removed for display purposes.

I would assume the left image is the correct interpretation? Looking at the body of the griffon it looks much more like an African lion than the others which appear tinted orange. Also you can see more detail as the image appears overall less dark, which makes sense as people generally do not paint such dark detail.

Assuming the left image was correct a question you may be asking is what will the game see an sRGB image as if it is not converted to linear RGB? Here is an sRGB interpretation which is hopefully vaguely accurate.

sRGB%20as%20Linear%20RGB.jpg


It appears a lot brighter than it should. Colours look faded, almost bleached. Shading detail is also lost.
 
Last edited:
I don't know if you still have Wc3 installed, but it is a simple check. Download that BLP, convert it out and back in BLP lab, import it into the game and determine if the colors have changed (you can import a copy of the model with a different texture path if you want to compare them side by side--or just take two screenshots and use color picker).

Then do the same for your linear RGB version. I feel like the middle/right ones are the correct interpretation, mostly just because I know Shadow Daemon tested his program (and the BLP format) quite extensively.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
Then do the same for your linear RGB version. I feel like the middle/right ones are the correct interpretation, mostly just because I know Shadow Daemon tested his program (and the BLP format) quite extensively.
This has nothing to do with extracting the pixel values. Those are right as they do not change between left and middle image. It has to do with the color space the pixel values are in.

To put it simply, making sure an orange is truly orange and not orangey red or orangey green.

Color space defines the mapping between color values and real life colors. The left image is the result of interpreting the pixel values are linear RGB (like how OpenGL and D3D operate in) and the right image is the result of interpreting the values as sRGB (what most images and displays operate in).

To clarify images are displayed with sRGB by default by all browsers and almost every display will use sRGB color. As such the left image is an sRGB interpretation of what it looks like in linear RGB color space since I cannot show it to you directly in the linear RGB color space. This means that the pixel values are different from the original image, but only for purposes of displaying it correctly to viewers.

This is important for a color managed workflow. Specifically when creating textures for games which do not support sRGB textures. Assume you paint a texture in sRGB color space. Before the game can use it you need to convert it into linear RGB color space which involves adjusting the pixel values using a color space translation function. The game can then use this linear RGB texture for filtering, lighting etc to produce an image of the game scene for display. Finally before this image is displayed, it undergoes gamma correction, by default 2.2 although that is not entirely accurate, to convert it from the linear RGB color space used by the shaders to the sRGB color space used by displays.

If you fail to translate your sRGB texture into linear RGB then it will suffer from color distortion. Like wise if you fail to correctly set the gamma at the end of the shader results, the colors will appear distorted.

In this case I am extracting images from blp files. Blp files being textures might assume linear RGB color space. As such to display the texture accurately to a user, eg for UI or image preview, a color space conversion is required from linear RGB to sRGB so that the colors appear as they should.

Looking at the left Griffon image it looks more like an African lion in color than the right, which look very orangey. Like wise the darker details are brighter and more pronounced in the left image. As such that might be what the texture looked like when it was painted and before being converted into linear RGB for use by the game.

In image editing software like Adobe Photoshop you can apparently alter the color space used by images. This lets you directly produce linear RGB images while still having the color results display correctly in the sRGB space used by your display. Doing this avoids the need for color space conversion and the associated loss in image quality.

I think I can confirm that the game does not undergo color space conversion when loading textures an orange of 254 red and 127 green stayed in the 1:2 ratio independent of lighting which is not possible if it was converted from sRGB to linear RGB for use by the shaders. It would also appear that World Edit screen shots are not gamma corrected, as that orange had the same color ratio in the screen shot which if it was gamma corrected it would not have.

Screenshots taken by WC3 are not gamma corrected. You can set WC3 to be gamma corrected but by default the screenshots are not. I have two demonstration images for people.

In%20Game%20Wrong%20Gamma.jpg



In%20Game%20Correct%20Gamma.jpg


The orange on the tree was engineered to be 1.0, 0.5, 0 in a normalized linear color space. This means that it was intended that the green component was half maximum and the red component was maximum. Notice how in the uncorrected image it appears more red than after correction. This is because the green pixel values are physically half the red pixel values but the image is being displayed in sRGB color space so the green is considerably less than half the perceived red brightness. After gamma correction the orange is much stronger, and looks more like orange one would expect.

Interesting note is how bright and saturated WC3 looks. These are kinds of the effects described if one forgets to color space correct textures. Is it possible Blizzard messed up big time and forgot about color spaces? Or is this how we are meant to be seeing Warcraft III and anyone viewing it any differently has been viewing it wrong.

I do apologize for the wrong aspect ratio of the image. It is due to me using a wide screen monitor and forgetting about aspect ratio when taking the images.
 
Last edited:
Thanks for the explanation, but what is the point? If we can't use Wc3 as a baseline for what is "correct", then how do we determine the truth of the matter? So far, it looks like the main justification is that the left's color looks more like that of an African lion, but that is debatable.

So here is a question: how would you prove what color space Wc3 is in?
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
So here is a question: how would you prove what color space Wc3 is in?
I already have...
  1. Shaders at the time WC3 was made could only support linear RGB textures, hence will be working on and with linear RGB.
  2. BLP files load colors with the same channel value ratio as put into them. This means BLP files are loaded directly as linear RGB.
  3. The output for Warcraft III screenshots shows colors in the same channel value ratio as the colors put in. This means that the screenshot output is in linear RGB space.
  4. Color channel ratio is preserved by lighting meaning that the shaders are working in linear RGB space.
  5. The orange looks a lot more red before correction, which is expected as the green channel which is meant to be half as perceivably bright as the red channel is less than half as bright due to the non-linear response of displays.
  6. Applying a gamma correction factor of 2.2 (value 44) transforms the WC3 output image into approximately sRGB color. The orange now looks more orange and less red as the green channel should be approximately half as perceivably bright as the red channel when displayed.

The only question remaining is if Blizzard messed up by not understanding how D3D/OpenGL works, or if practically every skin and icon maker has messed up by not understanding how WC3 works?

I found this low quality youtube footage which shows brightness similar to the gamma correct output. However it is not high quality enough to really tell. There is a surprising lack of official WC3 videos showing gameplay as intended by Blizzard.
 
Last edited:

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
Bumping this with possibly more proof that textures are in linear color space. The mipmaps with Blizzard textures do not follow normal sRGB resizing rules.

The theory being that when halving the resolution in both axis to produce the mipmap each resulting mipmap pixel will have the average brightness of 4 pixels from the level below. If the image is in linear color space this is as simple as averaging the 4 pixel values for each channel. If the image is in non-linear color space you need to apply gamma correction to linear color space before averaging can be done and then convert the result back to non-linear color space. Significantly different results can be produced from both approaches, especially on edges where bright pixels meet dark pixels. This is because combining a black pixel with a white pixel to produce a grey half as bright as the white will produce a pixel value of ~128-127 in linear color space but 186 in non-linear color space, a difference of ~60.

So I found 4 suitable pixels...
Code:
255	255	166 Very Bright
195	150	55   Bright
165	128	45   Bright
0	3	12   Dark

Then did the maths...
Code:
163	149	64 Mipmap Pixel
154	134	70 Linear Computed Pixel
183	165	94 Non-linear Computed Pixel

- 9 -15 + 6 Linear Computed Pixel Error 
+20 +16 +30 Non-linear Computed Pixel
Given that the image was JPEG compressed it would be impossible to get exact results. However the results obtained showed significantly more error when using a non-linear assumed resizing algorhtim than a linear one. Further more the non-linear approach error was biased to be always positive by a large amount which one could expect given the input pixels if the image was resized linearly.

Error in the results could also be the result of reduced color precision. If the images were painted in sRGB or other color standards and then converted to linear color space to become a texture, then the mipmaps could have been generated directly from the original image resulting in more precise pixel values. Since the experiments were conducted on the texture which if one assumes is in linear color space they will be less accurate as much color precision has already been lost.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,286
One final bump to clarify things once and for all...
Again, regular BGR, as far as I know. My viewer shows things exactly like they do in the editor, and there's nothing explicit in it.
The editor is rendering the scene incorrectly as it lacks a final gamma correction stage. It displays the linear RGB fixed shader pipeline results directly without applying the required gamma correction. These results are also the results dumped to screenshots in game. Hence the resulting pixel color and brightness results are wrong.

BLP textures are linear RGB textures. They are loaded as such so treated as such by the fixed shader pipeline WC3 uses. This means that to correctly create them you need to gamma correct RGB channels of textures to gamma 1.0 from ~gamma 2.2 of sRGB which most art work is done in. Alpha is always linear so does not need correction.

WC3 screenshots need to be gamma corrected from gamma 1.0 to gamma 2.2 in order to be correct. This is shown in the example screenshots above.

Failing to perform gamma correction appropriately will result in any of the following display issues.
  • Colors made from different color channels in significantly different ratios are reproduced incorrectly due to significant differences in color intensity.
  • BLP mipmap levels are computed incorrectly as the downsize blending is performed wrong (good algorithm is average of 2*2 pixels, but sRGB resize factors in gamma 2.2 so is not average).
  • Pixel brightness is computed incorrectly by scene lighting. The non-linear nature of sRGB will incorrectly add a non-linear component to the lighting results making shaded pixels far darker than intended by the light.
  • The results of tri-linear filtering (if enabled) will be wrong as they assume linear blend mechanics such as used by mipmap computation.
  • Alpha blend results will be incorrect as they assume linear color response.
  • Tinted light blending will appear incorrect as they assume color linear results.

People who think WC3 cannot possibly be as bright as shown are delusional. If you look at the MDL specification of the environmental lights they have a diffuse magnitude of 1.3 with an ambient of 0.1-0.3 for a maximum pixel brightness of 1.4 to 1.6 times the texture brightness. To put it in perspective, you will have little problem seeing what is going on with a 0.1 brightness light, although you will notice it is quite dim.
 
Status
Not open for further replies.
Top