Search

Nick, thank you for your reply :)

Indeed there is. Unfortunately it is a global property and is applied only to files uploaded as jpegs already, right?

What I'm looking for is possibility to turn pngs, bmps, gifs into jpegs "on the fly" as clients upload those. I've been working with iPhone/iPad painter recently and he had whole portfolio in png format. It's been very flexible to add phpthumbof=f=jpg&q=80 to image output template and have all converting job done automatically using phpThumbOf extension in MODx.

I understand such feature is not yet here. It would be lovely to have it though so I will definitely look into the code on my own and try to give something to community :)

Anyway, I'm working on my first project in Symphony and I love how smooth, quick and minimal admin panel is. That's basically what brought me here and I am sure my client will love it.

Once more, thanks! Greg

JIT certainly does process GIF, JPEG and PNG images and will attempt to output them in the same format. The quality setting is global in the config for all processing, but if I'm correct you're saying the functionality you need is:

  • to have a per-request quality setting
  • to always output JPEG regardless of input format

JIT does the resizing on the fly (when the image is requested, i.e. "Just In Time") and not as the user uploads them (probably "A Bit Longer Before Time"!) but I don't see much advantage of one over the other. I anything the JIT method allows you more flexibility so that you can tweak the output parameters (size, crop etc) on the fly.

We're in the process of adding "recipes" to the JIT extension. These are named sets of parameters, so that the JIT URL might look like:

/image/my-recipe-name/my-file.jpg

Instead of:

/image/2/200/100/5/my-file.jpg

Masking the parameters adds a little extra security, but it also means that the system knows about each desired image size at the point a user uploads a file. To this end, I've been working on another extension which, upon uploading a file to an entry (through any type of upload field), it will run the image through all recipes, creating the static output images. This bypasses the dynamic just in time nature of the extension, meaning you can ship these images off to a CDN for storage and delivery.

Anyway, I'm working on my first project in Symphony and I love how smooth, quick and minimal admin panel is. That's basically what brought me here and I am sure my client will love it.

Great to hear!

We're in the process of adding "recipes" to the JIT extension.

The recipes will also support a per-recipe quality setting. It still ouputs the image in the same format it gets uploaded, but you can have different quality settings for each recipe.

Well, thank you both for warm and informative welcome to the community :)

I will be looking forward to JIT update! Recipes sound useful.

Hi Greg,

If you're not adverse to a bit of hacking, you can do the following:

In extensions/jitimagemanipulation/lib/class.image.php you can set $output to permanently output JPGs - in the "render" function, I just added

$output = IMAGETYPE_JPEG;

to the top of the function.

However - I did have a problem when transparent pixels in PNGs were converted to black. In the "run" function in extensions/jitimagemanipulation/lib/filters/filter.resize.php, I just changed a couple of lines:

/* making the new image transparent */
$background = imagecolorallocate($dst, 255, 255, 255);
imagefill ( $dst, 0, 0, $background );      
ImageColorTransparent($dst, $background); // make the new temp image all transparent                
if(function_exists('imageAntiAlias')){
    imageAntiAlias($dst, true);
}
imagecopyresampled($dst, $res, 0, 0, 0, 0, $dst_w, $dst_h, Image::width($res), Image::height($res));

James,

Thank you. I already have seen image type in class.image.php but was aware that would change all images, even those which require transparency.

I'm certainly looking for flexibility here so while this solution actually might work in 99% of cases it isn't exactly that.

Nonetheless, it's highly appreciated Sir :)

Is anyone still having issues with transparent pngs?

Recently I updated from Symphony 2.1.2 and JIT 1.0.9 to Symphony 2.2.3 and JIT 1.1.3.

After that I upgrade, I started getting all these artifacts on the transparent PNGs.

I've attached the JIT image and the original image. (the images are a browser screenshots so you can see how the original image looks and the way the JIT image looks.)

NOTE: As you can see I'm using the basic resize settings. Here are my settings...

http://domain.com/image/1/150/0/0/original.png

I'm really stuck and need to find a solution. Anybody have any ideas?

Attachments:
original.png and JIT-image.png

I'm using same versionsof JIT and Symphony as you do Brian and have no trouble on 3 different websites/servers so far.

Have you tried re-uploading the image after the update?

@thelikeable, what version of PHP are you running on your server?

I am running PHP 5.3.8.

I have tried re-uploading the PNGs and they still come out that way. This only happened after I upgraded. It's really weird.

am i wrong in thinking that it looks like it's being converted to 8 bit rather than 24 bit?

It looks that way, although I don't get how. We got the code to work pretty slick for PNGs...

I think it may be something so do with the GD library in your PHP, although I can't find any specific reference...

Can you get the version of the GD library out of phpinfo() and I can see if it matches mine, which I recoded the transparent PNG functions to work on...

Here's my GD Library info...

GD Support enabled
GD Version bundled (2.0.34 compatible)
GIF Read Support enabled
GIF Create Support enabled
JPEG Support enabled
libJPEG Version 6b
PNG Support enabled
libPNG Version 1.2.42
WBMP Support enabled
XBM Support enabled

Now I'm really confused. That's the exact version I have too. Weird...

Oh, I think I found the problem. I was exporting from Fireworks as a 8-bit PNG. I exported the file from Fireworks as a 32-bit PNG, and it worked.

I guess I am just confused, because it worked fine with a 8-bit image before. But, as I've read online, it seems that 8-bit images don't play consistently nice with the GD library, I guess that's why it was working fine before the upgrade.

Thanks for your help!

at least you got it sorted.

Thanks John for your help!

Setting up Symphony at a client's server I run into JIT issues.

External images are linkes as such: http://sub.domain1.nl/image/2/120/120/5/1/sub.domain2.nl/workspace/media/images/image.jpg

This works fine on my test server (also with two domains) but on the client's host it gives me the following error: Error loading image . Check it exists and is readable. (notice the [space][dot] - the image file is not known).

The error message I get is 400 Bad Request and my main logfile returns:

2011/11/09 15:42:46 > Notice: Image class param dump - mode: 2, width: 120, height: 120, position: 5, background: 0, file: sub.domain2.nl/workspace/media/images/image.jpg, external: 1, raw input: 2/120/120/5/1/sub.domain2.nl/workspace/media/images/image.jpg

I can access the file on sub.domain2.nl directly and also through /image/ (with e.g. cropping) so JIT is working there.

By the way, GD seems fine too:

GD Support  enabled
GD Version  2.0 or higher
FreeType Support    enabled
FreeType Linkage    with freetype
FreeType Version    2.3.7
T1Lib Support   enabled
GIF Read Support    enabled
GIF Create Support  enabled
JPG Support enabled
PNG Support enabled
WBMP Support    enabled

I have added both * and sub.domain2.nl* to the JIT Trusted Sites preference on sub.domain1.nl and I have added * and sub.domain1.nl* to the JIT Trusted Sites preference on sub.domain2.nl

My guess is that, for some reason, JIT class.image.php:79 is_readable($image) returns false.

Probably because of permissions/ownership issues, as usual :(

UPDATE It's definitely something with write permissions. I've found out the JIT script cannot write to the tempnam() directory. When I changed line 60 in class.image.php from $dest = @tempnam(@sys_get_temp_dir(), 'IMAGE'); to $dest = @tempnam('/public/sites/sub.domain1.nl/manifest/tmp', 'IMAGE'); JIT worked!

Obviously this is not a future-proof solution, but I'm a bit closer: I need the PHP process to be able to write to sys_get_temp_dir() (which is /tmp)... It's probably the owner/group right?

UPDATE 2 The issue is actually that, on this shared host, sys_get_temp_dir() returns /tmp while PHP's temp. folder is actually set to /public/tmp (upload_tmp_dir). sys_get_temp_dir() does not respect upload_tmp_dir... I filed an issue and proposed a workaround in using $upload_tmp_dir first, if it's available.

I have never actually managed to get the crop to fit mode to work with this extension. Please could someone point out where I'm going wrong. The following works:

<img src="{$root}/image/1/0/50/{logo-image/@path}/{logo-image/filename}" alt="{title}" />

Yet this doesn't work:

<img src="{$root}/image/4/200/50/{logo-image/@path}/{logo-image/filename}" alt="{title}" />

Any comments or corrections would be very welcome. Thanks.

Symphony 2.2.3, JIT 1.12

And on that note, this site needs updating to represent that mode ;o)

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details