← Back to team overview

schooltool-developers team mailing list archive

Re: Photo instance

 

Hi,

  Wow, thanks for the fixes!

On 02/17/2012 01:23 AM, Douglas Cerna wrote:
--- On Thu, 2/16/12, Justas<justas@xxxxxx>  wrote:

<... fixes ...>

  A small nitpick.  In flourish/widgets.py

223   try:
224       image = Image.open(StringIO(data))
225       if image.format not in ('JPEG', 'PNG'):
226           raise IOError()
227   except (IOError,):

I would allow to upload any images that can be handled by Image. Since it raises IOError itself it would be a matter of removing lines 225-226.


   flourish.css:  "border-radius: 4px;".  Is
it worth adding -moz-border-radius?..  Maybe not
anymore.
I'd say yes. In fact, in my CSS TODO list I have a task to add vendor prefixes to some of our css3 rules: -moz-*, -o-*, -webkit-*, etc.
  You're the tzar! :D

   May be worth considering:

     - store all images as PNG.
I used JPEG.
  Okay.

     - convert all images to RGB or RGBA
mode.  Paletted (GIF) ->  convert to RGB ->  pretty
scaling with resampling and all.
All images are converted to RGB JPEG, even if they're PNGs with transparencies:

http://69.164.203.135:6662/persons/student199
  Nice.

  I noticed you always create a white-background image of 3:4 size.
Frankly, I miss rounded corners on "landscape" images like this http://69.164.203.135:6662/persons/student055

     - do not accept large data.  No 1GB image
transforms to thumbnails killing the server.
I limited the upload size to 10 MB, and put the check before processing anything.
  Thanks.

     - do not accept large images.  No
10000x10000 px image transforms - it's a photo, not a map of
Washington D.C.
Maybe the upload size is enough?

Things to consider (because some deployments may care about running out of RAM):

  10000x10000 empty white-filled png.
  file size ~= 300K
  python Image eats ~300 Mb of RAM to make a thumbnail, somewhat slow.

  10000x10000 empty white-filled jpeg
  file size ~= 500K
  python Image builds thumbnail fast, eats <1 Mb RAM.

  Now, on to the real life users mishandling their (graphical) software:

10000x75000 jpeg scaled (cubic interpolation) from thumbnail (taken from http://69.164.203.135:6662/persons/student399 )
  file size ~= 1.2MB
  building thumbnail again - fast, little RAM eaten.

10000x75000 png scaled (*no* interpolation) from thumbnail (taken from http://69.164.203.135:6662/persons/student199 )
  file size ~= 260K
  building thumbnail eats ~280 Mb of RAM, somewhat slow.

  Then again, many digital cameras do take high resolution pictures.

     - save image.copy() (after the thumbnail
transform) to keep only raster data.  Do we really need
app headers like image comments, GPS coordinates and other
waste?
Didn't implement this. Version 2 of the feature? ;)

  OK :)

     - scale images up, if they're smaller than
desired size?
Didn't scale them up, just centered them in a 99x132 "canvas":

http://69.164.203.135:6662/persons/student299

  Probably it's better this way.

Thanks Justas! When you're OK with these changes I'll merge my branch.

Now I need your help with another thing:

I tried to insert a photo in a PDF. Just for testing, I tried to modify the default report template inserting an image directive with its file attribute pointing to the photo url.

The problem is that z3c.rml.attr.File.fromUnicode uses urllib.urlopen to retrieve the resource, which produces a Forbidden page, since the request doesn't have session info :( You end up with an IOError, because PIL.Image tries to open the HTML.

One way to solve this is to point to actual file instead of server URL. urllib.urlopen can open '/home/justas/some_image.png' for example.

Is there a way to modify z3c.rml behavior when processing<image ...>  directives?

  I'm gonna go with "yes, if need be" :)

Cheers,
Justas



Follow ups

References