is it wrong to use floats to store images?
Author
currently I'm writing a bunch of classes to easily load and filter images... each class starts by allocating a bunch of memory to store the floats of the image.
Is it worth the hassle to rewrite these classes into using chars? will the increase in speed be noticeable?
Depend on what you want to do with the images...
use floats if you want to "edit" the images, either by making effects and stuff. Floats makes much sure that you don't loose information in the process.
like bluring, lightning etc etc...
If your idea is to do "photoshop" on the images ... then floats
If your idea is just displaying or simple editing ... then char (or int, byte+byte+byte+byte = int )
use floats if you want to "edit" the images, either by making effects and stuff. Floats makes much sure that you don't loose information in the process.
like bluring, lightning etc etc...
If your idea is to do "photoshop" on the images ... then floats
If your idea is just displaying or simple editing ... then char (or int, byte+byte+byte+byte = int )
It's not really a speed issue, more a size issue. A char (rather, 24 bit RGB) takes up one quarter the memory of a float based version. Speedwise, on modern processors it will be slower due to the increased amount of memory access being done.
Skizz
Skizz
agree - but then again, back to what you want to use it for
lets take a simple example - brightness /contrast
Think this is lua or something...
Just think it works on a x by y image...
This code is slow, but create a good adjusting on the image. +you can adjust with small amounts. This creates a good image.
Doing this on an image based on char is not a smart idea if your goal is good images.
If speed is important, then you might sacrifice speed for quality, and do it with char... but then you adjust the brightness /contrast differently
lets take a simple example - brightness /contrast
Think this is lua or something...
float brightness = 0.2float contrast = 1.5for y=0, height-1 do for x=0, width-1 do r,g,b,a=pget(x,y) //function return r,g,b,a from pixel r=(r-0.5)*contrast+0.5+brightness g=(g-0.5)*contrast+0.5+brightness b=(b-0.5)*contrast+0.5+brightness pset(x,y,r,g,b,a) // function sets r,g,b,a on pixel end progress(y/height) // don't rememberendJust think it works on a x by y image...
This code is slow, but create a good adjusting on the image. +you can adjust with small amounts. This creates a good image.
Doing this on an image based on char is not a smart idea if your goal is good images.
If speed is important, then you might sacrifice speed for quality, and do it with char... but then you adjust the brightness /contrast differently
Author
Quote:Original post by Skizz
It's not really a speed issue, more a size issue. A char (rather, 24 bit RGB) takes up one quarter the memory of a float based version. Speedwise, on modern processors it will be slower due to the increased amount of memory access being done.
Skizz
but a float is 32-bit and so are most modern day processors... won't this minimize the difference in speed of floats and chars?
(unless ofc 1 32-bit instruction can reserve 4 chars)
Author
Quote:Original post by DarkSlayer
Depend on what you want to do with the images...
use floats if you want to "edit" the images, either by making effects and stuff.
that's the idea :)
Quote:Original post by ShaiQuote:Original post by Skizz
It's not really a speed issue, more a size issue. A char (rather, 24 bit RGB) takes up one quarter the memory of a float based version. Speedwise, on modern processors it will be slower due to the increased amount of memory access being done.
Skizz
but a float is 32-bit and so are most modern day processors... won't this minimize the difference in speed of floats and chars?
(unless ofc 1 32-bit instruction can reserve 4 chars)
The bit width of a processor is a very misleading metric. It's usually the width of the native integer type. The floating point size has nothing to do with this. In fact, the 16 bit versions of the x86 processors (8086, 80186, 80286) could still handle 32 bit floats. You can also specify 64 bit floats as the 'double' type. Floats will be slower than using chars because FPU operations are slower and you're using much bigger data sets, but they will be more accurate. Also, if you want to you can use the MMX (for char based) or the SSE (for float based) extensions to manipulate the RGB values in parallel.
Skizz
If you want a 3.40282367+e38 colour bitmap then be my guest, but I imagine it's a little overkill.
If you only want to manipulate a bitmap then that's different, you usually aren't doing that sort of thing in realtime, so IMHO the extra accuracy would be worth it.
Then again, if it was accuracy you were worried about, you might be better off using an 8.8 or 8.24 fixed point representation for each component, but that's a lot more work.
If you only want to manipulate a bitmap then that's different, you usually aren't doing that sort of thing in realtime, so IMHO the extra accuracy would be worth it.
Then again, if it was accuracy you were worried about, you might be better off using an 8.8 or 8.24 fixed point representation for each component, but that's a lot more work.
why don't you just normalize them when you load them.
r = (float)red/256.0f;
g = (float)green/256.0f;
b = (float)blue/256.0f;
(alpha, if necessary)
and then store them as chars? Why waste disk space? You just do the conversion somewhere before putting them into your class.
r = (float)red/256.0f;
g = (float)green/256.0f;
b = (float)blue/256.0f;
(alpha, if necessary)
and then store them as chars? Why waste disk space? You just do the conversion somewhere before putting them into your class.
Author
thnx guys I'll store them as chars and convert 'em to fixed point notation
*goes searching for a good fixed point tutorial*
*goes searching for a good fixed point tutorial*
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
