Bug #23018

Images don't get compressed

Added by Thomas Deinhamer over 9 years ago. Updated about 5 years ago.

Could have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Images which are put into text /w image or image only content elements won't get compressed (JPGs - I haven't tried PNG or GIF) by the "quality" setting of the backend IF the image's size fits or is lower than the defined pixel size in the content element. See the screenshot for details.

Imo even if the image doesn't needs to be resized, the compression should take place and a temporary image should get displayed. At present the origin path 'uploads/pics/home.JPG' will be used for displaying the image which is not the best solution.
(issue imported from #M14891)

image-compress.jpg View (106 KB) Administrator Admin, 2010-06-28 10:26


#1 Updated by Thomas Deinhamer over 9 years ago

In other words. TYPO3 should compress/lower the quality of the JPEG even if the x and y dimensions are lower than the maximum allowed with and height of the content element. For now this is not done or doesnt work.

#2 Updated by Jigal van Hemert about 9 years ago

In 4.5beta3 it works as expected: I put an "Images" element on a page, did not set the size, but only the quality and type to JPG/Very low. The file size of the image was reduced from 3.5K to 1.34K.
Setting the width to the original size did not change this.

Can you check in the latest 4.4.x version?

#3 Updated by Thomas Deinhamer about 9 years ago

Checked now on 4.4.6, and works.
Not sure what was wrong before but I could
have bet, that images which were smaller
than the max dimensions weren't compressed by default.

Add: Also works in 4.3.x. Unfortunately I
can't reproduce this anymore. =o(

Maybe I was wrong. Do'h!

#4 Updated by Jigal van Hemert about 9 years ago

Thanks for testing!
Closed because it works fine in current version of this branch and later.

#5 Updated by Thomas Deinhamer almost 9 years ago

Hello again! :D

To clarify this again. What is the expected behaviour of TYPO3
if I put images into a content element which are smaller than
the max width/height settings of the css styled content constants?

I'm talking about these settings:
  1. [styles.content.imgtext.maxW] This indicates that maximum number of pixels (width) a block of images inserted as content is allowed to consume.
  2. [styles.content.imgtext.maxWInText] Same as above, but this is the maximum width when text is wrapped around an imageblock. Default is 50% of the normal Max Image Width.

Cause I expect TYPO3 to compress ANY given image,
either of it's bigger than the max settings, OR even if NOT.

In a currect project images which are smaller then the
max settings don't get compressed and will be served directly
from the uploads/ directory: http://project.tpl/uploads/pics/not-compressed.jpg

I expect the path to be something like: http://project.tpl/typo3temp/pics/not-compressed_1234567890md5etc.jpg
even if the size of the images is smaller than the max dimension settings.

#6 Updated by Patrick Rodacker over 8 years ago

Hi Thomas,

I had a look into this in tx_cssstyledcontent_pi1::render_textpic() and tested the feature for 4.5dev and 4.6dev. The images get compressed even if they are smaller than the max settings.

If you are still experiencing the described behavior please provide some detailed information about which TYPO3 Version you use and which css_styled_content static template you have included.

#7 Updated by Thomas Deinhamer over 8 years ago

Hi Patrick!

Thanks for your feedback,
I really appreciate it.

Actually I don't use a content element,
but rather simple typoscript:

10 = IMAGE
10 {
file {
width = 705c
height = 346c

import = uploads/media/
import {
field = media
listNum = 1

(TS may be wrong in sense of syntax.)

I'd expect the generated image to be
coming from typo3temp, rather than returning
the original image path, also if the original
image is smaller than width and height.

Currently, if the image is smaller or has the exact
same size, it is not touched and the original path
to /uploads/media/<image.jpg> is returned.

Is this working as intended, or is there any way
to force TYPO3 to process the image anyway?

Thanks a lot,

#8 Updated by Patrick Rodacker over 8 years ago

So your current setup changed from the issue description. IMO the issue should stay closed and the discussion should continue on the mailinglist.

#9 Updated by Thomas Deinhamer over 8 years ago

Not sure if I'm able to communicate this well.

The following TypoScript constants are set:
styles.content.imgtext.maxW = 960
styles.content.imgtext.maxWInText = 960
styles.content.imgtext.linkWrap.width = 960

I add a content-element Text/Image to a page,
add a picture which is 640x480 to the element.

Let's say the picture is called 'cat.jpg'.

Now the output in the HTML source is:
<img src="/uploads/pics/cat.jpg" width="640" height="480" alt="" />

In my oppinion the output should be:
<img src="/typo3temp/pics/cat_7172f426e9.jpg" width="640" height="480" alt="" />

But this is not the case in TYPO3 4.5.3 on Windows.

Is this expected, working as intended, or is it a bug?

Why do I ask this?

Because if you have aggressive caching configured,
and you exchange an image, which will get served from
the upload directory ("/uploads/pics/cat.jpg") the
browser will show the locally cached image, instead of the new.

If TYPO3 would automatically create a new cached image
("/typo3temp/pics/cat_<MD5>.jpg") then the browser would
be forced to download the new image at all circumstances.

Is this working as intended or is this a bug?

Thanks for your patience,

#10 Updated by Thomas Deinhamer over 8 years ago

Eh, sorry - to even make it clearer;
Yes, I'm talking of two different cases.

One case is a content element with an image,
and the second case is an image imported with TS.

But in both cases, the image gets served
from the /uploads/media/ or /uploads/pics/ directory.


#11 Updated by Steffen Gebert over 8 years ago

  • Category deleted (Communication)
  • Status changed from Closed to New
  • Target version deleted (0)


#12 Updated by Helmut Hummel over 8 years ago

  • Priority changed from Should have to Could have
  • PHP Version changed from 4.3 to 5.2

The behaviour you describe is there since ages and personally I'm very happy with it, as it saves resources.

You describe two usecases, which should go into two feature requests.

  1. Invalidate caches if the image file changed, but the filename stays. For CSS and JS files this is solved by implementing [FE][versionNumberInFilename]. This could be extended for images as well. No need to pass the image through im or gm for that usecase.
  2. Respect image compression settings even if the original image has the same size as the to be rendered image. An option would need to be created, that the IMAGE cObject checks the compression level (if applicable) of the image and recalculate it, if the compression level of the original image is higher than the target level.

So I would suggest to close this ticket and you then can pick one or both usecases and create tickets (or even patch requests) for them.

#13 Updated by rack jackson over 6 years ago

I had my servers changed and I'm working my way through bugs.

My images processed with Typo3 won't show.

For example, go to [[http://www.domainregistrations.in]]

You'll notice that there is a black box on the right hand side where the
image is supposed to be.

I cleared all caches and nothing changes.

Here is the html of that box:

<!-- CONTENT ELEMENT, uid:16/textpic [begin] -->
<a name="16"></a>
<!-- Image block: [begin] -->
<table width="15" border="0" cellspacing="0"
align="right" class="imgtext-table"><tr><td rowspan="2"
valign="top"><img src="clear.gif" width="10" height="1" alt="" title=""
/></td><td colspan="1"><img src="clear.gif" width="4" height="1" alt=""
/></td></tr><tr><td valign="top"><table border="0" cellpadding="2"
cellspacing="0" bgcolor="black" align="left"><tr><td><img src=""
width="" height="" border="0" align="top" alt="" title="" /><br
<!-- Text: [begin] -->

&lt;p class="bodytext"&gt;&nbsp;&lt;/p&gt;
&lt;p class="bodytext"&gt;Deacur Income Tax Service provides bookkeeping and
accounting services. We process business and personal tax returns.
&lt;p class="bodytext"&gt;&nbsp;&lt;/p&gt;
&lt;!-- Text: [end] --&gt;
&lt;!--  Image block: [end] --&gt;
&lt;!--  CONTENT ELEMENT, uid:16/textpic [end] --&gt;

You'll notice that the img src is blank.

All other images such as the background and the flash work, and the logo
on the bottom of the screen, but I'm wondering if it's because this
image is processed through Typo3 (resized) if it's a problem.

If I click on Images, fileadmin/, and then the folder with the images,
the window shows I have my images there with the sizes and names, but I
can't actually see the thumbnail images in my back-end.

Any help?


#14 Updated by Georg Ringer about 5 years ago

  • Status changed from New to Closed
  • Is Regression set to No

since FAL there are now always references used which will be properly handled.

if the issue is still valid for you in 6.2 LTS, please reopen the issue.

Also available in: Atom PDF