Bug #48841
closed
TS-included PNG images corrupted in frontend
Added by Dennis Lümkemann over 11 years ago.
Updated over 11 years ago.
Description
I'm creating a footer menu with icons from the corresponding pages' resources. The images are PNGs with alpha transparency. Until 4.5.26 this worked fine. With the 4.5.27 update, the images are getting corrupted. (If I include the same pictures as page content, they are shown correctly.)
TS for the menu creation:
marks.FOOTERMENU = HMENU
marks.FOOTERMENU {
special = directory
special.value = 7
1 = GMENU
1.NO = 1
1.NO {
10 = IMAGE
10.file {
import = uploads/media/
import.field = media
import.listNum = 1
}
XY = 20,20
ATagTitle.field = subtitle // title
}
}
Typo3 4.5.27
IM 6.2.5
GD 2.0.32
SLES 10.2
PHP 5.2.5
Files
- Status changed from New to Needs Feedback
There were not that many changes between 4.5.26 and .27, and none of them involved anything related to image processing.
Could it be that some time ago something else, such as an update of ImageMagick, was changed on the server? With the update to 4.5.27 the image cache might have been emptied and the scaled images were re-generated, showing the effect of the other change.
IM 6.2.5 is actually quite old and it might be worth a try if a more recent version (6.8.5 is the latest) solves the problem. On the other hand, ImageMagick is known to be a rather problematic tool; GraphicsMagick has a much better history regarding stability, strange bugs, unexpected changes in bugfix level releases, resources (CPU/memory) usage.
If it is at all possible, switch to GraphicsMagick (you need to adjust some settings in the Install Tool).
I downgraded to 4.5.26 and after removing the references to the images and adding them again and clearing the cache, the icons looked correctly. I then upgraded again to 4.5.27 and after clearing the cache, the icons were corrupted. I removed the references, saved, added the references, cleared the cache - icons stayed corrupted. Then I downgraded again to 4.5.26 and did the same and the icons came back correctly.
(There seems to be a problem with referencing the same image from different page language page properties. I had to create copies of the files for every language. Is that normal?)
The server is not really in my hands so updating ImageMagick is not really an option. And to me it doesn't look like it's an ImageMagick problem, since it works ok with 4.5.26.
Is there maybe some way I can tell Typo3 not to process the images? They don't need to be resized or anything.
Thanks for trying the previous version. I'll have a closer look at the changes and see what might be the cause of the problem.
I found this issue:
http://forge.typo3.org/issues/34446
It fixes an issue with reducing the number of colours for PNG files when png_truecolor is false. The behaviour you see is at least that the number of colours are reduced and it is a PNG file.
Can you check if PNG truecolor is set in the Install Tool? If you enable it the images should be normal again (after clearing image cache).
I have
$TYPO3_CONF_VARS['GFX']['gdlib_png'] = '1';
$TYPO3_CONF_VARS[‘GFX’][‘png_truecolor’] = ’1′;
$TYPO3_CONF_VARS['GFX']['gdlib_2'] = ’1′;
I "successfully" reproduced this problem on another system. Images corrupted (but looking a bit different than on the first machine) after updating to 4.5.27. This server uses GraphicsMagick 1.3.12 on Squeeze.
Dennis Lümkemann wrote:
I have
[...]
$TYPO3_CONF_VARS[‘GFX’][‘png_truecolor’] = ’1′;
[...]
Just to be sure, you seem to have incorrect quotes there in this particular setting. Can you double check if this is the case?
Because with "png_truecolor" really set to "true", 4.5.26 should behave the same as 4.5.27 in this particular situation (not trying to "reduceColors").
Thanks for taking your time testing and giving us more information!
Correcting (all) the quotes fixes the problem!!! So Jigal, your suggestion was right, and thank you Ernesto for your sharp eye!
If someone else has this problem, set
$TYPO3_CONF_VARS['GFX']['png_truecolor'] = '1';
in localconf.php
So this issue can be closed?
- Status changed from Needs Feedback to Closed
Turned out to be a configuration issue. If png_truecolor isn't TRUE PNG file have their number of colours reduced (by default to 256 colours).
Also available in: Atom
PDF