TYPO3 Core

Bernhard, could you please have a look at this? Thanks!

The attached patch works (the original code had typos),
though I think this depends on the ImageMagick version and use of GD or something like that (no time to take a look at it further) and should at all events be revised before adding it to the Core.

This wont work, since the offset that is used to move the cropping area around the image is not taken into consideration.

It will take at least two different crop actions and a bit more calculation with the percentages after the "c" suffix to get the same cropping results as with the original GIFBUILDER setup but with 24bit colordepth.

Working patch attached ...

To make the m.mask feature work with cropscaled images too, I created a new diff.
It sets a new $data Array based on the size of the cropscaled image.

Sorry - I have to admit that I misunderstood how the crop command works. So the first approach seems to be the best solution.

Anyway we would need the newly crated $data Array after the operation so that the m.mask feature will get the correct size of the image.

Will add a new patch.

As far as I can see, it is not necessary to call imagemagick twice. With my patch (class.t3lib_stdgraphic4.diff) "resizing" and cropping is performed with one command, which saves time and should lead to a better quality (by reducing the number of jpeg de-/encoding steps).

Furthermore the original patch introduces a factor 1/2 in the calculation of the crop offset, which leads to a different image detail than the original implementation. I don't know whether this was intended.

Finally, the $data array is not used after the imagemagick-call as far as I can see. Therefore I don't see any need to update it. It might be useful to update the $info array (or at least $info⁰ and $info¹). However, the original implementation didn't do that either.

The patch4 worked for me! Thank you so far!
Btw. I came to this issue, because I do not have GDLib installed and wondered why cropping needs GDLib (or simply produced a white screen with no error message)

I tested patch4 in RC1 and it works perfect !

Why is'nt it integrated since now ? This Bugpost is quite old ...

Please integrate it, without cropscale makes no sense !

Bastian, the info array is update near the end of the function if $params is set. So instead of changing $command, the patch should modify $params, to force the update.

Hi Martin,

the $command is added with $param. Before it was
$command = $this->scalecmd.' '.$info⁰.'x'.$info¹.'! '.$params.' ';

Bastian changed the $command and added it afterwords.

Do you mean to add the modification at the and like that ?
$command.=$params.' '.$tmpParams;

ah - i think i see what you mean:
if ($params) { ...
to update the info. For this case only this has to be changed:

$params.= ' -crop '.$data['origW'].'x'.$data['origH'].'+'.$ofX.'+'.$ofY.'! ';

i made the changes Martin mentioned and tested, it works for me.
It's in crop_scale.diff

Please can you check this.

have you tried to cropscale GIF images? I get very strange results in 4.1RC2. With JPG images everything works like expected. Very strange.

edit:
After applying the last patch 'crop_scale.diff' everything worked fine.

The crop_scale.diff patch is fine for me.

can this fix go to svn ?

Today i had this problem on a server, that the cropscaled were gif and created with wrong filecreatemask, applying this patch helped and everything worked as it should (jpg and right filecreatemask).

Lately I had again a problem with cropscaling GIF images, even with the applied patch that worked allready on the same server. I used graphicsmagic and the results where very strange. The image dimension where correct, but the offset of the image inside the cropping-canvas was wrong. After switching to ImageMagick5.x the problem was gone. Very strange though. I tried to debug this but couldn't find any bug. The parameters given to the IM/GM-command seemed to be correct (as far as I can say) - and it worked by only switching to IM, so it might be a GM bug?

Dummy question... sorry

How can i install the "class.t3lib_stdgraphic4.diff" file in SSH,
which command do i have to use?

Thank you!

Addition to my note from 04.04.2007:
The cropscaling finally worked again after I defined the resulting image-type to be always "jpg", so the problem appears only when the source and resulting image are gif. And as mentioned it also appears WITH the applied patch 'crop_scale.diff'.
Hope that helps debugging somehow as I haven't been successful on debugging myself.

@Bas - patch should be your friend (http://www.die.net/doc/linux/man/man1/patch.1.html)

@Franz Koch - yes, gif is problematic. I also see a bad quality with gif files, I'm not sure if this is a side effect or still exists before.

Would it be possible to include the patches into the CORE files? I guess this is a very useful function, especially if you want to have a lot of control over your images. And for non developers it's not that easy to add the DIFFs through
GNU-Tools even it's not impossible ;-)

thanks indeed

+1 For inclusion in CORE!

hey guys - will it make it into 4.2? It'll be very nice, because currently the image quality is crap.

I just tried to apply the patch on 4.1.3 - but I get some errors there. It seems to write jpg-data into a file with gif file extension and then tries to use the image as gif which of course fails. Haven't found a solution so far.

I can not reproduce the issue Franz-Xaver Koch mentioned. The patch works perfectly with all my TYPO3 4.1.5 installations...

Works for me too... PLEASE integrate this... At the Moment the croping-functionality cannot be used due to extreme bad quality.

Added current path aginst 4_2 branch

@Benno:
This issue is pending in core list to be integrated at least in TYPO3 4.2.
I don't know if this will also go into 4.1.x, as it may be considered as a feature rather than a bugfix.

• TYPO3_4-1 (rev. 3447) --> TYPO3 4.1.7
• TYPO3_4-2 (rev. 3448)