Symphony.

I am not sure if I understand your desire here. According to your article, EXIF orientation meta data don't really work on the web, so why should we add it?

Cropping or resizing an image via JIT removes all EXIF data from the resized image (not from the original file). Since browsers don't really handle EXIF orientation in a consistent way, just adding it back to the resized images would only solve the problem for browsers that get it right in the first place.

Instead, I handle the orientation on the server side right before applying filters and make sure they get rotated and flipped so you won't end up with resized or cropped images mirrored and/or upside down, no matter if the browser handles EXIF orientation correctly or not.

Example:

You make a picture with your iPhone while "holding it wrong" (landscape, upside down, etc.).

The picture is stored the way the iPhone sees it, but with EXIF orientation data attached.

When you look at the picture on other devices, it may or may not look correct depending on whether the software you're using to display the picture handles the EXIF orientation data correctly.

• Original Picture looks good on a Mac because Preview handles EXIF orientation correctly.
• Original Picture might be upside down on Windows.
• Original Picture might be upside down in some browsers.
• Resized Picture is upside down in all browsers because JIT removes EXIF orientation entirely.

Now I understand.

One might argue, however, that "pictures for web" should not include any EXIF data. If you use Photoshop's "Save for Web" feature, for example, those orientation meta data will not be included.

On the other hand, I see that people might simply upload iPhone pictures to their website and wonder what went wrong.

Interesting! I'd like to know what others think.

(Anyway, since your code changes and additions are not small, it should be tested before pulling it.)

On the other hand, I see that people might simply upload iPhone pictures to their website and wonder what went wrong.

Exactly. And it's not only the iPhone, other cameras might handle it quite similar. I wonder why nobody('s clients) complained about it so far.

Anyway, since your code changes and additions are not small, [...]

They aren't really that big, just looks like it on GitHub. I basically just added

• the EXIF orientation to the getMeta...-function in the image class
• a switch for correcting the orientation (flipping and rotating) before applying crop and resize-filters
• two new filters for flipping and rotating

[...] it should be tested before pulling it.

Sure.

How can I extend JIT in order to add a mode for black and white (B&W) conversion?

I need different favicons, made as favicon ico, because of this (..) ie. these favicons should be cropped and reized images. there are working fine even as jpeg's on firerfox/opera/safari so far.

to get them run on ie the spezial image format (ico) is needed. icos can be made bei Imagemagick oder by phpthum.ico.php ( http://api.zikula.de/filesource/fsource_Zikula%201.0.1modulesThumbnailincludesphpThumbphpthumb.ico.php.html) on the fly.

so when I'm patching jit to create ohter filtypes than the original one, it would be nessesary to have a new argument order(because one arg must be the final filetype).

I prefer: images/filetype/mode/width/heigth/position/background/external/path

if you choose longest.

thanks for suggests.

I've made a new filter at last, corresponding to mode 5 -> biulding an ico. the saved ico are printed quite nice - including spezial header data, the fresh generated ones can't be printed on the fly, because of an text/html header generated somewhere: I cant find.

I've put it on github as a draft, may somebody knows to reloves this or is interested in such stuff:

https://github.com/strlcp/jit_image_manipulation

Hi All, I am facing an issue with JIT when I moved to a new server. Now I am getting an error response (500 internal server error) for all images. Images directly from uploads are loading fine, only JIT manipulated images are having issues. Here are more details:

Symphony CMS version - 2.3.3 Server - LAMP on Ubuntu 12.04 mod_rewite is enabled (the entire site seems to work fine except for images) php version - 5.4

I did some searching and found that on 5.4 ob_clean() might be giving a problem, I have tried commenting that too but that didn't solve my issue. Also the manifest cache is empty.

Can Anyone help ?

thanks.

Edit: Note - everything works fine on my localhost (WAMP)

Ok, I solved it, After making error reporting on I realized that GD was not installed. installing php5-gd solved the issue.

Can't get JIT to work.

• Extensions's enabled
• Handle set to: / image / 1 / w / h / e / path - what's the point of this, if the image can be accessed via URL anyway? Maybe I'm not getting the concepts straight
• Example URL I'm using to test it manually: /image/1/200/0/5/workspace/uploads/7be593a54b5df506bb9f29a03d6e5174.jpg
• Result: "Bad Request"
• The image is indeed accessible, the path without "/image..." works fine, but loads the raw image, of course

Any advice on this?

Thanks! M

Edit: I also tried {$root}, since that makes more sense, however, I got the same result as above.

You have to remove the workspace from your paths.

Hey, Nils. Thank you for replying.

No, unfortunately that URL is not working either.

The URL formed is http://localhost:8888/symphony/image/1/200/0/5/uploads/7be593a54b5df506bb9f29a03d6e5174.jpg

What's the idea of having a JIT "recipe" creation section in the Preferences panel?

I created a recipe and set the handle to / image / 1 / w / h / e / path, is that ok or should I replace the w, h, e, with the real numbers?

Thanks, M

I just realized that I had to go to the page and select JIT from the data sources. For those who are having issues trying to implement this:

1. Enable JIT extension
2. Go to preferences, create a new recipe. Define a handle (it can be any name, 'my-handle' would work)
3. Go to your page, select the JIT data source (optional)
4. Check out your pages XML with ?debug at the end of the URL (optional)
5. Make sure the JIT node is in the XML (optional)
6. Test your image with the following URL: {$root}/image/my-handle/path-to-my-image (the path to your image is formed with whichever the image folder is, for example, mine is at uploads/image.jpg) as the src url for the image

That's it. Your image will appear cropped, resized or whatever you select on the preferences section of the recipe.

Cheers, M

Glad you got it working somehow. Just two clear this up a bit: JIT offers two different ways to generate images, one using a predefined, dynamic URL structure (/image/recipe/w/h/e/path) and the other using custom, named recipes. You should not have to define the dynamic recipes in the backend, but you have to make sure that they are not disabled in the preferences (see Disable dynamic URLs and use named recipes only).

I don't remember ever having to add the JIT data source to pages...

/image/1/200/0/5/ and / image / 1 / w / h / e / dont fit. I think you mixed ist with onother jit mode (cropping)

DavidOliver, you're right. You don't need to get JIT into the data sources of your page. But seeing it there helped me out to realize that I could use the handle name in the URL.

The real problem is that e can only be 0 or 1 for whether or not the URL is external.

have you tried this method to manipulate images. i think they are working well for me. you can do all the processing work, such as cropping, flipping, rotating and resizing images.

I have a few images from many uploaded that are not reachable through a JIT recipe, returning a HTTP 500 Internal server error upon their HTTP requesting.

I've learned that they all differs from the others in their file size of cca 4MB, whereas others have < 1,5MB, and resizing those images to a smaller size before upload solved this error.

Is this error caused by some memory restraints on the server? Or is it a limitation of JIT? And also, can it be treated somehow safely?