Pixel Shaders: float & integer colors

I am guessing this is coming down to rounding rules etc. I would suggest a couple changes to your code to enhance your chances, and portabbility:

1. Don't use any integer variables, DX allow these to be emulated as floats. I am not sure how much wiggle room it allows for the handling.
2. Minimize your operations. Each one is adding error. You scale the numbers 4 times in your code. You only need to do it twice.

I would try this:

Code:

struct PS_INPUT { 
    float2 uv : TEXCOORD0; 
}; 

sampler image : register(s0);         // original image 
sampler watermark :register(s1);   // texture containing the bit pattern of the watermark in the blue channel 
      
float4 main (PS_INPUT In) : COLOR 
{ 
  float4 pix1 = tex2D(image,In.uv); 
  float4 pix2 = tex2D(watermark,In.uv); // read the bit 
  float tmp = floor(pix1.b*127.0); //clip the last bit

  pix1.b = tmp/127.0 + pix2.b/255.0; //add 8th bit based on watermark
  
  return pix1;  //put value 
};

Getting bit exact integer math is pretty hard with floats. Would you care if I stuck this in a piece of sample code?

Assuming it works, it is something that several developers would like to see.

-Evan

 

I'd suggest this:

Code:

struct PS_INPUT {
    float2 uv : TEXCOORD0;
};

sampler image : register(s0);         // original image
sampler watermark :register(s1);   // texture containing the bit pattern of the watermark in the blue channel
     
float4 main (PS_INPUT In) : COLOR
{
  float4 pix1 = tex2D(image,In.uv);
  float4 pix2 = tex2D(watermark,In.uv); // read the bit
  pix1.b = (floor(pix1.b * 127.9) * 2 + pix2.b) / 255.0;
  return pix1;  //put value
};

Code:

struct PS_INPUT {
    float2 uv : TEXCOORD0;
};

sampler image : register(s0);

float4 main (PS_INPUT In) : COLOR
{
  float4 pix1 = tex2D(image,In.uv);   // read texel
  float tmp = pix1.b * 255;
  float bit = tmp - (floor(pix1.b * 127.9) * 2);                 return float4(bit);
};

 

Evan, nice to see you here

I hate to say it, but your LSB clipping code won't work. When you insert 2/255 as pix1.b, you will get 0/255 as result. 255/255 will result in 255/255, but should be 254/255, so you can add 1/255 without overflowing.

The correct scaling factor is 127.5, but for numerical reasons it is better to use 127.9

 

Yeah, after I read your post, I realized it. I think I have been staring at too much code this weekend.

-Evan

 

Ahh but you can represent 1/3

 

Let's assume your texture contains integer values ranging from 0 to 255, which get mapped to float values ranging from 0.0 to 1.0 by dividing them by 255.
So
0 -> 0/255
1 -> 1/255
2 -> 2/255
etc.

Now you multiply those values by 127.5, use floor(), multiply by 2 and get this:
0 -> 0/255 -> 0 -> 0 -> 0
1 -> 1/255 -> 0.5 -> 0 -> 0
2 -> 2/255 -> 1 -> 1 -> 2
3 -> 3/255 -> 1.5 -> 1 -> 2
4 -> 4/255 -> 2 -> 2 -> 4
etc.

Seems to work... but only if x/255 can be represented perfectly accurate! Imagine the float representation of 42/255 is slightly lower than 42/255 itself. Then you get something like 20.99999 instead of 21, and the floor function gives you 20 instead of 21.
Using 127.9 makes sure the result is slightly above 21.