TYPO3 Core

This bug is already reported by me, look bug 285 (http://bugs.typo3.org/bug_view_page.php?bug_id=0000285)

with the attached patches for me it's working know. I raised the quality to 65536 colors.
You have to set $GLOBALS['TYPO3_CONF_VARS']['GFX']['gdlib_png'] to true even if your gd supports gif, the reason for this is that this way the temporary images are created as png, too. Png can handle more than 256 colors which results in a better quality.

after using the patches there might be problems with GIFBUILDER/GMENU but I'm not sure whether this behavior is the normal behavior because I'm using GMENU the first time now...

I've attached updated versions of the patches.

Does this problem still exist? I just tried the above example with the newest CVS source, and for me, the generated file has a lot more than 256 colors - even though the text is rendered into the image. Is this generally like this now or should I post my configuration here?

I tried it, and the color loss is clearly visible (unmodifed 3.8-branch)

the attached patch still doesn't work for me...

The 2005-05_19_bugfix_760-gifbuilder1.patch works, but it's sloooooow. It took convert about 10 minutes to work on the image, and while the quality was nice, it's very slow.

It's a lot faster if no -colors option is given at all (tested on the command line).

I tried the latest patch (2005-05-19_bugfix...) and it seems to work except for one problem.
When an image gets masked onto an other then the mask image (alpha layer) isn't allowed to have an alpha-layer. Images created in PHP with the imagecreatetruecolor(...) function always have an alpha channel. So it is not allowed to create the mask image with the truecolor function. But the problem is that the real mask image needs to get copied onto a temporary one. And this temporary one needs to be truecolor because of the PHP imagecopyresized bug.

I choose the following solution: Change the line
$theMask2 = $tmpStr.'_mask2.'.trim($GLOBALS['TYPO3_CONF_VARS']['GFX']['im_mask_temp_ext_noloss']);
in t3lib_stdgraphic.php (~ line 339) to
$theMask2 = $tmpStr.'_mask2.gif';

so always a gif file will be used to store the mask. As a mask is always greyscale it won't have ever more than 256 colors so gif is ok. And the real reason why this works is that gif has no alpha channel. MIFF and PNG do have. So I use IM to remove the alpha channel.

for me the latest patch works only when setting [GFX][gdlib_png] = 1 in the install tool. But with this setting there are some warnings and a final fatal error in t3lib/class.t3lib_iconworks.php leading to not rendering the list view at all for some pages.

The warnings are occuring on lines 477, 348, 396, 450, 451. The fatal error finally occures on line 453.
Fatal error: Call to undefined function: imagemagickcommand() - which indeed does not exist in class.t3lib_exec.php

Last patch works for me but generates relatively large png's. I used TypoScript to convert the resulting PNG to a JPG, conserving precious bandwidth. This causes a tradeoff between CPU-load (I have plenty of CPU power) and bandwidth (which is paid by the gigabyte).

temp.JPG = IMAGE
temp.JPG.file < temp.PNG.file
temp.JPG.file {
quality = 85
format = jpg
}

This patch:

GIFBuilder_Truecolor_Patch.diff

was made during the "Zap the Gremlins" project and is special in such a way that it retains complete downwards compatibility. This means you will have to set the TS variable "reduceColors" to -1 if you want you images to be truecolor.

Set it for every GIFBUILDER and IMAGE object .... like this:

lib.test = IMAGE
lib.test {
file = GIFBUILDER
file {
format = jpg
quality = 90
XY = [10.w],[10.h]
reduceColors = -1
10 = IMAGE
10 {
file = fileadmin/user_upload/test.jpg
file {
reduceColors = -1
}
}
}
}

why should I want to set this (another) option? It's just another gremlin...
The whole thing should work out of the box

I've changed the default to generate truecolor image.
I've deleted the old patch and uploaded the new as in the old one there was also a debug statement which disabled image caching.
So anybody who wants lowcolor images (in GIFBUILDER/IMAGE/IMG_RESOURCE and Image/Text w. Image elements) has to set the appropriate config variable "reduceColors" to 256.

I think setting the default to truecolor will not be accepted by Kasper. I would rather make it configurable via the Install Tool.

The patches I made were simple: if GD supports truecolor (and you want a JPEG) use it.

I see NO reason not to use truecolor. And please ask Kasper for his preferences before assuming anything.

I don't know if anyone else has encountered this problem or if there is a easy way to solve it but i've tried most of the supplied patches (including the newest one) with the result, that if the niceText Option is activated the generated Images are all black.

After installing the Patch the Effect can be seen right from the InstallTool (in the Image Processing section -> GD library functions) where the Test of the niceText-Processing fails (outputing black Images).

The problem with nice text and some other operations (Shadow i.e.) was that they set a background color to the image. Before the patches (When palette images where used) the first allocated color was the background color.

With truecolor images this is different. You have to fill the image with the background color. I've deleted my yesterdays patch and uploaded a new one which fixes this issue.

The new patch is called:
GIFBuilder_Truecolor_2005-10-22.patch

This patch also finaly enables multiple transparent Colors for an image like it was intended.

You can try a new GIFBUILDER patch !

This one fixes the issue with niceText and others ! (Read bugnotes)

sorry to disapoint you, but it's still not working... I will send you an example via pm which I don't want to make public here

I attached a new patch.
GIFBuilder_Truecolor_2005-10-26.patch
With normal setup (no patches) and the static version of IM 4.2.9 (tested also a dynamically linked one) there is a problem with the makeShadow - text generation - method when png images are used (gdlib_png) - most probably this only occurs with gdlib2.
The new patch also fixes this problem.

Ingmars Problem is fixed. It was just a GIFBUILDER TS mistake.

I've just applied the latest patch (2005-10-26) and there's a minor bug which seems to make it unusable, at least under some circumstances (as the patch worked fine on another setup). Fix is simple. The patch has:

+ $theMask = $this->randomName.'.'.$this->gifExtension;

change that to:

+ $theMask = $this->randomName().'.'.$this->gifExtension;

You can try it out in the Install-Tool, "Image processing" section under "Combining images". Without the change, the call to convert doesn't have a valid filename for the mask so the whole process aborts. Unfortunately we get no error or warning about that. :(

Cheers,
Ernesto

The latest version (2006-01-19) should also work with GM. Negation wasn't set properly.

I send the latest version to CVS.

Don't forget to set [GFX][truecolor] to (X) in the install tool if you try the patch !

Hi Bernhard,

please remove [GFX][truecolor]. IMO it's just stupid to introduce a variable everybody would need to set and thus adding inconvinience. gifbuilder images are rendered truecolor inside but wirtten as 256color - who wants this actually?
And as I read you even havn't found a gd1 anymore...

<rant>sorry, but this variable is just bullshit</rant>

edit:
Bernhard, please don't take this personal, as I don't know you in person. But please take it from a usability point of view

I also used to think that the files will get bigger saving as truecolor, which would make the feature optional a reasonable choice, but I just learnt that this is not correct. In fact we will get even smaller files.

JPEGs are always stored as true-color bitmaps. If we give JPEG a truecolor image, there will similar-colored areas, so JPEG compression can work better. If we convert a truecolor image (photo) to a 256 colored bitmap, it will have a "paletted" effect, so the similar-colored areas are interrupted by "dots". JPEG will have more trouble compressing such a file: it will get bigger.

In my tests the resulting JPEGs with truecolor=1 were about 10% smaller than the original "non-true-color" JPEGs.

So +1 to just have this feature added without a switch. Just check if GD2 supports it and use it!

I agree with Ingo and Ernesto, when I want a JPEG I want true-color. Forget the variable and my good wishes to you that the patch makes it into rc1

But please compare the sizes of a "old" generated "PNG" and this of a "PNG" generated after the patch !!! There's a very big difference !

The only possibilty I see then (concerning your opinions) is that I output a "true truecolor" jpg if the ouptut file is .JPG, but when somebody outputs a .PNG it will get saved as palette image by default and only get written as truecolor when the user checks the option in the install tool

When we talk about unnecessary options in the install tool:
When IM5 get's used the "negateMask" option get's nailed down to "1".
But somewhen it was noticed that there are some IM around which don't like this.
Instead of taking aways the lock to "1" of the "negateMask" value a SECOND OPTION
"imvMaskState" was introduced which simply negated the value of "negateMask".

This would be a better place to start reducing options :)

Hmm,

when looking at programs like photoshop you're right. In photoshop one can choose between creating an 8-bit png or 24-bit png. So a [GFX][pngtruecolor] would be ok I think.

True, I wasn't considering PNG output.

Now I like the idea of having that configurable for PNG specifically, but one should be able to override this in a specific GIFBUILDER setup. I still might want to generate a 256-colored PNG even in a "truecolor" site for things that are not "truecolor-worthy" (menüs, etc).

So if GIFBUILDER's "reduceColors" property is respected (even in "truecolor" mode), that would be the best solution. Don't forget to adapt GIFBUILDERs docs in TSref! :)

So if GIFBUILDER's "reduceColors" property is respected (even in "truecolor" mode), that would be the best solution.

That is already very well considered in the latest patch !

Have a look at the new method IMreduceColors which get's used in applicable places (when final image get's created) and reduces the colors using imageMagick cause by this method it is possible to force the creation of palette based images for .png's

In IM4 this was automatically done when a .png had less than 256 colors but in IM5+ you have to force it using -Palette option and prefixing the output filename with png8 to write a 8-bit palette :(

Please report any problems concerning image generation and scaling.