让Django识别PIL JPEG支持

时间:2021-02-12 00:22:19

I am running Django 1.4 and PIL 1.1.7 in a virtualenv managed with pip. Whenever I upload a JPEG file via my admin interface, I get the following error: Upload a valid image. The file you uploaded was either not an image or a corrupted image.

我在使用pip管理的virtualenv中运行Django 1.4和PIL 1.1.7。每当我通过管理界面上传JPEG文件时,都会出现以下错误:上传有效图片。您上传的文件不是图像或损坏的图像。

As many Ubuntu users have reported, on installation, PIL erronously looked in /usr/lib/ for libjpeg, while its true location was in /usr/lib/i386-linux-gnu/. That's taken care of; I followed the answers in these posts:

正如许多Ubuntu用户报告的那样,在安装时,PIL错误地在/ usr / lib /中查找了libjpeg,而它的真实位置在/ usr / lib / i386-linux-gnu /中。这是照顾;我按照这些帖子中的答案:

Django ImageField "Upload a valid image. The file you uploaded was either not an image or a corrupted image."

Django ImageField“上传有效图像。您上传的文件不是图像或损坏的图像。”

Why can't I upload jpg files to my Django app via admin/?

为什么我不能通过admin /?将jpg文件上传到我的Django应用程序?

Now the final output of installation looks as follows:

现在安装的最终输出如下:


PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version       1.1.7
platform      linux2 2.7.3 (default, Apr 20 2012, 22:44:07)
              [GCC 4.6.3]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.

To check the build, run the selftest.py script.
changing mode of build/scripts-2.7/pilfile.py from 644 to 755
changing mode of build/scripts-2.7/pilfont.py from 644 to 755
changing mode of build/scripts-2.7/pilconvert.py from 644 to 755
changing mode of build/scripts-2.7/pilprint.py from 644 to 755
changing mode of build/scripts-2.7/pildriver.py from 644 to 755

changing mode of /usr/local/bin/pilfile.py to 755
changing mode of /usr/local/bin/pilfont.py to 755
changing mode of /usr/local/bin/pilconvert.py to 755
changing mode of /usr/local/bin/pilprint.py to 755
changing mode of /usr/local/bin/pildriver.py to 755
Successfully installed PIL

However, Django still doesn't allow me to upload anything but BMP files, which is not acceptable for this project. Unlike the user in the second link, I'm not using Apache, so my problem is probably not related. My suspicion is that Django is still using an old installation of PIL. The problem is that I don't know where it could be getting it from. The files in ~/.virtualenvs/project/local/lib/python2.7/site-packages seem up-to-date to me. Any ideas?

但是,Django仍然不允许我上传除BMP文件之外的任何内容,这对于这个项目是不可接受的。与第二个链接中的用户不同,我不使用Apache,所以我的问题可能与此无关。我怀疑Django仍在使用旧的PIL安装。问题是我不知道从哪里得到它。 〜/ .virtualenvs / project / local / lib / python2.7 / site-packages中的文件对我来说似乎是最新的。有任何想法吗?

EDIT 1: Also note that I have tried logging out and logging back in the admin, as well as installing pillow, as in this post: Uploading a JPEG image via Django displays error

编辑1:还要注意我已经尝试注销并重新登录管理员,以及安装枕头,如下文所述:通过Django上传JPEG图像显示错误

1 个解决方案

#1


2  

It turns out that this whole thing is my fault due to a misunderstanding of how pip actually works. By habit, I associate any and all installations with superuser privileges, which was not only not necessary in this case, but a recipe for confusion.

事实证明,由于对pip实际工作原理的误解,这一切都是我的错。根据习惯,我将任何和所有安装与超级用户权限相关联,这不仅在这种情况下是必需的,而且是混淆的一个秘诀。

The first time I installed PIL, I did not prefix it with sudo, but I did each time after. Thus, building from Meitham's advice, I checked to see where the import was coming from. It came from the correct place, but it did not have the extensions I desired, despite the post-installation output saying I did. Long story short, I removed the directory from my site-packages, then pip freeze continued to tell me I did not have PIL but sudo pip install told me I did.

我第一次安装PIL,我没有用sudo作为前缀,但我每次都做过。因此,根据Meitham的建议,我检查了进口的来源。它来自正确的地方,但它没有我想要的扩展,尽管安装后输出说我做了。长话短说,我从我的网站包中删除了目录,然后pip冻结继续告诉我我没有PIL但是sudo pip install告诉我我做了。

Lesson learned: virtualenv is based in the user's directory, on the user's privileges. Think twice before combining sudo and pip in the same command.

获得的经验教训:virtualenv基于用户的权限,位于用户的目录中。在同一命令中组合sudo和pip之前要三思而后行。

#1


2  

It turns out that this whole thing is my fault due to a misunderstanding of how pip actually works. By habit, I associate any and all installations with superuser privileges, which was not only not necessary in this case, but a recipe for confusion.

事实证明,由于对pip实际工作原理的误解,这一切都是我的错。根据习惯,我将任何和所有安装与超级用户权限相关联,这不仅在这种情况下是必需的,而且是混淆的一个秘诀。

The first time I installed PIL, I did not prefix it with sudo, but I did each time after. Thus, building from Meitham's advice, I checked to see where the import was coming from. It came from the correct place, but it did not have the extensions I desired, despite the post-installation output saying I did. Long story short, I removed the directory from my site-packages, then pip freeze continued to tell me I did not have PIL but sudo pip install told me I did.

我第一次安装PIL,我没有用sudo作为前缀,但我每次都做过。因此,根据Meitham的建议,我检查了进口的来源。它来自正确的地方,但它没有我想要的扩展,尽管安装后输出说我做了。长话短说,我从我的网站包中删除了目录,然后pip冻结继续告诉我我没有PIL但是sudo pip install告诉我我做了。

Lesson learned: virtualenv is based in the user's directory, on the user's privileges. Think twice before combining sudo and pip in the same command.

获得的经验教训:virtualenv基于用户的权限,位于用户的目录中。在同一命令中组合sudo和pip之前要三思而后行。