Ticket #2204 (closed feature: fixed)

Opened 9 years ago

Last modified 9 years ago

Image resizing system

Reported by: gracinet Owned by: gracinet
Priority: P1 Milestone: CPS 3.5.2
Component: CPSCore Version: unspecified
Severity: major Keywords: image thumbnail resizing


This is a follow up for #693. Actually, this is more general than just image galleries, and ends up being qualified as a new feature in CPSCore.

I'm speaking of resized images because it's more general than just thumbnails.

  • resized images are computed upon request, and not upon upload. Rationale: one cannot predict from the Image document what will be useful for other documents (Image Gallery) or custom logic. For instance, the size of thumbnails for Image Gallery is a choice of the Gallery itself. Further, we may need several resizings at once for one image (imagine a full resolution image is stored, a midsized version is used for display, and there's the thumb).
  • resized images will be ZODB persistent, and stored on the Image document object. That's because RAM is ok for thumbs only. Besides, for really big pictures, one does not want to recompute everything each time the server restarts. Invalidation is really easy.
  • access to resized images is made through a special traversal, akin to downloadFile, and that's in ProxyBase

Change History

comment:1 Changed 9 years ago by gracinet

Side note: the cache must have a max amount of resized images. Otherwise, it gets real easy for an attacker to make a CPS site crumble under its own weight (request 320x200, 321x200, 322x200 etc.)

comment:2 Changed 9 years ago by gracinet

Done and pushed in future-3.5.2 branch.

The number of sizes per document is limited to 10 by the traversal system. Last modification time of a resized version is compared to the original's, so that no outdated content can be served, independently from whatever invalidation code is done while modifying documents.

However, if there is an old resized image that never gets requested again, it will stay forever. This would be frequent in case of Image Gallery thumb size changes.

We could have either a housekeeping task cleaning those stale images or the usual event stuff. Since the frontend already takes care of the requested ones, the housekeeping approach is simple and effective enough.

comment:3 Changed 9 years ago by gracinet

The explicit bidimensional resizing works well. More thoughts for unidimensional specification (not implemented yet)… we should have three modes keeping the ratio aspect : width spec, height spec, and largest dimension height. The latter would be the one to use to accommodate the typical mix of portrait and landscape pictures that most people produce in one picture session for an event etc.

comment:4 Changed 9 years ago by gracinet

Meant "largest dimension spec", obviously

comment:5 Changed 9 years ago by gracinet

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

Just implemented the unidimensional size specifications.

Note: See TracTickets for help on using tickets.