1

It is good way to convert color from Linear space from 0.0 to 1.0 into sRGB space from 0 to 255 by using Lookup table in this manner?
Example, in Java:

byte[] table;
void initializeTable()
{
    table = new byte[65536];
    for(int i = 0; i < table.length; i++){
         float Lin = i / (float) (table.length-1);
         if(Lin<=0.0031308f)
            table[i] = (byte)(255*(Lin*12.92f));
         else
            table[i] = (byte)(255*(  (1+0.055f)*Math.pow(Lin,1/2.4f)-0.055f)  );
    }
}

int sRGB(float Linear/*in range 0..1*/) // Will return  0..255 integer sRGB
{
    return 255 & table[(int)( Linear*(table.length-1) )];
}
biv
  • 1,613
  • 3
  • 13
  • 21
  • 1
    So are you looking up two bytes or one? – 2501 Dec 14 '14 at 07:37
  • 1
    @2501 that's not a duplicate. the linked question is requesting a linear to linear component conversion. sRGB is not linear. – justin Dec 14 '14 at 08:05
  • I was update a little a Code. ↑↑↑ ↑↑↑ – biv Dec 14 '14 at 08:30
  • The problem with tables that big is that don't fit into L1 or L2 cache on ARM devices (or modest x86 devices). The cost of a cache miss is significantly more expensive than ... well maybe not Math::Pow, but definitely more expensive than a sensible approximation. You may want to benchmark to make sure you're really speeding things up. – Robin Davies Aug 20 '23 at 00:03

1 Answers1

0

Yes, that looks fine to me. You can probably use a smaller table, in fact.

If I were feeling pedantic, I'd say that your conversion from float to int always makes the value slightly darker. You can improve that by changing line 6:

float Lin = (i+0.5) / (float) (table.length-1);

or by changing line 16:

return 255 & table[(int)( Linear*(table.length-1) + 0.5 )];

but not both. Either fix centres the rounding error at zero. However, the rounding error still exists, and it is so small that it's not really worth mentioning, so I think your code is fine.

apt1002
  • 969
  • 6
  • 15