I have a problem_page such that
from PIL import Image
problem_page = "/home/rajiv/tmp/kd/pss-images/f1-577.jpg"
img = Image.open(problem_page)
results in
PIL.Image.DecompressionBombError: Image size (370390741 pixels) exceeds limit of 178956970 pixels, could be decompression bomb DOS attack.
I'd like to respect the limit and not increase the limit (as described here: Pillow in Python won't let me open image ("exceeds limit"))
How can I load it in a way that the resolution is lowered just below the limit and the lower resolution image is referenced in img without causing any error.
It'd be great to have a Python solution but if not, any other solution will work too.
Update(to answer questions in comments):
These images are derived from PDFs to do machine learning(ML). These PDFs come from outside the system. So we have to protect our system from possible decompression bombs. For most ML, pixel size requirements are well below the limit imposed by PIL so we are ok with that limit as a heuristic to protect us.
Our current option is to use pdf2image which converts pdfs to images and specify a pixel size (e.g. width=1700 pixels, height=2200 pixels) there but I was curious if this can be done at the point of loading an image.
Related
I used PIL to open and save the same jpg image, but the size reduces significantly. Could somebody explained what's going on under the hood?
I run
a = Image.open('a.jpg')
a.save('b.jpg')
a.jpg has the size 5MB, whereas b.jpg is only 600KB. and I enlarge them and compared side by side and basically see no differences in the picture quality. Could somebody explain this?
Much appreciated!
The default save quality for jpg in Pillow is 75. I bet your original image is saved with a higher quality setting.
The image quality, on a scale from 0 (worst) to 95 (best), or the string keep. The default is 75. Values above 95 should be avoided; 100 disables portions of the JPEG compression algorithm, and results in large files with hardly any gain in image quality. The value keep is only valid for JPEG files and will retain the original image quality level, subsampling, and qtables.
From https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#jpeg
I use python pillow to do a easy gif image reverse,but I found that the image has become more size(10m) than before(1m). Anyone know how to make it?
And here is my code:
from PIL import Image, ImageSequence
from PIL import ImagePalette
with Image.open('sd.gif') as im:
if im.is_animated:
frames = [f.copy() for f in ImageSequence.Iterator(im)]
frames.reverse()
frames[0].save('out.gif', save_all=True, append_images = frames[1:])
I can't tell for sure without examining the actual images, but I can guess what likely happened:
Some gifs are optimized with a method that finds pixels in each frame where nothing is changing (or changing only very slightly) from frame to frame, and make them transparent instead of storing the color for each pixel, to reduce the amount of data. For some gifs with large static areas in many consecutive frames this can be very efficient way to reduce file size.
When you are reversing the GIF, the frames must be unoptimized first, otherwise there would be transparent areas without any data. This can increase file size quite a bit. The difference may vary from one image to another.
You probably can solve this by running some gif optimization algorithm after the new image is created.
I am trying to lower the file size of an image using pillow (pil) however lowering the image quality doesn't lower the size of the saves image.
The saved images 'image2' and 'image3' are the same size.
import PIL from Image
im = Image.open('image.png')
im.save('image2.png', quality=100)
im.save('image3.png', quality=10)
The PNG format only supports lossless compression, for which the compression ratio is usually limited and not freely adjustable.
If I am right, there is a variable parameter that tells the compressor to spend more or less time finding a better compression scheme. But without a guarantee to succeed.
You have to use image compression to reduce sizes - pngquant or similar
https://pngquant.org/
I'm resizing various images with GAE Image service like this:
from google.appengine.api images
img = images.Image(image_data=get_file_content(image_file_path))
img.resize(width=600)
thumbnail_data = img.execute_transforms(output_encoding=images.JPEG)
It works fine but for an animated GIF image, execute_transforms raises LargeImageError. The image size is 143KB and has a resolution of 607x571px. This happens in GAE but not in my local development server.
In Images Python API Overview says that the image must be no larger than 32 megabytes. But this is not the case.
This looks like a legitimate bug to me. It is possible that the Image service somehow treats all frames in an animated GIF as a single image, exceeding the size limit.
Note that black image is not a bug. JPEG does not support transparency:
transparent_substitution_rgb
If transparent pixels are not supported
in the destination image format, the default is to substitute black.
You can replace this default color with another substitution by
specifying it in 32-bit RGB format.
It is indeed a bug, one of the many images service bugs/shortcomings, I suspect a major improvement to the images service should be on it's way, it has been lagging behind the latest resolution improvements / retina screens etc.
Please star this issue - they fix things when a lot of people star an issue, I've also linked this question over the issue tracker
I am using the following code to resize an image using PIL
img = Image.open("in.png")
resized = ImageOps.fit(img, (200, 200), method=Image.ANTIALIAS)
resized.save("out.png")
But the output image colors look very different. Here they are for comparison, the big one is the original:
What's even stranger is that when I open them using the image viewer in ubuntu, they look the same. But not in Windows or MacOS.
The larger image is using the Adobe RGB color profile. It is omitted from the smaller image, which means the color correction system will use some default (probably sRGB), which likely has a smaller gamut. This will cause the colors to appear duller.
Solution 1: Create the original image using sRGB instead of Adobe RGB.
Solution 2: Copy the color profile from the larger image to the smaller image.
Most Linux systems do not support color correction, at least not on the same scope that OS X or Windows do. So the fact that they appear the same in Ubuntu's image viewer is really a limitation of the image viewer program, which is unable to understand color profiles.