Zend and images

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend and images

Oscar Fanelli
Hi guys, I want to discuss with you about a big question: the images.
Actually I need to store some images and eventually do some actions to them (resizing, cropping, etc…)

So, my solution is: using Gaufrette (https://github.com/KnpLabs/Gaufrette) to store in the fs, link the gaufrette id of the image to an id in the database and then show the images with an ImageController.
(this is my idea, I'd be really happy to hear how you have resolved the issue).

Second problem: resizing, cropping
I have 2 ideas: 
- store the resized image in the fs permanently
or
- process the resize and store in the cache… but, what cache? Zend Cache? if yes, Zen Cache with which adapter (apc, fs)?

What solution you suggest?



Thanks all for the answers

---


Oscar Fanelli
Fondatore Gamempire.it
Email secondaria: [hidden email]
Skype: gamempire
Tel: 3388696167

Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Jurian Sluiman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Marc Bennewitz (private)
In reply to this post by Oscar Fanelli
> Hi guys, I want to discuss with you about a big question: the images.
> Actually I need to store some images and eventually do some actions to them
> (resizing, cropping, etc?)
>
> So, my solution is: using Gaufrette (https://github.com/KnpLabs/Gaufrette)
> to store in the fs, link the gaufrette id of the image to an id in the
> database and then show the images with an ImageController.
> (this is my idea, I'd be really happy to hear how you have resolved the
> issue).
>
> Second problem: resizing, cropping
> I have 2 ideas:
> - store the resized image in the fs permanently
> or
> - process the resize and store in the cache? but, what cache? Zend Cache? if
> yes, Zen Cache with which adapter (apc, fs)?
>
> What solution you suggest?

Hi Oscar,

I would prefer you using Zend\Cache\Pattern\Captcha if images of an id doesn't change.
I'm using fixed file URLs with modify information on query part so the images gets modified will written to fs and on next requests the response will be done by httpd only.

My URLs looks like this:
http(s)://example.com/img/<imgId>/<imgModifyInfoHash>.<imgOutputFormat>?<imgModifyInfoBase64>

Greetings
Marc

>
>
>
> Thanks all for the answers
>
> ---
>
>
> Oscar Fanelli
> Fondatore Gamempire.it
> Email: [hidden email]
> Email secondaria: [hidden email]
> Skype: gamempire
> Tel: 3388696167
>
>

MfG

Marc Bennewitz
Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Oscar Fanelli
In reply to this post by Jurian Sluiman
Jurians: ok for the keys, very useful to prevent attacks, however you give me another idea: we can use the constraints in the routes definition :)
Besides, you suggest to use a permanently resized image on the filesystem. And what about Zend\Cache?

Marc: can you provide me an example? I don't really understand what you did. Thanks



Il giorno 24/ago/2012, alle ore 00:34, Jurian Sluiman <[hidden email]> ha scritto:

2012/8/24 Oscar Fanelli <[hidden email]>
Hi guys, I want to discuss with you about a big question: the images.
Actually I need to store some images and eventually do some actions to them (resizing, cropping, etc…)

So, my solution is: using Gaufrette (https://github.com/KnpLabs/Gaufrette) to store in the fs, link the gaufrette id of the image to an id in the database and then show the images with an ImageController.
(this is my idea, I'd be really happy to hear how you have resolved the issue).

Second problem: resizing, cropping
I have 2 ideas: 
- store the resized image in the fs permanently
or
- process the resize and store in the cache… but, what cache? Zend Cache? if yes, Zen Cache with which adapter (apc, fs)?

What solution you suggest?

We have struggled with the exact same issue. We came up with a framework-agnostic solution with a FS "cache". I say "cache" because with Apache rewrite rules we have directly access to the file.

Our solution:
  1. Access an original filename with the canonical uri (http://my-domain.com/assets/my-image.png)
  2. Create so-called variations on an image based on a key: /assets/my-image.small.png
  3. The keys are used to specify the image characteristics (eg. width = 200px) without the vulnerability to be open for DOS attacks if you specify for example the width as a query parameter (they might request the image with width 200, 201, 202, 203 and so on)
  4. Store all variations inside a folder, so if the original gets updated, you can remove the folder to clear the complete "cache"
  5. All images are passed through the browsers without php involved when the image variation is already processed
I blogged about the how-to here: http://juriansluiman.nl/en/article/112/media-asset-management-resize-images. It might look a little complex but it is quite flexible and powerful at the same time. Happy to hear what you're thinking about this.
--
Jurian Sluiman

Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Jurian Sluiman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Oscar Fanelli-2
Mmm ok, so you do it manually… but, Zend Cache with filesystem adapter would not be better?

Il giorno 24/ago/2012, alle ore 08:27, Jurian Sluiman <[hidden email]> ha scritto:

2012/8/24 Oscar Fanelli <[hidden email]>
Jurians: ok for the keys, very useful to prevent attacks, however you give me another idea: we can use the constraints in the routes definition :)

Certainly true. It might help to make things a bit easier in the rewrite rules. However, you need to bootstrap your whole application before you can perform any resize action, so I am not sure it is worth it. With this small script, we can just copy/paste it over from ZF1 to our ZF2 base (or if we want to use Symfony 2, that's fine too).

Besides, you suggest to use a permanently resized image on the filesystem. And what about Zend\Cache?

We just want to keep things in the file system so if the resized version exists, no php processing is involved anymore to pass through the image. It is faster and saves memory. 
--
Jurian Sluiman

Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Jurian Sluiman
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

jeremiah
This post has NOT been accepted by the mailing list yet.
In reply to this post by Oscar Fanelli
Not ZF2specific, but work pretty nice https://github.com/lencioni/SLIR

Jeremiah
Reply | Threaded
Open this post in threaded view
|

Re: Zend and images

Tomáš Fejfar
In reply to this post by Jurian Sluiman
IMO Zend_Cache is a right tool for the job. You can create an API for that, and your own adapter, that will generate the files. 

sth. like:

$cachedFilename = $cache->getFilename($filename, 'small');
if (!$cache->load($cachedFilename)) { //this will be practically generate a filename and try file_exists()
    $cache->save($cachedFilename, 'small');
    //create file if not and return it's name&path
    //tags are used for various sizes
}

You can also create a view helper that will generate the proper URL for the image and include the caching code in there. That way you only have the images, that have been requested/used. And not all. 

On Fri, Aug 24, 2012 at 4:51 PM, Jurian Sluiman <[hidden email]> wrote:
2012/8/24 Oscar Fanelli <[hidden email]>
Mmm ok, so you do it manually… but, Zend Cache with filesystem adapter would not be better?

It is "better" if you want to use php to access you cache files. I don't, because my cache files are as simple as requesting a normal resource file via your webserver (say, a mystyle.css). That means it is fast and uses not much memory. If you let php handle all your thumbnails and so on, they load much slower than normal.

In this case, I don't think you need to use a framework for every request. Something like this is easier to perform outside ZF2 since it is then portable, smaller, easier to understand and faster.
--
Jurian Sluiman