Symphony.

Forget that, I had a width and height-attribute on my image tag :-P

Still, shouldn't mode 4 also give the option to provide a background-color like mode 3 does?

Does JIT retain image EXIF/IPTC-information from the sourcefile?

Very doubtful. EXIF/IPTC info has it's own set of functions in PHP, for output onto a web-page, these will probably not be used in an effort to save size.

JIT creates an entirely new image that is stored in the cache. You could check an image in the cache to see, but I seriously doubt it.

@designermonkey looks like you’re right, thanks! should have tought about simply checking the cache msyself m(

What I think I’d need would be something like the already existing EXIF/IPTC-extension that works in reverse (e. g. writeing EXIF into files) and somehow hooks itself into JIT. But this specific project is still very conceptual, so I will have a lot of time thinking about how to do that, or if it’s even needed.

Still, thanks! :·)

I remember @alpacaaa making that for me :o)

I really think that it would be useful to have an extension that could read IPTC into Symphony fields, and vice-versa.

How to go about that easily is another matter. Have a think and I'll give you a hand if you decide to do it.

You can still retrieve data from the original image, even if you're showing the resized one, unless I'm missing something huge :D

@alpacaaa ahh, good point! Though it would be nice to have proper metadata in the downsized images too, for copyright reasons.

I would like to be able to use the value of a page param for Width in a JIT Recipe.

From what I can tell, setting Width to data/params/my-page-param does not work – it returns a broken image. Is this not possible, or am I just using the wrong syntax?

Recipes are static. If you need dynamic urls you should tick the box in preferences to enable "standard" URLs.

@klaftertief is there a branch that includes watermarking that’s working in Symphony 2.3?

Not that I know of. Have't updated my branch, but maybe someone else has something.

I might (a big might) work on something JITy soonish that uses Imagick to be able to preserve image metadata and color profiles (GD throws those away). Could implement a watermarking feature as well then.

Have you seen https://github.com/rowan-lewis/image-jit? Haven't tried it myself and I think it's not integrated with Symphony at all, but it might be a good starting point.

Ok, interesting, thanks for the info!

I'm trying to receive an external image provided by Twitter: therefore I need to load the medium URL from Twitter which is specified with a special syntax:

http://p.twimg.com/1234.jpg:medium

Symphony returns a 404 error when trying to resize the image using JIT, e. g. http://example.com/image/584/0/1/p.twimg.com/1234.jpg:medium. One problem seems to be the .htaccess redirect expression which expects a file type at the end of the image link. But if I change the rule, the next problem occurs:

Unsupported image type. Supported types: GIF, JPEG and PNG

Has anyone resized Twitter images successfully and can give me a clue how to do this?

Why don't you grab the normal image? I am doing this with profile images, e.g.:

A super image, thumbnailed

Is there an URL scheme I'm not aware of to fetch orginal sources of images attached to tweets?

Hmmm , sorry, I am am not sure. I assumed it might be as simple as with profile pictures to request the original file. But I can't find it in the API documentation...

Twitter images are not cacheable, you must user their service which i believe limits you you to the 4 predetermined sizes thumb, small, medium, large (Might be able to find more from this article I came across https://dev.twitter.com/docs/tweet-entities)

Can i use wildcards for subdomains? It seems that JIT doesn't support wildcards at the beginning like *.ytimg.com*

If i use ytimg.com* it will not work for its subdomains...

For now i'm using:

i1.ytimg.com*
i2.ytimg.com*
i3.ytimg.com*
youtube.com*
b.vimeocdn.com*

How do you guys allow youtube and vimeo image preview domains?

Added correct EXIF-orientation handling to the extension. Would be nice if a few people could test my fork and provide feedback if something doesn't work as expected before it gets pulled in.

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?