# What is the difference between 32 Bit Float and 32 Bit fixed pixel types?

I am using a real time graphics program that offers the following "pixel formats". I understand many of them but one thing I do not understand is the difference between `float` and `fixed`.

Why would someone use one over the other? They both take up the same amount of space so I do not see how one could offer more precision.

• I don’t know which application you are using but if it’s derivative: Fixed point formats, regardless of if they are 8 or 16 bit, can only represent values between 0 and 1. Floating point formats can represent very large values and very small values, both negative and positive. From the derivative wiki :) Apr 14 '16 at 19:16

So basically, "float" means that it stores a significand and a base exponent. A "standard" 32-bit float uses 1 bit for sign, 8 bits for exponent and 23 bits for signifcand. The key here is that the scale (the exponent) is stored with the number.

"Fixed" is stored hi-word/low-word "packed". A 32-bit fixed point is probably going to be a 16 bit integer before the radix and 16-bit integer after (the decimal part). This does not comport with @elegent's comment about a range between 0 and 1: that link may be implementation specific, I don't know. It sounds to me like that implementation uses all 32 bits for the decimal portion and then relies on context for scale (the exponent) or that they are leveraging a color-model (likely) that uses the same range.

Regarding precision: the number of bits available does not equate to better precision on its own, but I am completely unqualified to speak about the distinctions beyond the obvious overflow/underflow issues.

https://stackoverflow.com/questions/8638792/how-to-convert-packed-integer-16-16-fixed-point-to-float

https://stackoverflow.com/questions/7524838/fixed-point-vs-floating-point-number

In the context of your screen-capped menu: they are using fixed as a synonym for integer: 8-bit fixed (rgba), means 8-bits per pixel, where each byte is represents an integer value between 0 and 255.

• I also don’t really understand the explanation on the wiki: "each pixel of the Texture Operators will have 8-bits of information for each of it's R, G, B and A channels … a 8-bit texture can only store values between 0 and 1 for each of its R, G, B and A channels …" I don’t get it :) Apr 14 '16 at 20:10
• @elegant: what you quote is confusing, because they use "8-bit" in two contexts: the first mention is "8 bits per pixel per channel (RGBA) = 32 bit, and then they immediately switch context to an 8-bit texture (2 bits per pixel per channel). I am still confused however, since 2-bits can be {0,1,2,3) or if the high-bit is sign, it can be a range {-1,0,1,2). Then again, the TOPs link mentions a TOPs flag, so perhaps 4-bits for flags, 4 bits for colors = 8 bits total. Apr 14 '16 at 20:23
• I want to point out, though, that the modern miracle of computing is predicated on using a single numeric representation (which is really an abstraction of an on-off switch) to do everything that computers do. So the context switching and plastic nature of the representation is a feature as much as a bug. Apr 14 '16 at 20:25
• fyi @elegent that is actually the software I am using, (nice job recognizing it from nothing but a pull down window). Apr 14 '16 at 20:25
• @elegent: got it right in the body, wrong in the comment :) Apr 14 '16 at 20:37

Lets keep things simple by thinking about a monochrome image.

To represent out image we cut it up into a grid of pixels and record a number representing the light intensity at each pixel. For simplicity lets assume that the value linearly represents the ammount of light (reality is a little more complicated than that, but it's close enough for now).

However we still have to actually represent that number as a bit pattern. There are an infinite number of possible light intensity values but only a finite number of possible bit patterns of a given size. Clearly we must make a compromise.

There are basically two strategies for representing numbers on computers, fixed-point and floating point (integers can be considered a special case of fixed point). There is also the question of signed verses unsigned.

In a fixed point number we fix the scale factor in advance. So for example to represent numbers in the range 0 to 1 inclusive we might use a 32-bit unsigned number with a scale factor of 1/(232-1).

In a floating point number we allow a range of scale factors to be chosen. We do this by splitting our bits up. Some bits are used to store a binary number and other bits are used to store what power of 2 to scale that binary number by (there is a bit of extra trickery in practice, read IEEE 754 if you really want the gory details). With floating point numbers we can store a very wide range of numbers but the precision varies depending on the value of the number.

When dealing with a camera, screen or printer our hardware determines the darkest possible and lightest possible values and typically breaks up the possible values in between in a roughly equal manner. Negative values don't really make any physical sense since there is no such thing as negative light.

On the other hand when we get into the world of 3D modelling it can be useful to represent a much wider range of brightness values. There can be a vast difference in brightness between the brightest and darkest parts of the world and while negative light doesn't physically exist that doesn't mean you can't have it in a 3D model. So formats using signed floating point numbers can start to make sense.

Of course there is a price to pay. The 32-bit signed floating point number can represent much larger and much smaller values than the 32-bit unsigned fixed point number but in some cases it will have a lower precision.