2) But you can. As long as you know that you have a valid float number. Which means as long as you have assigned one first and told the compiler "I assign a float number to a float".
Originally Posted by Elysia
3) I agree it is better. It will save you the trouble for all kind of bugs. But memory might be a problem since he is mentioning millions of floats. And I mention the cache because for the Main Memory millions of floats is nothing. But for the cache memory it is.
But I ll stick to 1). It is not a good idea to make premature optimizations. But that is what he asked. He might be in the final state for what I know. I don't say it will be faster or slower. I say that it will be faster IF he is right about the way he thinks it will be used. That way is for the Bitmap to be in the cache memory so he can reuse it right away.
If you store float numbers in the Bitmap, load another Bitmap, do a lot of things, then store colors in the first Bitmap, it might not be present in the cache, so you won't gain anything. You might as well have a float Bitmap and a color Bitmap and just load whichever you need. If you use it right away though it might make sense to do it this way.
Other solutions that require multiplying/dividing by a number will possibly have an error due to rounding. So it won't be a good idea.
And if the float is 8 bytes instead, for example, then you can do the same thing, as long as your COLOR class will have space to store it. If not then you cannot do it.
Has this not already been done on most every video card via floating point textures??? I really don't understand the issue here.
And if these are colors then how are you going to render an infinite amount of colors onto a surface that only has the ability to represent a finite amount of colors?
The only way I know of to represent colors as floats is to maintain that there is a max value for each RGB and then the RGB components are simply normalized. The final color is a simple equation based on the color depth of the device and can be normalized or non-normalized.
The intent of this post really makes no sense to me. And what does thickness of color mean? That again makes no sense to me. Alpha blending is just fine for 'thickness' if you want to put it that way.
Every color I work with in Direct3D is already represented as a float so again I'm confused. Now you could take a color cube and represent the final color as 3 floats which represent it's normalized 3D position in the color cube and extract a color from that. This is common practice in industries such as glass manufacturing when they want to monitor their glass manufacturing process and find out 'where' in the color space they are. I was involved with this at a recent job but will not go into the details in order to protect possible copyrighted information. However for computers storing a color as a 3 normalized cube coordinates just does not makes sense to me since you must do some nifty calculations to find out what the final color is and your final RGB components. AFAIK alpha cannot be represented in a 3D color cube and would be represented as an infinite collection of color cubes all at a different alpha or an alpha cube which would give the final alpha as 3 normalized coordinates into the alpha cube. This value would then be used on the final color values in the standard alpha blending equation. Super overkill here.
There is a ton of information on the internet about color theory and various color spaces.
upon closer inspection, i see that the fundamental problem is that there's a disconnect between what was asked and what was intended.
c_ntua and i answered the question that was asked, but that doesn't appear to be what the OP meant to say.
sure, if you aren't using the A channel, i suppose you could use that byte to store some floating point value with 1/255 resolution.
float thickness = (float)((color&0xFF000000)>>24)/(0xFF);
Ok, so you have a 3d object. At every point of the object you will have a "thickness".
You want to produce a bitmap to display an image that will be a grayscale representation of the object's thickness. (Top down picture of a mountain, peaks are black valleys are white).
So as you read in a thickness, you want to hava a float value between 0.0 and 1.0? And you want to be able to take a RGB value of say, (175, 175, 175) and store it into a float as 0.5? (and vice versa)
If that is the case couldn't you use a RGB function that accepts floating point values instead of integer? ( 0-1 instead of 0-255).
Turns out that the color class I will be working with is using floats to represent the components so I won't be relying on those floats to get rounded correctly when using the union approach. Seemed like a good solution but I won't be able to use it. The floats themselves in that class gets limited to steps between 0 and 255 though in that class so I can't use them to store any values. So it is back to the qriginal question... how to use a color class that stores values between 0 and 255 to represent a float?
Example: I have a float value of 5640.854f. I want to assign that to a color that has r,g,b,a values from 0 to 255 and then later be able to read the color value to get back the float. Pretty simple actually, not sure what the fuzz is about.:)
I won't be changing the way the color class works either so that needs to be assigned values from 0 to 255. (or as I described acbove... float values that represent 0 to 255)
I calculate the thickness in the first step which may go anywhere from 0.0 to 1000000.0. That value needs to be stored as a color in the bitmap. In the second step I will retrieve the floats that the colors represent and clamp them between 0.0 and 1.0 based on what the minimum/maximum thickness are.
Originally Posted by shoutatchickens
So I need to take a float value and convert to color and back.
This may not be the most common approach but if I can find a way to do it that represents the floats accurately enough then I will save memory, speed and have a simplified code structure. Surely that would be a good thing.
What about this:
Take the color value, say R first.
You want it to have 3 digits no matter what so yo ucan store it in the first 3 positions of a variable.
So for R, you could first check if it's under 100, if it is, add 300. << 6 so that it will be the 3 most significant digits.
When doing the reverse, take your varialbe and >> 6 and check if it's over 255, if it is, subtract 300.
Repeat with the other values except shifting the correct amount for the poisition.
you're not providing enough information to say, there's a number of ways it could be done.
the most logical assumption would be to assume a first order linear relationship between the two mapping schemes like so:
intVal ≅ floatVal*(maxInt - minInt)/(maxFloat - minFloat)+minInt
where maxInt and minInt would be 0xFFFFFF (0xFFFFFFFF if your upper byte is relevant) and 0, respectively.
...or you aren't actually reading my posts. The information you need is simple. We have 4 values that go from 0 to 255. How do we best make them represent a float value that is as big as possible with as many decimals as possible? (3 decimals is minimum)
Originally Posted by m37h0d
Not sure what you are doing there in your example really.
And btw, I don't know much about bitwise operations so do explain a bit if you post an example like that. May very well be the way to go...
I'll just assume you were talking about my post there.
Originally Posted by DrSnuggles
Multiplying and dividing by 1,000,000 is just about the same as shifting 6 places.
What I was suggesting is you have a floating point of osmetihng this large:
If that is the case then you could just say.
To get the colors back out you would
R = 50;
G = 150;
B = 25;
if (R < 100) R = R + 300;
R = R * 1000;
if (G < 100) G = G + 300;
if (B < 100) B = B + 300;
B = B / 1000;
yourFloat = R + B + G;
Note: I am just throwing an idea off the top of my head and am taking absolutely no considerations about the floating point data type or it's limitations and/or rounding issues
R = yourFloat / 1000;
if(R > 255) R = R - 300;
perhaps the information is there, but it is not clear. however, being that you are using some other class that undoubtedly has some algorithm for interpreting floats as colors, i suspect that you may need to use that same algorithm.
what i'm doing above is elementary discrete calculus. the simplest possible numerical approximation for dY/dX = (Y_2-Y_1)/(X_2-X_1)
dY = dX*(Y_2-Y_1)/(X_2-X_1)
Y = X*dY/dX+X_0
this gives you an expression to relate one variable to another in this case, you are relating dFloat with respect to dInt, or vise-versa
that's one possible way to map related values to one another
"the question was, essentially, how to convert a 4 chars (possibly aggregated as an int) to a float. "
Was it? That is trivial. Though the post has long been edited, he rejected the first solution outright.
It seemed to me as if he wants to freely convert something that requires 32 bits of representation to something that doesn't represent 32 bits. (Actually, his latest post originally said something that still makes me think that.) This is fine, and again, trivial. He also rejected that, and again the post has been edited.
Now he says he the class is using 'float' to store each RGBA component in the class anyway and yet still asks how to represent the combined values as a single 'float'.
I still don't get what he is doing. Why does he need to represent all four values as a single 'float' unless he intends to perform some operations on the value? Does he just want to normalize the values?
I'm asking anyone that seems to understand what the OP wants to do. I'm not interested in how he apparently wants to solve it. I want to know what he is trying to solve.
i don't know, honestly. the OP provides instructions that don't appear to align with it's intended function (there is a 'bug' in his question, if you will :) )
at this point, i think we just need to communicate with a more precise language than english. here's my best guess as to what he's trying to do:
drsnuggles, please discuss how this may or may not accomplish what you're trying to do. i think at this point, code will be the clearest means of communication.
unsigned char pixel;
unsigned char &a;
unsigned char &b;
unsigned char &g;
unsigned char &r;
unsigned int &intVal;
const float minFloat;
const float maxFloat;
color(const float _minFloat,const float _maxFloat) :
intVal(*(unsigned int *)pixel),
intVal = 0;
int main(int argc, char* argv)
c.intVal = 0x00AABBCC;
float f = c.asFloat();
You say you want to do it this way to make it more efficient. You may save a couple of Mb's by reusing the bitmap, but all this converting back and forth will probably affect the speed negatively. Not to mention your bitmap class which may have an overhead when accessing each pixel (as opposed to an array of floats that you can access directly).
If you still insist on reusing the bitmap then go for the union approach (or a reinterpret cast). A float (32 bit IEEE 1/8/23 single precision) converted to 4 bytes will still be the same number when converted back, assuming no one messed with those bytes. Then ignore whether people scream this is not an elegant solution, you kinda gave that up anyway reusing bitmaps :)
The conversion does not need to be exact, 3 decimals will do and the conversion always starts with a float. It needs to be able to convert from float to the color and back. I havn't rejected anything but havn't seen a complete solution so far.
Originally Posted by phantomotap
I also said that the float values in the color class I use are limited to steps between 0 and 255, so I don't have unlimited float values to work with there. They should rather be treated as integer values between 0 and 255. This is not relevant to the question of the thread though. Just wanted to note that when talking about not being able to use the union approach so that nobody would suggest the thing you just did.;)
Originally Posted by phantomotap
I want to store a float value in each pixel of a bitmap to be able to later get the float value for each pixel. I don't want to store it as a float but as a color value rgba that somewhow represents the float by some logic. What is there to not understand? It is the logic for how the conversion is done that is the challenge here.
Originally Posted by phantomotap