Where color images read into an image_map and the x,y position is found 
to be outside the image(a) the code makes those pixels transparent. It's 
a cool feature about which I did not know. Basically you can implement 
old style sprite animations with color images on a plane. Set the 
background to rgbt <0,0,0,1> and render with +ua and the alpha channel 
transparency carries through to the output file.

The problem is the transparency was being set to rgbft <1,1,1,0,1>. I'll 
let the comments I added to the code say the rest.

bool ColourImagePattern::Evaluate(...)
...

if (map_pos(EPoint, pImage, &xcoor, &ycoor))
{

// Below, for many years, was <1.0, 1.0, 1.0, 0.0, 1.0>. However, this
// led to incorrect channel values when the image_map was accessed by
// channel or by a limited subset of channels as with functions using
// ().gray, for example(b). Making the RGB channels 0.0 aligns behavior
// with that of other pigment{} related methods like pigment_pattern
// which hard codes a return of 0.0 on seeing false, image_pattern does
// a map_pos() check and if off the map hard codes a return of 0.0.

result = ToTransColour(RGBFTColour(0.0, 0.0, 0.0, 0.0, 1.0));
return false;
}
else
...

Bill P.

(a) - This happens while using 'once'.

(b) - In existing releases you can sometimes change/align the behavior 
by knowing about the hidden internal code - and where not otherwise 
using an alpha channel, filter or transmit. Something like this is ugly, 
but get you to black for the outside pixels.

pigment {
     function {
         FnPgOnly(x,y,z).gray*(1.0-FnPgOnly(x,y,z).transmit)
     }
}

Post a reply to this message