Bug #15726
closed
No 100% transparency/opacity with file.mask
0%
Description
When overlaying images using the file.mask, the colours will always come out wrong.
Example:
Create a GIFBUILDER object with white (#ffffff) background, overlay a 100% green image (gif, #00ff00) with a mask (gif) that is 100% transparent on the left half (#000000) and 100% opaque on right other half (#ffffff). In theory you should get a new image that is #ffffff on the one side and #00ff00 on the other side.
What you get is different, though: The left side will be something like #f9fef9 and the right side #04fe04.
The Reason for this issue is quite trivial:
maskImageOntoImage() in t3lib_stdgraphic uses TYPO3's wrapper function imagecreate() to create all image objects needed in the masking process. If GD2 is used, these images will always come out as true color images. When the images are written to disk, they have to be converted back to 256-color palette images, and this is where the color aberration happens.
Set $truecolor = false and the images come out perfect.
Proposal: If the source files (background, overlay, mask) are 256 color palette images, they should never be converted to truecolor images in the masking process since converting them back will usually return bad colors. The PHP reference for imagetruecolortopalette() admits these problems ("This does not work as well as might be hoped.").
(issue imported from #M2702)
Files
Updated by Wolfgang Klinger over 18 years ago
Bernhard, can you take a look at this? I think it has todo with your recent patches.
Updated by Bernhard Kraft over 18 years ago
Har :)
This issue was not really related to the masking algorythm.
Transparency get's set when everything is finished completly. Then the color which is set to be transparent get's marked as transparent colors. Or if more than one colors are set to be transparent they get "unified" to one transparent color by a nifty algorythm :)
The problem was that when you set #ffffff as backgroundColor for your image this was the very first assigned color and got index "0" ... When setting the transparent color I did a check
if ($Tcolor) {
which of course failed for a color index of "0" (I just read up that imageColorExact which returns the index of a color in an image returns -1 if it fails - I fixed that in the patch attached to this bug note)
I also changed some code which disables truecolor completly if .gif or non-truecolor .png's are going to get generated and transparency get's used.
Real-life examples showed that in most cases transparency didn't work properly there because those images got color reduced at the end and then transparency got lost.
Also when reduceColors get's used and transparency together then truecolor get's disabled.
This is al incorporated in the diff:
gifbuilder_transparency_2006-03-09.diff