Bug #36947

GIFBUILDER render twice

Added by Florian Zimmermann over 8 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
TYPO3 Release Team
Category:
Image Cropping
Target version:
Start date:
2012-05-08
Due date:
% Done:

100%

TYPO3 Version:
4.7
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Hello,

my problem is that Image Layers on a GIFBUILDER IMAGE are rendering twice.
First on the Position 0,0 of the GIFBUILDER IMAGE and then at the offset Position. See attached
TEXT Layers are ok.

Here my Code.

$imageArray = array(
    'img' => 'IMAGE',
    'img.' => array(
        'file' => 'GIFBUILDER',
        'file.' => array(
            'format' => 'jpg',
            'quality' =>80,
            'XY' => '300,200',
            'backColor' => 'white',
            '1' => 'IMAGE',
            '1.' => array(
                'file' => 'fileadmin/img/right_teaser_bg.jpg',
                'offset' => '10,0'
            ),
            '2' => 'IMAGE',
            '2.' => array(
                'file' => 'fileadmin/img/main_image.jpg',
                'offset' => '35,0',
                'file.' => array('maxH' => 200)
            ),
            '3' => 'TEXT',
            '3.' => array(
                'text' => 'TEST TEXT',
                'fontSize' => '12',
                'fontFile' => 'fileadmin/fonts/arial.ttf',
                'fontColor' => 'white',
                'offset' => '150,40',
            ),
            '4' => 'IMAGE',
            '4.' => array(
                'file'=>'fileadmin/img/icon.png',
                'mask'=>'fileadmin/img/mask_icon.png',
                'offset' => '0,90',
                'file.' => array('maxW' => 300)
            )
        )
    )
); 

I use debian squeeze 6.0.4 with imagemagick 6.6.0.4 and PHP 5.3.10-1.
On TYPO3 4.5 everything runs fine.

de942a5766.jpg View - Error (12 KB) Florian Zimmermann, 2012-05-08 12:41

f5871266ed.jpg View (116 KB) Florian Zimmermann, 2012-05-09 09:50


Related issues

Related to TYPO3 Core - Bug #37060: GIF with transparant background turns black Closed 2012-05-10
Related to TYPO3 Core - Bug #26660: imagecopyresized has invalid function parameter Closed 2011-05-06
Related to TYPO3 Core - Bug #39563: Regression in t3lib_iconWorks::imagecopyresized Closed 2012-08-06

Associated revisions

Revision 6bc116e7 (diff)
Added by Lorenz Ulrich over 8 years ago

[BUGFIX] Fix refactoring regression in imagecopyresized

t3lib_stdGraphic::imagecopyresized was refactored to make it
unit-testable in #26660. This change had a regression. When GIFBUILDER
is used with a mask, the mask is copied to the mask instead of the
source image.

Change-Id: Ice2a1cf86f36aed7b429fccd28563782e65966a4
Releases: 4.7, 6.0
Fixes: #36947
Reviewed-on: http://review.typo3.org/11984
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Florian Zimmermann
Tested-by: Florian Zimmermann
Reviewed-by: Andreas Bouche
Tested-by: Andreas Bouche
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn

Revision ab720c0e (diff)
Added by Lorenz Ulrich over 8 years ago

[BUGFIX] Fix refactoring regression in imagecopyresized

t3lib_stdGraphic::imagecopyresized was refactored to make it
unit-testable in #26660. This change had a regression. When GIFBUILDER
is used with a mask, the mask is copied to the mask instead of the
source image.

Change-Id: Ice2a1cf86f36aed7b429fccd28563782e65966a4
Releases: 4.7, 6.0
Resolves: #36947
Reviewed-on: http://review.typo3.org/12074
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn

Revision 863f5dd7 (diff)
Added by Lorenz Ulrich over 8 years ago

[BUGFIX] Fix refactoring regression in imagecopyresized

t3lib_stdGraphic::imagecopyresized was refactored to make it
unit-testable in #26660. This change had a regression. When GIFBUILDER
is used with a mask, the mask is copied to the mask instead of the
source image.

Change-Id: Ice2a1cf86f36aed7b429fccd28563782e65966a4
Releases: 4.7, 6.0
Fixes: #36947
Reviewed-on: http://review.typo3.org/11984
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Florian Zimmermann
Tested-by: Florian Zimmermann
Reviewed-by: Andreas Bouche
Tested-by: Andreas Bouche
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn

History

#1 Updated by Florian Zimmermann over 8 years ago

Hi,
i have right now tried the GIFBUILDER from the wiki, and it is still the same problem.

lib.test = IMAGE
lib.test {
file = GIFBUILDER
file {
XY = 1024,768
format = jpg
quality = 88
10 = IMAGE
10.file = fileadmin/backimage.jpg
15 = IMAGE
15.offset = 420,18
15.file = fileadmin/overlay.png
15.mask = fileadmin/mask.png
  1. 15.mask = fileadmin/mask_i.png
    }
    }

#2 Updated by Florian Zimmermann over 8 years ago

Hi,
now tested with Image Magick 6.6.7.1 Same thing. Rendering Twice. Please could someone proof on his own Server what happend?
Thx in advance

Florian

#3 Updated by Kai Tallafus over 8 years ago

Same problem here - using GraphicsMagick Version 1.2.10

#4 Updated by Florian Zimmermann over 8 years ago

  • Target version set to 4.7.1
  • % Done changed from 0 to 100

ok have found the bug and fix it.
Please change

class.t3lib_stdgraphic
Function imagecopyresized
Line 442
imagecopyresized($tmpImg, $srcImg, 0, 0, 0, 0, imagesx($dstImg), imagesy($dstImg), imagesx($dstImg), imagesy($dstImg));
to
imagecopyresized($tmpImg, $dstImg, 0, 0, 0, 0, imagesx($dstImg), imagesy($dstImg), imagesx($dstImg), imagesy($dstImg));
JIHHAA!

#5 Updated by Florian Zimmermann over 8 years ago

  • Assignee set to Xavier Perseguers

Please add the fix. GIT i do not understand right now.

#6 Updated by Florian Zimmermann over 8 years ago

  • Assignee changed from Xavier Perseguers to TYPO3 Release Team
  • Target version changed from 4.7.1 to 4.7.2
  • % Done changed from 100 to 80

#7 Updated by Johanna Brütsch over 8 years ago

I could solve problem also with lines below of Florian Zimmermann, before had both issues:
Black Background and twice pictures // Schwarzer Hintergrund und doppelt geladene Grafiken

Typo3 4.7.1
GraphicMagick 1.2.7

Thanks.

#8 Updated by Gernot Ploiner over 8 years ago

It would be great if you insert this function, to generate alpha-transparent PNGs. At the Moment only Alpha-Transparent Layers in GIFBUILDER are possible.

In File: t3lib/class.t3lib_stdgraphic.php at Line 439 replace the function with this function:

function imagecopyresized(&$im, $cpImg, $Xstart, $Ystart, $cpImgCutX, $cpImgCutY, $w, $h, $w, $h) {
static $counter = 0;
if ($this->imagecopyresized_fix && !$this->saveAlphaLayer) {
$im_base = imagecreatetruecolor(imagesx($im), imagesy($im)); // Make true color image
imagecopyresized($im_base, $im, 0, 0, 0, 0, imagesx($im), imagesy($im), imagesx($im), imagesy($im)); // Copy the source image onto that
imagecopyresized($im_base, $cpImg, $Xstart, $Ystart, $cpImgCutX, $cpImgCutY, $w, $h, $w, $h); // Then copy the $cpImg onto that (the actual operation!)
$im = $im_base; // Set pointer
} else {
if ($this->saveAlphaLayer) {
imagealphablending($im, TRUE);
imagealphablending($cpImg, TRUE);
}
imagecopyresized($im, $cpImg, $Xstart, $Ystart, $cpImgCutX, $cpImgCutY, $w, $h, $w, $h);
}
}

#9 Updated by Florian Schaeffer over 8 years ago

The provided patch fixes the problem only for the first rendererd item on the page.

I refined lib.headerData.5 (graphical headline) and include a arrow in front of the headline using an offset.

  • Without using your patch I get the arrow rendered twice (0,0 and on offset position) and black background
  • with using your patch and removing the offset I get both elements on the page rendered with correct background and arrow at 0,0
  • with using your patch and including the offset the first element on the page is correct (arrow only one time and correct background) but the second element now again has both arrows and black background

So there must be still something weird going on (global variable?, same image used twice as destination?). If I use a GIFBUILDER-object two times on one page the second one is messed up when using offset...

#10 Updated by Florian Zimmermann over 8 years ago

Florian Schaeffer wrote:

The provided patch fixes the problem only for the first rendererd item on the page.

  • with using your patch and including the offset the first element on the page is correct (arrow only one time and correct background) but the second element now again has both arrows and black background

So there must be still something weird going on (global variable?, same image used twice as destination?). If I use a GIFBUILDER-object two times on one page the second one is messed up when using offset...

Hello,

have you truncate your typo3temp/pics and typo3temp/GB folder? When i was testing the whole process i have the same thing.
First image great second image bad because of caching.
Please test it
Thx
Florian

#11 Updated by Andreas Bouche over 8 years ago

Obviously a mistake that happened during the refactoring of the imagecopyresized method.
I came across a similar problem while using a gifbuilder-generated mask under TYPO3 4.7. Versions 4.5 and 4.6 rendered the image correctly.
Using the above fix from Florian Zimmermann or the implementation from TYPO3 4.6 fixed this Problem.

I already commented on the patchsets that apply this change at
https://review.typo3.org/#/c/9608/ and
https://review.typo3.org/#/c/6829/

For the TYPO3_4-7 branch, this change has been integrated as Revision 98f73d8b. Related issue is #26660.

#12 Updated by Lorenz Ulrich over 8 years ago

@ Gernot Ploiner: There is only one bugfix/feature allowed in a change request. Please open an new issue for your feature request (alpha-transparent PNG).

@ Florian Zimmermann: I will take care of pushing the fix to Master (where it's already merged). Then it can be applied to the other versions.

#13 Updated by Gerrit Code Review over 8 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11984

#14 Updated by Gerrit Code Review over 8 years ago

Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/12074

#15 Updated by Lorenz Ulrich over 8 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 80 to 100

#16 Updated by Riccardo De Contardi about 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF