I want to propose a potentially controversial move. I’d love to remove the ImageField from Django. Maybe Django isn’t a great home for it.
We have deprecated other fields in the past, like CIText, and in many regards I believe this to be the better candidate. Mainly because on its own it’s always insufficient. Furthermore, I don’t believe it’s a good base for most sophisticated solutions to work off.
Why?
Mainly it’s a hard dependency on Pillow. Any project that derives from the image field has to use Pillow, because Django doesn’t work without it.
I am a great fan and donor of Pillow, but it’s not always the best choice for all applications. ffmpeg and ImageMagick are far superior at some tasks, and the former has great Python bindings too.
All 3rd-party packages can backport the current version or choose to abandon it.
Now, I’d especially love to explore the perspective of new Django adopters.
I think that’s a sensible alternative. However, I was looking at this from a maintainer’s perspective. Adding different backends adds more complexity for us to maintain. All that while the ImageField barely provides any benefit over the excellent FileField.
I’d be curious to know if anyone uses the ImageField without any 3rd party extension.
As for me, I think that having a built-in and simple ImageField in Django is really nice for simpler use case where you just have to store an image somewhere without any further functionalities.
Nobody is forced to use it, so I’d prefer that we explain something like that in the docs instead of removing the functionality and forcing anyone to use one more dependency.
Some story for a richer way forwards — the sensible alternative — sounds better. (A short overview of options in the ecosystem as a Django blog post, and then becoming a section on the Ecosystem page, would be a starting point, even if a code solution were further away.)
If people use it, let’s definitely keep it and improve it! I just didn’t mean to bother the community with suggestions for updates if nobody cares.
It looks like people care, wonderful! And I also believe image displaying images should be a core capability of a web framework for people with deadlines.
As a maintainer of django-imagekit to give my two cents. Even if 3th party libraries are used to provide custom ImageField (like django-imagekit), most of them extend Django’s ImageField (not only django-imagekit). This way all of them have common API.
Also when we speak about ImageField for which one we are speaking about - the model field or the form field? The model field does not have direct dependency with Pillow. It’s the ImageFile from the django’s files API which depends on Pillow. And the only thing for which it depends on it, is to get the image dimentions (width and height) with this function https://github.com/django/django/blob/stable/6.0.x/django/core/files/images.py#L35-L89
The form field on the other hand has direct dependency in one method used for validaton (if it is an image and what is the exact content type of the image) https://github.com/django/django/blob/stable/6.0.x/django/forms/fields.py#L720-L761
The suggestion given by @Arfey to have some form of backends is a great idea. Only two functions need to be in the backend (at least on first glance). One for getting the dimentions and one that returns the content type or raises ValidationError if it’s not an image.
This way if we have proper API for backends someone may decide to create backend which uses different library than Pillow, or even create backend that uses multiple libraries to have broader support for different file formats.
. DB, cache, storage, email, and sessions all follow the same shape.
