Is there a trick or instrument (GDI+,FreeImage,Draw, whatever) allowing to print transparent PNG image on standard Clarion REPORT target?
Image itself is a customer signature drawn with black color. The rest of pixels are transparent. Sample image here:
The problem is that such an image appears as black signature on black background in a REPORT when using standard Clarion {PROP:ImageBits} property assignment. The result is just a black rectangle.
I see at least two acceptable ways:
Replace transparency with white color. Clarion has no problem to print such an image.
Print image as is (with transparency) on top of other REPORT controls visible from behind.
The latter is preferable. Any hint will be greatly appreciated.
I’m thinking that your only option is going to be option #1, or render the transparent image over another solid color image with tools that allow you to do that.
I don’t know whether this is the problem with PNG, but one issue could be that Clarion uses the 80000000h bit as a switch to indicate that this is a system color (such as COLOR:BtnFace, etc). So any notion of transparency in a bitmap goes out the window, unless Alpha channel is supported.
The PNG decoder in the CW RTL uses the incorrect color depth value for your test image. As result, “unused” pixels are displaying/printing without blending. The image is displaying in a WINDOW incorrectly too. I know how to fix this problem. The fix is being sent to SV.
Windows metafiles do not support the AlphaBlend function. If a report is not printing directly to the printer, the RTL uses the StretchBit function for images with alpha channel. Of course, result of printing such controls is unexpected but there is no other way until switching to EMFs.
Thank you so much for deep insight, AlSo. It would be nice if SV will apply your fix in C11.1 or C12 build some day “soon”. But I need a solution right away in C10.
Clarion works great with the GIF format that supports transparency (and in reports). You can try converting PNG to GIF “on the fly” using the FreeImage library …
Additionally, there seems to be a problem with that particular image. It is color type 6 (RGB with Alpha channel) but Alpha channel is 0 in every pixel (both the intended to be transparent and the intended not to be). You can see in Windows Explorer preview of the file that it is also showed as a black rectangle.
PrintImage PROCEDURE(STRING p_FileName, WINDOW p_Window, LONG p_ImageFeq)
fi FreeImageClass
CODE
fi.iImage.Load(p_FileName)
If fi.iImage.IsTransparent()
fi.iImage.Composite(COLOR:White)
End
fi.iImage.CopyToImageControl(p_Window,p_ImageFeq)
Problem solved. Thanks ALL and EVERYONE for pointing me to the right direction. Much appreciated!
I was confused about all transparency bytes being 0 in that image.
Instead, all RGB color bytes are 0 (black)
Transparency bytes, as opacity in PNG, are as 0x00 where there is no signature, and mostly 0xFF and some bytes with intermediate values on the signature pixels.
This is not so. Most pixels, yes, have the alpha channel value equal to 0 => they shouldn’t be displayed/printed. But some pixels have not-0 alpha channel values after unpacking the tRNS block to RGBA. Only these pixels form the image.
Really, the test image is quite unusual. It has no the IDAT block which usually contains information about pixels. Moreover, the single PNG file can contain multiple IDAT blocks. The test image codes pixels as conjunction of palette from the PLTE block and transparency parameters from the tRNS block.
If I recall correctly rules for naming PNG image blocks, the 1st upper-cased characters means that the block is mandatory. If so, the format of the test image is incorrect. I have several image processing programs that display it as fully black. Even Corel’s program (PaintShop Pro X9) among this list.
It is interesting. We were looking at two similar but internally different images. Oleg dual posted here and on SV newsgroup. My test were using the one from newsgroup, which is colortype 6 (RGB with Alpha channel) while the one here is colortype 3 (Palette) + tRNS chunk. Perhaps Discourse made that change automatically.
This value is in the file header. The PNG_COLOR_MASK_ALPHA mask is adding to the color_type value during processing the tRNS chunk - in pnglib this is doing in the png_read_transform_info function.
Probably, some programs do use the color_type value from the header only before the PNG stuff finished processing all the data. The problem in CW is that parameters for the producing stream of pixels in RGB/RGBA for building a DIB calculated incorrectly for the test image because its data is really unusual.
