Closed cviebrock closed 10 years ago
It's missing in the docs since it's not well tested enough, but there's a convert filter (also see issue #9) that does exactly that.
JitImage::source( $source )->fit($w,$h)->filter('conv', ['f' => 'jpg']);
Finally got around to testing this. It looks like you need to do the filter before any resizing or it throws an exception. So, this worked in my case with a PNG source file.
JitImage::source( $url )->filter('conv', ['f'=>'jpg'])->cropAndResize($w,$h,5);
The resulting file is, indeed, a JPG image, but the cache still stores it with a .png extension.
hm, that's strange.
Hi, just had a look at the code, You're right, but that's actually part of the api. The resizing/cropping methods don't implement a fluent api as they return the processed image path. So calling the filter before is fine, as filters are not directly called but being attached at the end.
There's actually an example in the README :) https://github.com/iwyg/jitimage#the-facade-class. Maybe I should mention this explicitly.
Fair enough ... but any idea why my converted-to-JPG images are being saved with the original file extension still (in my case, .PNG)?
it should save the images with the correct file suffix. What driver do you use?
I'm using the "imagick" driver. Here's my code:
$url = 'file://' . public_path('img').'/default-pet.png';
$src = JitImage::source( $url )->filter('conv', ['f'=>'jpg'])->cropAndResize(100,100,5);
dd($src);
This returns:
http://example.dev/jit/storage/6e383466/jit_3706889de85e00e7.png
And if I load that image in a browser, I can see it's sent with an "image/jpeg" mime type (and by saving and inspecting the file source, I can confirm it is a JPG).
yes, again you're right. It's due to the way the cached names are being generated. Must figure ouf if there's a way to comprehend that
I found something like a solution, but I'm not happy with it. It would require the resolver to know about the properties of a filter (the Convert Filter) and this is quite ugly.
I mean, this is just a cosmetic issue, right? Would it help to omit the file prefix of the cached image?
In my particular case, the file prefix isn't super important. So omitting it would be fine (but I'd make that a config option, just incase it is important to others).
Now, I've had a hard time following the logic in the code (my issue, not yours!). But what about creating a "wrapper" function within the resolver that did this?
JitImage::source($url)->makeJPG()->cropAndResize(100,100,5);
Internally, the makeJPG()
method would call the Convert filter, but then set a flag internally to note that output should be a JPG. Would that help, since then you don't need to peer into the filters?
a makeJPG()
wrapper is in deed no problem because it'd be just shorthand for calling the convert filter. I've just set up a solution that'd output the correct file extension without effecting the cache. In fact, it's just a cosmetic operation: the resolver strips out any file extension from a cached url and the JitmImage
class would just add the real extension to the resolved cache path.
[Update]
While I was writing this, I updated the development branch, so basically the wrapper methods are toJpeg
, toPng
, toGif
$jit->source($file)->toJpeg()->get();
$jit->source($file)->toPng()->get();
$jit->source($file)->toGif()->get();
First, awesome work! This will probably save me from having to rewrite my L3 Thumbnailable package for L4. :)
It would be nice to be able to define the type of image (JPEG, GIF, PNG) instead of using whatever the source image is.
A configuration setting for this would be nice, but even better would be methods, so you could do:
and use them in recipes too, like maybe: