精确地将float 32转换为unsigned short或unsigned char

Question

First of all sorry if this is a duplicate, I couldn't find any subject answering my question.

I'm coding a little program that will be used to convert 32-bit floating point values to short int (16 bits) and unsigned char (8 bits) values. This is for HDR images purpose.

From here I could get the following function (without clamping):

static inline uint8_t u8fromfloat(float x)
{
    return (int)(x * 255.0f);
}

I suppose that in the same way we could get short int by multiplying by (pow( 2,16 ) -1)

But then I ended up thinking about ordered dithering and especially to Bayer dithering. To convert to uint8_t I suppose I could use a 4x4 matrix and a 8x8 matrix for unsigned short.

I also thought of a Look-up table to speed-up the process, this way:

uint16_t LUT[0x10000] // 2¹⁶ values contained

and store 2^16 unsigned short values corresponding to a float. This same table could be then used for uint8_t as well because of the implicit cast between unsigned short ↔ unsigned int

But wouldn't a look-up table like this be huge in memory? Also how would one fill a table like this?!

Now I'm confused, what would be best according to you?

EDIT after uwind answer: Let's say now that I also want to do basic color space conversion at the same time, that is before converting to U8/U16 , do a color space conversion (in float), and then shrink it to U8/U16. Wouldn't in that case use a LUT be more efficient? And yeah I would still have the problem to index the LUT.

Answer 1

The way I see it, the look-up table won't help since in order to index into it, you need to convert the float into some integer type. Catch 22.

The table would require 0x10000 * sizeof (uint16_t) bytes, which is 128 KB. Not a lot by modern standards, but on the other hand cache is precious. But, as I said, the table doesn't add much to the solution since you need to convert float to integer in order to index.

You could do a table indexed by the raw bits of the float re-interpreted as integer, but that would have to be 32 bits which becomes very large (8 GB or so).

Go for the straight-forward runtime conversion you outlined.

Answer 2

Just stay with the multiplication - it'll work fine.

Practically all modern CPU have vector instructions (SSE, AVX, ...) adapted to this stuff, so you might look at programming for that. Or use a compiler that automatically vectorizes your code, if possible (Intel C, also GCC). Even in cases where table-lookup is a possible solution, this can often be faster because you don't suffer from memory latency.

Answer 3

First, it should be noted that float has 24 bits of precision, which can no way fit into a 16-bit int or even 8 bits. Second, float have much larger range, which can't be stored in any int or long long int

So your question title is actually incorrect , no way to precisely convert any float to short or char. You want to map a float value between 0 and 1 to an 8-bit or 16-bit int range.

---

For the code you use above, it'll work fine. However the value 255 is extremely unlikely to be returned because it needs exactly 1.0 as input , otherwise values such as 254.99999 will ended up being truncated as 254. You should round the value instead

return (int)(x * 255.0f + .5f);

or better, use the code provided in your link for more balanced distribution

static inline uint8_t u8fromfloat_trick(float x)
{
    union { float f; uint32_t i; } u;
    u.f = 32768.0f + x * (255.0f / 256.0f);
    return (uint8_t)u.i;
}

Using LUT wouldn't be any faster because a table for 16-bit values is too large for fitting in cache , and in fact may reduce your performance greatly. The snippet above needs only 2 floating-point instructions, or only 1 with FMA . And SIMD will improve performance 4-32x (or more) further, so LUT method would be easily outperformed as it's much harder to parallelize table look ups