Make images even if the original image is small -- functions.py

[GoogleCodeExporter]

The function to create versions (non-cropped) of images only produce images
if the original image is big enough. These are lines 295-297 in the latest
functions.py:

            # ONLY MAKE NEW IMAGE VERSION OF ORIGINAL IMAGE IS BIGGER THAN
THE NEW VERSION
            # OTHERWISE FAIL SILENTLY
            if int(current_width) > int(new_size_width):

I think this should be an option. Something to activate in the settings.

---
What revision of the FileBrowser are you using?
Not sure. A SVN checkout from early october, I think. It should be the
latest available.

What version/revision of Django are you using?
1.0

Original issue reported on code.google.com by fversche...@gmail.com on 22 Nov 2008 at 9:46

[GoogleCodeExporter]

I don´t think this should be an option. enlarging images leads to really bad
image-quality. since the admin-interface is for "trusted editors", one should 
be able
to upload a big enough image.

Original comment by sehmaschine on 22 Nov 2008 at 12:09

• Changed state: WontFix

[GoogleCodeExporter]

The problem is sometimes you don't have a big enough image, like for instance 
you
need a 500x350 JPEG on the website but your best available source is 400x400. 
Not a
desirable situation, but it happens.

If you generate images bigger than the source:
- you get decent to awful quality, depending on the source (400 to 500 is ok for
JPEG, though not optimal, while 250 to 500 would be bad, and 100 to 500 just 
awful);
- it's harder to tell there's an image that's not big enough when viewing the 
site.

If you generate images only if there's a big enough source:
- you get good quality every time;
- you may end up with blank spaces where there should be an image, which makes 
it
easier to spot missing images but is not a great fallback...

There's no perfect solution. I think an option would be good, though.

If you stick with the WontFix (which is sensible, mind you, it's just not my 
prefered
design option), this behavior should be documented in
http://code.google.com/p/django-filebrowser/wiki/imagegenerator ;)

Original comment by fversche...@gmail.com on 25 Nov 2008 at 7:01

[GoogleCodeExporter]

there´s another option:
compare this
http://skip.at/film/11349/
with this
http://skip.at/film/6158/
and take a look at the images on the right hand side of the content-area.

though this is (also) not a perfect solution, you see that you can handle this 
on the
frontend ...

I will stick with the won´t fix and change the docs.
anyway, thanks a lot for the suggestion.

Original comment by sehmaschine on 26 Nov 2008 at 9:29

[GoogleCodeExporter]

True enough. But with the way FileBrowser works, if I call a specific image 
version
and it was not generated... well I get nothing at all. So I need to check 
whether the
image version exists (was it generated?), and since this information is not in a
database I have to check it using the os module of Python, which is ressource 
intensive.

So if you don't make the image bigger, you may want to copy the original (small)
image as a version, rather than outputing nothing (zero byte file).

Original comment by fversche...@gmail.com on 26 Nov 2008 at 11:23

[GoogleCodeExporter]

I see your point, but handling images is not done by the filebrowser but by 
your code
instead.

1. nothing stops you from saving image-data within your database. I´ve already 
been
thinking about putting this into the filebrowser, but needs are very different 
here,
so it´s hard to find a decent solution. saying that, this functionality will be
implemented someday ...

2. I don´t quite agree with the way you integrate images. if I have an article 
and I
like to have an overview-image for that article, I define a filebrowsefield and
select the right image-version (not the original image). so, it won´t happen 
that
there´s no image on the website (it only happens if I don´t define one).

if I need two different image-versions for that article (say you have two 
different
ways of showing that article on an overview.page), I am defining 2 
filebrowse-fields.

an example: http://skip.at/neuimkino/
the movie on the left hand side ("Der Mann, der niemals lebte") shows a bigger
overview-image than the movie on the right hand side ("Max Payne"). for this
behaviour, I am defining 2 filebrowse-fields (which is, 2 charfields). I am even
adding validation to each of the fields, so that only images with the right 
width can
be used.

that said, the main idea behind the image-generator is that you actually never 
save
the path to the original-image in your database. you´re using image-versions 
instead.

although you might not agree with this solution, this is the basic idea. if you 
think
this can be improved, please let me know ...

Original comment by sehmaschine on 26 Nov 2008 at 11:43