Ticket #693 (closed defect: fixed)

Opened 14 years ago

Last modified 9 years ago

Image gallery produces thumbnails without actually changing size of produced images

Reported by: rspivak Owned by: gracinet
Priority: P1 Milestone: CPS 3.5.2
Component: CPSDocument Version: 3.3.3
Severity: major Keywords: image thumbnail


Generated 'thumbnails' are produced with <img /> tag with given height and width, but that doesn't influence actual size of produced images that leads to long loading of gallery in case there are lots of big images.

This can be solved by on-fly thumbnails generation with PIL(falling back to original image size in case PIL is absent). I have created branch for this purpose: rspivak-imagegallery-branch.

Some logic will be added to new Image class. The trickiest part seems to be migration of class names in ZODB, as currently objects with portal type 'Image' are instances of Products.CPSDocument.CPSDocument.CPSDocument class.

Change History

comment:1 Changed 14 years ago by rspivak

  • Milestone changed from CPS 3.3.5 to CPS 3.3.6

comment:2 Changed 14 years ago by fguillaume

  • Milestone changed from CPS 3.3.6 to CPS 3.4.0

Ruslan, what's the status of this? You shouldn't keep branches too long.

comment:3 Changed 14 years ago by ogrisel

  • Owner changed from rspivak to ogrisel

I'll try to integrate it to trunk tomorrow as I need it for a customer project.

comment:4 Changed 14 years ago by ogrisel

I have a look at your branch but I don't really like it, sorry ;)

I would like to find a generic solution to generate thumbnails on the fly when PIL is available however, it would be better if we could do it for all image document, not only those in the image gallery. It would be nice to use it in the preview occuring in the folder listing template (source:CPSDefault/trunk/skins/cps_default/content_lib_info_detail.pt).

Furthermore, we need to make it RAM cacheable so as the thumbnail generation is not done at each view request.

I don't know if you should do that at document level (in your branch you create a Image class that derives from CPSDocument) or at some image widget level. I find the current image widget loosy since it does not keep the original file when resizing is allowed and thus resizing can only be done at upload time. The photo widget is a bit better but it only has a single persistent thumbnail which is not enough.

Maybe we sould derive the OFS.Image.Image class to add a method getThumbnail(self, max_height, max_width, keep_ration=True) and use that class instead of OFS.Image in CPSSchemas. But remember, we need to make the thumnails generation RAM cacheable in some way.

comment:5 Changed 14 years ago by rspivak

It was highly tentative and i thought you already took over it to mercilessly refactor :)

Making thumbnails generation stuff generic(to be applicable as you mentioned also in folder listing, for example) and cacheable would be great, of course.

comment:6 Changed 14 years ago by ogrisel

I was wondering if there already exists such a PIL based generic Zope Product before reinventing the wheel. I did some googling but I could not find anything.

So the plan is to write a new Zope product (with no CPS/CMF dependency) to implement the PILImage class that derives from the OFS.Image.Image class and overrides it's default ZCacheable_* methods to take care of the thumbnails as well.

Furthermore, we need add a default RAMCacheManager somewhere in a default CPS instance and find a way to make CPS (maybe the image widget) update the associations automatically each time an image field is updated.

comment:8 Changed 14 years ago by lregebro

The EasyImage? product I did for EasyPublisher? years ago did thumbnail resizing with PIL. It's not particularily difficult, but still, there is code you can steal:  http://www.easypublisher.com/

comment:9 Changed 14 years ago by lregebro

I also think that instead of using caching (which just is problematic) it might be easier to just save the preview? Doing something in computeDependentFields, for example. But then you need a way to set the preview-size on the fild then, which maybe isn't the most logical place to put it. Or it can be done during the validation, in which case the preview-size can ge defined as properties on the ImageWidget?.

comment:10 Changed 14 years ago by jmorliaguet

Saving a preview in the ZODB is also called "caching" (persistent caching) which also requires a method for invalidating outdated previews and managing a collection of thumbnails of different sizes (some sort of garbage collector). RAM-caching makes garbage collection slightly easier.

The question is whether to do the 100% on-the-fly image conversions or to save the resized images in a cache.

comment:11 Changed 14 years ago by gracinet

Seen on boxless branch, but shouldn't make any difference: no resizing at all for thumbnails. In other words, it's broken.

comment:12 Changed 14 years ago by fguillaume


  • thumbnails should be computed when the image is uploaded
  • thumbnail size should be a parameter of the gallery

Has there been any progress on this front?

comment:13 Changed 14 years ago by ogrisel

I tend to prefer JMO's approach with RAM caching because there is no dataloss + it allows to change the thumbnail size afterward (a timeout base RAM cache will act as a natural garbage collector for useless thumnails).

What about having some kind of generic Zope3 based 'PILCachingThumbnailer' adapter in CPSUtil that could be used by the ImageGallery? and other documents/portlets/widgets?

comment:14 Changed 14 years ago by fguillaume

  • Milestone changed from CPS 3.4.0 to CPS 3.4.1

comment:15 Changed 14 years ago by ogrisel

Interesting layout sample: pure CSS imagegallery laying with zooming on thumnails.


comment:16 Changed 13 years ago by sfermigier

  • Milestone changed from CPS 3.4.1 to CPS 3.4.2

Can we implement a quick solution soon?

comment:17 Changed 13 years ago by sfermigier

  • Milestone changed from CPS 3.4.2 to CPS 3.4.3

comment:18 Changed 10 years ago by gracinet

  • Milestone changed from CPS 3.5.0 to CPS 3.5.1

Need this soon. I've heard of a WSGI middleware that does the resisizing, caching on the fly, btw

comment:19 Changed 9 years ago by gracinet

  • Keywords image thumnail added
  • Priority changed from P3 to P1

Like all true changes after rc1, it will have to wait a bit. On the short list of things to do right after 3.5.1

comment:20 Changed 9 years ago by gracinet

  • Keywords thumbnail added; thumnail removed
  • Severity changed from normal to major
  • Milestone changed from CPS 3.5.1 to CPS 3.5.2

The actual handling of thumbnails will be done in #2204. Once that is done, this ticket will be about leveraging it.

comment:21 Changed 9 years ago by gracinet

  • Owner changed from ogrisel to gracinet
  • Status changed from new to assigned

comment:22 Changed 9 years ago by gracinet

Done and pushed in future-3.5.2 branch a few days ago

comment:23 Changed 9 years ago by Vaurien

Being able to set only one dimension (height or width) for the thumbnails would be convenient when a gallery consists of photos of different aspects/ratios (automatically keeping the original ratio).

comment:24 Changed 9 years ago by gracinet

Just seen the example CSS layout linked to by ogrisel, must consider implementing this.

comment:25 Changed 9 years ago by gracinet

Another minor issue: since the major use case for image galleries is to upload pictures almost straight from a digital camera, the default aspect ratio for thumbs should be 4:3 (128x96 is nice to my taste) instead of the current 1:1

comment:26 Changed 9 years ago by gracinet

  • Status changed from assigned to closed
  • Resolution set to fixed

This last issue being done, with an upgrade step, it's time to close

Note: See TracTickets for help on using tickets.