UWORD to String/LONG
On 17/04/2014 at 18:48, xxxxxxxx wrote:
Cinema 4D Version: R14
Platform: Windows ;
Language(s) : C++ ;
I'm trying to get the alpha value of an image, via GetAlphaPixel(). The alpha is placed in a UWORD, but setting the alpha again is done via a LONG.
How do I correctly convert a UWORD to LONG (and/or string so I can print)?
On 18/04/2014 at 03:46, xxxxxxxx wrote:
The compiler will handle it automatically. There is no problem converting from UWORD to a LONG
since all the values the UWORD can represent (2^16) can be represented by the LONG, too. (2^31
in positive range).
It can be problematic when converting the other way round since UWORD can not represent
negative numbers or numbers higher or equal to 2^16. But when you keep it in the range of 0
and 255 (which is what the docs tell you about the alpha pixel stuff), there should be no
The compiler will do the conversion automatically, but the values could be truncated.
Just use String::IntToString() to convert even the UWORD to a string. (or LongToString() for
R14 and older).
On 20/04/2014 at 18:15, xxxxxxxx wrote:
I thought that was how it works as I couldn't find anything in the docs otherwise, but thought I should ask just in case..!
I'm getting some strange values printed after using it to get the alpha pixel value. I must be doing something else incorrect. Will need to dig into it a little more.
On 21/04/2014 at 12:34, xxxxxxxx wrote:
It is of course dependent on the color mode.
Is it for example COLORMODE_ARGBf (Floating point RGB channels with floating point alpha) or RGB (8-bit RGB channel) or plain alpha colormode_Alpha (only 8 bit alpha channel).
So, it depends what data you are using (where is it coming from) and how to interpreted it.
On 22/04/2014 at 02:46, xxxxxxxx wrote:
As I can see from documentation the values are always only 8bit (The valid range of val is 0 to 255.)
UWORD val = 0; GetAlphaPixel(ch,x,y,&val); print(val); //should pring something from 0 to 255 SetAlphaPixel(ch,x,y,val);
But using GetPixelCnt() / SetPixelCnt() is faster and much more flexible, it also works with Float textures for MultipassBitmap.
On 22/04/2014 at 03:45, xxxxxxxx wrote:
Ok, thanks folks, I seem to be making some progress again. I had been using ScaleBicubic() on the bitmap, but changed that to ScaleIt(). I don't know if that has made any difference to the alpha values or not, but that was changed never-the-less.
The second part I changed was to update my for loop to include some steps that calculated the new pixel value based on what was already in the GeClipMap, and comparing it to the new pixel color data, and applying the two together by using the alpha value to calculate the percentage of change in color required between the old and the new. Not sure if that makes sense... but it's working!
On 22/04/2014 at 03:51, xxxxxxxx wrote:
Ah, Remo, I hadn't realised you'd made a post. I'd been sitting on a message all day but I kept changing and updating it as I went along until a few minutes a go!
For the purpose of 'coding', is a float bitmap a 32b bitmap?