image in feeds.py

[matthewwithanm]

image in feeds.py

[rizumu]

I should note I am using django-cumulus with rackspace cloudfiles.

[bryanveloso]

@rizumu, would you mind trying with the latest master? There were some fixes related to writing to image files.

[rizumu]

@bryanveloso the problem persists on master. What stands out most is that the other thumbnails works fine from the template, just not in the feeds.py

[matthewwithanm]

Oh wow, github automatically closed this when I committed dd7ae5a. That's…interesting.

Anyway, I did some research and it seems like the issue is just one with PIL and giant JPEGs (yours is apparently 1000x1000). I couldn't duplicate it myself, but based on what I'm reading, I'm fairly confident that increasing MAXBLOCK will take care of it for you.

Please let us know if this fixes it so we can (properly) close this issue.

My fix is based on this but it's made me rethink our approach to MAXBLOCK in models.py. Right now we're just setting it to an arbitrary number (512^2) and providing a django setting to change it. However any other library is just as likely to mess with MAXBLOCK, so our django setting could ultimately just be scrapped. So I'm thinking we should just remove that line entirely and maybe log a warning in the except clause I added saying something like "You might want to increase ImageFile.MAXBLOCK." That way we won't cause any problems for other libraries (which may set it to something higher), an image always gets produced, and we provide some feedback about avoiding the IOError in the first place. @bryanveloso Thoughts?

[matthewwithanm]

…or maybe we shouldn't even bother with the warning?

[bryanveloso]

You said "fix ##" in your commit message, hence the closure. :)

The warning could be good to have in place for situations such as these, especially when the project mainly deals with large files. That way IK won't be switching between two MAXBLOCK values. Although it feels a bit more "automatic" if we just let that function work its magic on an image-by-image basis and not even worry about presenting a warning.

I could go either way.

[rizumu]

Yes indeed, this solves the problem. Thanks for taking a look so quickly. Interestingly it was the image proportions, and had nothing to do with the feeds.py :)

[matthewwithanm]

@bryanveloso I figured that's what it was. Funny that I could say "doesn't at all fix #X" and close the issue!

I looked through the PIL source and it doesn't seem like switching MAXBLOCK has any cost at all, so we could certainly do that every time without warning. The IOError, on the other hand, is probably something that should be avoided. So logging a warning is probably good. (Unless I'm wrong and the IOError isn't costly.)

I'm thinking now that we should replace line 19 with this:

if ImageFile.MAXBLOCK < 256 * 2 ** 10:
    ImageFile.MAXBLOCK = 256 * 2 ** 10

That way people won't start getting new warnings for sizes that used to work, and we won't decrease the value another library has set.

If you agree, I'll try to get to it (and the warning) later today.

[bryanveloso]

@matthewwithanm, looks good to me!

[matthewwithanm]

I decided to go with my original approach (removing line 19 entirely) and not log a warning. I think this is the least troublesome since it stays out of everybody's way—both the people like @rizumu who just want their big images to work, and the people/apps that are trying to set MAXBLOCK themselves. If anybody complains, we can reconsider (:

Check it out: 8911836

[andrewebdev]

I'm still getting this error with 1.1.0

File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/core/handlers/base.py" in get_response
  136.                     response = response.render()
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/response.py" in render
  97.             self._set_content(self.rendered_content)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/response.py" in rendered_content
  75.         content = template.render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render
  123.             return self._render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in _render
  117.         return self.nodelist.render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/defaulttags.py" in render
  311.             return self.nodelist_true.render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/defaulttags.py" in render
  227.                 nodelist.append(node.render(context))
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in render
  792.             output = self.filter_expression.resolve(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in resolve
  510.                 obj = self.var.resolve(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in resolve
  653.             value = self._resolve_lookup(context)
File "/home/andre/dev/InterActivPT/eggs/Django-1.3.1-py2.7.egg/django/template/base.py" in _resolve_lookup
  683.                         current = getattr(current, bit)
File "/home/andre/dev/InterActivPT/parts/django-imagekit/imagekit/models.py" in url
  196.         self.generate()
File "/home/andre/dev/InterActivPT/parts/django-imagekit/imagekit/models.py" in generate
  221.             img, content = self._process_content(self.name, fp)
File "/home/andre/dev/InterActivPT/parts/django-imagekit/imagekit/models.py" in _process_content
  151.         imgfile = img_to_fobj(img, format, **options)
File "/home/andre/dev/InterActivPT/parts/django-imagekit/imagekit/utils.py" in img_to_fobj
  20.             img.save(tmp, format, **kwargs)
File "/home/andre/dev/InterActivPT/eggs/Pillow-1.7.5-py2.7-linux-i686.egg/PIL/Image.py" in save
  1439.             save_handler(self, fp, filename)
File "/home/andre/dev/InterActivPT/eggs/Pillow-1.7.5-py2.7-linux-i686.egg/PIL/JpegImagePlugin.py" in _save
  471.     ImageFile._save(im, fp, [("jpeg", (0,0)+im.size, 0, rawmode)])
File "/home/andre/dev/InterActivPT/eggs/Pillow-1.7.5-py2.7-linux-i686.egg/PIL/ImageFile.py" in _save
  501.                 raise IOError("encoder error %d when writing image file" % s)

Exception Type: IOError at /contentbrowser/browse/items/
Exception Value: encoder error -2 when writing image file

In the terminal there is a single line output: "Suspension not allowed here"

If I use a smaller original image then it works.

[matthewwithanm]

@andrewebdev I believe this commit is only in the develop branch. We'll try to get the next release together ASAP but until then, you can use the develop branch.

[andrewebdev]

For the time being, I've reduce the image Quality down to 90 rather than 100. This seems to work for now, and the compromise isn't that big. I'll keep an eye out for the latest stable release :)

Thanks!

[jperelli]

This bug continues, I've installed using pip, and I got the same error for a jpeg img

[matthewwithanm]

@jperelli What version are you using?

[jperelli]

Django==1.4.3
django-imagekit==2.0.2
PIL==1.1.7

changing this line in imagekit/utils.py

ImageFile.MAXBLOCK = img.size[0] * img.size[1]

to this

ImageFile.MAXBLOCK = img.size[0] * img.size[1] * 10

Fixes the issue for me, but I suspect this modification could have side effects? no idea...

[matthewwithanm]

Where is the 10 coming from? This kind of workaround seems really arbitrary.

This line has actually already been changed in PILKit—which is being used by version 3 of ImageKit (now an alpha release). We could make backport it for a 2.x support release though.

[jperelli]

Yes, as you say, it's arbitrary, but it worked for me in this case.

A backport of this fix would be great!

[matthewwithanm]

Yeah, we can do that. @bryanveloso how should we handle that? Do you want to create a support branch for the 2.0.x series?

[bryanveloso]

@matthewwithanm — Yep, I can do that. I'll tag 2.0.3 right before the IK-next merge and we can apply the fix.

[matthewwithanm]

Can I get this fix in first? Just let me know which branch to use.

[bryanveloso]

@matthewwithanm — Go for it, support/2.0.x.

[jperelli]

Great work you all are awesome!

Is this going to be available from pip install django-imagekit?

[matthewwithanm]

Thanks (:

Yeah, it will. @bryanveloso will be pushing it to PyPI as 2.0.3 soon.

[bryanveloso]

2.0.3 has been pushed to PyPI. Apologies for the wait!