Weird Alpha mode needed?


#1

Hi,

I’ve run into a weird problem where i need to use 3 alpha channels for a color.

DESTr = ALPHAr * COLr + DESTr*(1-ALPHAr) DESTg = ALPHAg * COLg + DESTg*(1-ALPHAg) DESTb = ALPHAb * COLb + DESTb*(1-ALPHAb)

Another way to look at this is to want to set each pixel to (color - dest)*alpha + dest, ie to move the destination pixel color by a proportion of its difference to a reference color. The three alphas being different for each RGB of the destination.

any ideas?


#2

That’s pretty obscure! I guess you’d need to use Image::BitmapData to grab the pixels and then get/set the argb values from the PixelARGB values directly…


#3

obscure it is! But not completely useless.

Its related to this problem of subpixel rendering. I have a 3 channel bitmap in “RGB” format, that’s actually not RGB. The values in each channel correspond to alpha intensities to be used against a given colour.

It’s easier to explain in terms of the normal rendering. When i have a bitmap glyph, i have a single channel bitmap that represents intensities of the text colour to use. ie a single alpha channel. But when subpixel rendering, the output bitmap is 3 times wider and corresponds to alpha channels for each of the R,G and B of the text colour.

This is how it gets its correct colour edges on the glyph pixels that work for any given text colour and against any background.

So im stumped on how to draw this effect because it requires blending with the current screen colour behind - whence the alpha blend.

To conclude, having a special draw mode for this would be too obscure. But it makes the case for user supplied blends to be given to the draw functions, or at least ones chosen from a palette of predetermined ROPs.


#4

Ah, I see. To sub-pixel render glyphs, I think the best approach would actually be to leave the font rendering alone, but change the software renderer code and hack the stuff that renders the edge-tables, and make that do the sub-pixel stuff. Doing that would be quite a self-contained change, and would work for all kinds of rendering, paths as well as fonts.


#5

That would indeed be a general solution, you’d have all of Juce support sub-pixel rendering!

FWIW, im not hacking the juce font rendering at all, this experiment is a stand alone use of freetype. I use freetype to generate my bitmaps, then i want to blit them. Obviously, i only get the funky sub-pixel font rendering for things drawn by this special component.

I had everything working apart from this last step. I wanted to see how it looked and whether it was worth it. If i assume the text colour is black against a white background, i can cheat and just use a normal draw. However, annoyingly one glyph clips another in this “hack” where corners overlap i dont get the correct blend.