The method self.get_photo_miniature will work like get_photo_url, but it receives the limits of the image miniature, this method check if there is a file called some/path/some/where/photo_200x200.jpg (supposing the image filename is photo.jpg). If this file exists, returns the proper url to it, if not, it resizes the image and store on this file to then return the miniature url.
I need PIL to this work, but it works a pretty way. The above is working for me, but the custom method get_photo_miniature is defined on my model. I want to know if this is a useful feature, then I can dig up where to put this to make it generic.
Now that I done, I think I can do it another way, maybe using filters. As images generally goes in templates, I can do something like:
I think you catch the idea. What do you think? I sent a post about the problem of the filename being unique, I don't bother about this anymore, I see that if I put 2 files with same name, the files start to append a _ on the filename. But I still think the upload_to keyword could receive id.
Would you consider adding a thumbnail capability to Django? I know there are contributions out there that do it and the dependency on PIL might be a negative but I believe this is a very common use case. How many apps have an image field and don't use some sort of thumbnail? I bet very few.
Having a standard integrated in Django would be a big plus IMHO.
On 4/18/07, chris.moff...@gmail.com <chris.moff...@gmail.com> wrote:
> Would you consider adding a thumbnail capability to Django? I know > there are contributions out there that do it and the dependency on PIL > might be a negative but I believe this is a very common use case. How > many apps have an image field and don't use some sort of thumbnail? I > bet very few.
I'd be +1 on adding something as a contrib app. I've got some code we use at work, but it'll likely be some time before I'm able to generalize it enough for public consumption, so I'd be thrilled to see an effort by a few committed community members...
> I'd be +1 on adding something as a contrib app. I've got some code we > use at work, but it'll likely be some time before I'm able to > generalize it enough for public consumption, so I'd be thrilled to see > an effort by a few committed community members...
I used filters to implement this task, did you like the filter approach or do you think to have a method like object.get_image_thumbnail on the model is better? I must confess that use filter was easier to implement and it's easier to use too, I don't realize how to specify the limits of the image once I can't send parameters to the get_image_thumbnail method:
Now the questions (not about usage but about directioning :P):
1) What could be the name of the contrib package? Could it be in webdesign? 2) What is the better approach? Do a filter or a custom method on the model? 3) Should I create a ticket?
On Wed, Apr 18, 2007 at 08:28:00PM -0500, Jacob Kaplan-Moss <jacob.kaplanm...@gmail.com> wrote:
> On 4/18/07, chris.moff...@gmail.com <chris.moff...@gmail.com> wrote: > > Would you consider adding a thumbnail capability to Django? I know > > there are contributions out there that do it and the dependency on PIL > > might be a negative but I believe this is a very common use case. How > > many apps have an image field and don't use some sort of thumbnail? I > > bet very few.
> I'd be +1 on adding something as a contrib app. I've got some code we > use at work, but it'll likely be some time before I'm able to > generalize it enough for public consumption, so I'd be thrilled to see > an effort by a few committed community members...
I've got a chunk of code that's reasonably generic but needs some tidying up and decoupling... it's just a template tag... can be found:
This is a really great patch. I read the patch but have not attempted to use yet. Here are a couple of thoughts: - I think the patch file itself may be a little messed up. I see that several of the files are repeated. I could just be reading it wrong. - Big positive in that you documented it so well! - I like the fact that it's simple to create your own thumbnail classes if necessary. - Squash, crop and thumbnail are all very useful and I think it's great to have all these available. - This syntax looks just fine: <img src="{{ object.imagefield|thumbnail:"150x100" }}" />
However, this feels a little bit clunky: {% with object.imagefield|thumbnail:"150x100" as thumb %} <img src="{{ thumb.url }}" width="{{ thumb.thumbnail.size.0 }}" height="{{ thumb.size.1 }}" /> {% endwith %}
What if we had a shortcut like this: {{ object.imagefield|thumbnail_full_tag:"150X100" }}
Which would generate: <img src="source/file" width="150" height="100" />
- Also, one thing that is nice in Nesh's version is that it is easy to cache thumbnails in memory. I think this would be a nice & fairly simple thing to add.
Once again, really nice work. I look forward to seeing this in Django. I think it would be really really useful.
<chris.moff...@gmail.com> wrote: > This is a really great patch. I read the patch but have not attempted > to use yet. Here are a couple of thoughts: > - I think the patch file itself may be a little messed up. I see that > several of the files are repeated. I could just be reading it wrong.
Probably is messed up. I use tortoiseSVN and have noticed that it seems to mess up added files like that.
> - Big positive in that you documented it so well!
This is usually the way to a submitter's heart. ;)
> - I like the fact that it's simple to create your own thumbnail > classes if necessary. > - Squash, crop and thumbnail are all very useful and I think it's > great to have all these available.
I made crop recently for another project - squash isn't quite so nice but people may want it ;)
> - This syntax looks just fine: > <img src="{{ object.imagefield|thumbnail:"150x100" }}" />
> However, this feels a little bit clunky: > {% with object.imagefield|thumbnail:"150x100" as thumb %} > <img src="{{ thumb.url }}" width="{{ thumb.thumbnail.size.0 }}" > height="{{ thumb.size.1 }}" /> > {% endwith %}
> What if we had a shortcut like this: > {{ object.imagefield|thumbnail_full_tag:"150X100" }}
I felt a bit hesitant to even add that to documentation - it was more to show you can access the attributes of the thumbnail object (it's probably superfluous). Perhaps it would be better just provide an thumbnail_tag filter to handle it. I'd suggest a separate tag to handle it: {{ object.imagefield|thumbnail_crop:"150X100"|thumbnail_tag }}
> - Also, one thing that is nice in Nesh's version is that it is easy to > cache thumbnails in memory. I think this would be a nice & fairly > simple thing to add.
I thought about this, started implementing it and then scrapped the idea. IMO this is getting in to serving of static files, which historically Django has tried to steer very clear of. It wouldn't be difficult to do if it was deemed important enough.
> Once again, really nice work. I look forward to seeing this in > Django. I think it would be really really useful.
Thanks for the feedback, greatly appreciated. Anyone else (especially real testing)?