2015-01-18 21:56:29 +03:00
|
|
|
import os
|
2019-07-06 23:40:53 +03:00
|
|
|
from io import BytesIO
|
|
|
|
|
2020-02-03 12:11:32 +03:00
|
|
|
import pytest
|
2019-07-06 23:40:53 +03:00
|
|
|
from PIL import Image, ImageFile, JpegImagePlugin
|
2014-01-27 23:27:03 +04:00
|
|
|
|
2019-09-25 12:46:54 +03:00
|
|
|
from .helper import (
|
|
|
|
PillowTestCase,
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image,
|
|
|
|
assert_image_equal,
|
|
|
|
assert_image_similar,
|
2019-09-25 12:46:54 +03:00
|
|
|
cjpeg_available,
|
|
|
|
djpeg_available,
|
|
|
|
hopper,
|
|
|
|
is_win32,
|
|
|
|
unittest,
|
|
|
|
)
|
2012-10-16 00:26:38 +04:00
|
|
|
|
|
|
|
codecs = dir(Image.core)
|
|
|
|
|
2014-09-23 20:52:03 +04:00
|
|
|
TEST_FILE = "Tests/images/hopper.jpg"
|
2012-10-16 00:26:38 +04:00
|
|
|
|
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
class TestFileJpeg(PillowTestCase):
|
|
|
|
def setUp(self):
|
|
|
|
if "jpeg_encoder" not in codecs or "jpeg_decoder" not in codecs:
|
|
|
|
self.skipTest("jpeg support not available")
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def roundtrip(self, im, **options):
|
|
|
|
out = BytesIO()
|
|
|
|
im.save(out, "JPEG", **options)
|
2015-04-24 11:24:52 +03:00
|
|
|
test_bytes = out.tell()
|
2014-06-10 13:10:47 +04:00
|
|
|
out.seek(0)
|
|
|
|
im = Image.open(out)
|
2015-04-24 11:24:52 +03:00
|
|
|
im.bytes = test_bytes # for testing only
|
2014-06-10 13:10:47 +04:00
|
|
|
return im
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2019-06-13 18:54:11 +03:00
|
|
|
def gen_random_image(self, size, mode="RGB"):
|
2016-12-03 17:45:05 +03:00
|
|
|
""" Generates a very hard to compress file
|
|
|
|
:param size: tuple
|
|
|
|
:param mode: optional image mode
|
2017-03-03 13:32:31 +03:00
|
|
|
|
2016-12-03 17:45:05 +03:00
|
|
|
"""
|
2019-06-13 18:54:11 +03:00
|
|
|
return Image.frombytes(mode, size, os.urandom(size[0] * size[1] * len(mode)))
|
2017-03-03 13:32:31 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_sanity(self):
|
2014-05-21 15:32:24 +04:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
# internal version number
|
2018-04-10 13:40:44 +03:00
|
|
|
self.assertRegex(Image.core.jpeglib_version, r"\d+\.\d+$")
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(TEST_FILE) as im:
|
|
|
|
im.load()
|
|
|
|
self.assertEqual(im.mode, "RGB")
|
|
|
|
self.assertEqual(im.size, (128, 128))
|
|
|
|
self.assertEqual(im.format, "JPEG")
|
|
|
|
self.assertEqual(im.get_format_mimetype(), "image/jpeg")
|
2014-05-21 15:32:24 +04:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_app(self):
|
|
|
|
# Test APP/COM reader (@PIL135)
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(TEST_FILE) as im:
|
|
|
|
self.assertEqual(
|
|
|
|
im.applist[0], ("APP0", b"JFIF\x00\x01\x01\x01\x00`\x00`\x00\x00")
|
|
|
|
)
|
|
|
|
self.assertEqual(
|
|
|
|
im.applist[1], ("COM", b"File written by Adobe Photoshop\xa8 4.0\x00")
|
|
|
|
)
|
|
|
|
self.assertEqual(len(im.applist), 2)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_cmyk(self):
|
|
|
|
# Test CMYK handling. Thanks to Tim and Charlie for test data,
|
|
|
|
# Michael for getting me to look one more time.
|
|
|
|
f = "Tests/images/pil_sample_cmyk.jpg"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(f) as im:
|
|
|
|
# the source image has red pixels in the upper left corner.
|
|
|
|
c, m, y, k = [x / 255.0 for x in im.getpixel((0, 0))]
|
|
|
|
self.assertEqual(c, 0.0)
|
|
|
|
self.assertGreater(m, 0.8)
|
|
|
|
self.assertGreater(y, 0.8)
|
|
|
|
self.assertEqual(k, 0.0)
|
|
|
|
# the opposite corner is black
|
|
|
|
c, m, y, k = [
|
|
|
|
x / 255.0 for x in im.getpixel((im.size[0] - 1, im.size[1] - 1))
|
|
|
|
]
|
|
|
|
self.assertGreater(k, 0.9)
|
|
|
|
# roundtrip, and check again
|
|
|
|
im = self.roundtrip(im)
|
|
|
|
c, m, y, k = [x / 255.0 for x in im.getpixel((0, 0))]
|
|
|
|
self.assertEqual(c, 0.0)
|
|
|
|
self.assertGreater(m, 0.8)
|
|
|
|
self.assertGreater(y, 0.8)
|
|
|
|
self.assertEqual(k, 0.0)
|
|
|
|
c, m, y, k = [
|
|
|
|
x / 255.0 for x in im.getpixel((im.size[0] - 1, im.size[1] - 1))
|
|
|
|
]
|
|
|
|
self.assertGreater(k, 0.9)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_dpi(self):
|
|
|
|
def test(xdpi, ydpi=None):
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(TEST_FILE) as im:
|
|
|
|
im = self.roundtrip(im, dpi=(xdpi, ydpi or xdpi))
|
2014-06-10 13:10:47 +04:00
|
|
|
return im.info.get("dpi")
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(test(72), (72, 72))
|
|
|
|
self.assertEqual(test(300), (300, 300))
|
|
|
|
self.assertEqual(test(100, 200), (100, 200))
|
2017-06-03 07:04:54 +03:00
|
|
|
self.assertIsNone(test(0)) # square pixels
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_icc(self):
|
|
|
|
# Test ICC support
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/rgb.jpg") as im1:
|
|
|
|
icc_profile = im1.info["icc_profile"]
|
|
|
|
self.assertEqual(len(icc_profile), 3144)
|
|
|
|
# Roundtrip via physical file.
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im1.save(f, icc_profile=icc_profile)
|
|
|
|
with Image.open(f) as im2:
|
|
|
|
self.assertEqual(im2.info.get("icc_profile"), icc_profile)
|
|
|
|
# Roundtrip via memory buffer.
|
|
|
|
im1 = self.roundtrip(hopper())
|
|
|
|
im2 = self.roundtrip(hopper(), icc_profile=icc_profile)
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im1, im2)
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
self.assertFalse(im1.info.get("icc_profile"))
|
|
|
|
self.assertTrue(im2.info.get("icc_profile"))
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_icc_big(self):
|
|
|
|
# Make sure that the "extra" support handles large blocks
|
|
|
|
def test(n):
|
|
|
|
# The ICC APP marker can store 65519 bytes per marker, so
|
|
|
|
# using a 4-byte test code should allow us to detect out of
|
|
|
|
# order issues.
|
2019-06-13 18:54:11 +03:00
|
|
|
icc_profile = (b"Test" * int(n / 4 + 1))[:n]
|
2018-01-17 14:01:37 +03:00
|
|
|
self.assertEqual(len(icc_profile), n) # sanity
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper(), icc_profile=icc_profile)
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(im1.info.get("icc_profile"), icc_profile or None)
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
test(0)
|
|
|
|
test(1)
|
|
|
|
test(3)
|
|
|
|
test(4)
|
|
|
|
test(5)
|
2019-06-13 18:54:11 +03:00
|
|
|
test(65533 - 14) # full JPEG marker block
|
|
|
|
test(65533 - 14 + 1) # full block plus one byte
|
2014-06-10 13:10:47 +04:00
|
|
|
test(ImageFile.MAXBLOCK) # full buffer block
|
2019-06-13 18:54:11 +03:00
|
|
|
test(ImageFile.MAXBLOCK + 1) # full buffer block plus one byte
|
|
|
|
test(ImageFile.MAXBLOCK * 4 + 3) # large block
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2017-06-27 16:31:52 +03:00
|
|
|
def test_large_icc_meta(self):
|
|
|
|
# https://github.com/python-pillow/Pillow/issues/148
|
2017-06-29 12:21:19 +03:00
|
|
|
# Sometimes the meta data on the icc_profile block is bigger than
|
2017-06-27 16:31:52 +03:00
|
|
|
# Image.MAXBLOCK or the image size.
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/icc_profile_big.jpg") as im:
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
icc_profile = im.info["icc_profile"]
|
|
|
|
# Should not raise IOError for image with icc larger than image size.
|
|
|
|
im.save(
|
|
|
|
f,
|
|
|
|
format="JPEG",
|
|
|
|
progressive=True,
|
|
|
|
quality=95,
|
|
|
|
icc_profile=icc_profile,
|
|
|
|
optimize=True,
|
|
|
|
)
|
2017-06-27 16:31:52 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_optimize(self):
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper())
|
2016-09-25 07:10:27 +03:00
|
|
|
im2 = self.roundtrip(hopper(), optimize=0)
|
|
|
|
im3 = self.roundtrip(hopper(), optimize=1)
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im1, im2)
|
|
|
|
assert_image_equal(im1, im3)
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertGreaterEqual(im1.bytes, im2.bytes)
|
2016-09-25 07:10:27 +03:00
|
|
|
self.assertGreaterEqual(im1.bytes, im3.bytes)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_optimize_large_buffer(self):
|
|
|
|
# https://github.com/python-pillow/Pillow/issues/148
|
2019-06-13 18:54:11 +03:00
|
|
|
f = self.tempfile("temp.jpg")
|
2014-06-10 13:10:47 +04:00
|
|
|
# this requires ~ 1.5x Image.MAXBLOCK
|
2019-06-13 18:54:11 +03:00
|
|
|
im = Image.new("RGB", (4096, 4096), 0xFF3333)
|
2014-06-10 13:10:47 +04:00
|
|
|
im.save(f, format="JPEG", optimize=True)
|
|
|
|
|
|
|
|
def test_progressive(self):
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper())
|
2016-09-25 07:10:27 +03:00
|
|
|
im2 = self.roundtrip(hopper(), progressive=False)
|
|
|
|
im3 = self.roundtrip(hopper(), progressive=True)
|
|
|
|
self.assertFalse(im1.info.get("progressive"))
|
|
|
|
self.assertFalse(im2.info.get("progressive"))
|
|
|
|
self.assertTrue(im3.info.get("progressive"))
|
|
|
|
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im1, im3)
|
2016-09-25 07:10:27 +03:00
|
|
|
self.assertGreaterEqual(im1.bytes, im3.bytes)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_progressive_large_buffer(self):
|
2019-06-13 18:54:11 +03:00
|
|
|
f = self.tempfile("temp.jpg")
|
2014-06-10 13:10:47 +04:00
|
|
|
# this requires ~ 1.5x Image.MAXBLOCK
|
2019-06-13 18:54:11 +03:00
|
|
|
im = Image.new("RGB", (4096, 4096), 0xFF3333)
|
2014-06-10 13:10:47 +04:00
|
|
|
im.save(f, format="JPEG", progressive=True)
|
|
|
|
|
|
|
|
def test_progressive_large_buffer_highest_quality(self):
|
2019-06-13 18:54:11 +03:00
|
|
|
f = self.tempfile("temp.jpg")
|
2017-03-14 12:26:11 +03:00
|
|
|
im = self.gen_random_image((255, 255))
|
2014-06-10 13:10:47 +04:00
|
|
|
# this requires more bytes than pixels in the image
|
|
|
|
im.save(f, format="JPEG", progressive=True, quality=100)
|
|
|
|
|
2016-12-03 17:45:45 +03:00
|
|
|
def test_progressive_cmyk_buffer(self):
|
|
|
|
# Issue 2272, quality 90 cmyk image is tripping the large buffer bug.
|
|
|
|
f = BytesIO()
|
2019-06-13 18:54:11 +03:00
|
|
|
im = self.gen_random_image((256, 256), "CMYK")
|
|
|
|
im.save(f, format="JPEG", progressive=True, quality=94)
|
2017-03-03 13:32:31 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_large_exif(self):
|
|
|
|
# https://github.com/python-pillow/Pillow/issues/148
|
2019-06-13 18:54:11 +03:00
|
|
|
f = self.tempfile("temp.jpg")
|
2014-09-23 20:52:03 +04:00
|
|
|
im = hopper()
|
2019-06-13 18:54:11 +03:00
|
|
|
im.save(f, "JPEG", quality=90, exif=b"1" * 65532)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2015-07-29 16:38:26 +03:00
|
|
|
def test_exif_typeerror(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif_typeerror.jpg") as im:
|
|
|
|
# Should not raise a TypeError
|
|
|
|
im._getexif()
|
2015-09-10 15:21:21 +03:00
|
|
|
|
2015-10-07 12:24:15 +03:00
|
|
|
def test_exif_gps(self):
|
|
|
|
# Arrange
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif_gps.jpg") as im:
|
|
|
|
gps_index = 34853
|
|
|
|
expected_exif_gps = {
|
|
|
|
0: b"\x00\x00\x00\x01",
|
|
|
|
2: (4294967295, 1),
|
|
|
|
5: b"\x01",
|
|
|
|
30: 65535,
|
|
|
|
29: "1999:99:99 99:99:99",
|
|
|
|
}
|
2015-10-07 12:24:15 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act
|
|
|
|
exif = im._getexif()
|
2015-10-07 12:24:15 +03:00
|
|
|
|
|
|
|
# Assert
|
|
|
|
self.assertEqual(exif[gps_index], expected_exif_gps)
|
|
|
|
|
2016-01-01 15:08:44 +03:00
|
|
|
def test_exif_rollback(self):
|
|
|
|
# rolling back exif support in 3.1 to pre-3.0 formatting.
|
|
|
|
# expected from 2.9, with b/u qualifiers switched for 3.2 compatibility
|
2016-02-05 01:57:13 +03:00
|
|
|
# this test passes on 2.9 and 3.1, but not 3.0
|
2019-06-13 18:54:11 +03:00
|
|
|
expected_exif = {
|
|
|
|
34867: 4294967295,
|
|
|
|
258: (24, 24, 24),
|
|
|
|
36867: "2099:09:29 10:10:10",
|
|
|
|
34853: {
|
|
|
|
0: b"\x00\x00\x00\x01",
|
|
|
|
2: (4294967295, 1),
|
|
|
|
5: b"\x01",
|
|
|
|
30: 65535,
|
|
|
|
29: "1999:99:99 99:99:99",
|
|
|
|
},
|
|
|
|
296: 65535,
|
|
|
|
34665: 185,
|
|
|
|
41994: 65535,
|
|
|
|
514: 4294967295,
|
|
|
|
271: "Make",
|
|
|
|
272: "XXX-XXX",
|
|
|
|
305: "PIL",
|
|
|
|
42034: ((1, 1), (1, 1), (1, 1), (1, 1)),
|
|
|
|
42035: "LensMake",
|
|
|
|
34856: b"\xaa\xaa\xaa\xaa\xaa\xaa",
|
|
|
|
282: (4294967295, 1),
|
|
|
|
33434: (4294967295, 1),
|
|
|
|
}
|
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif_gps.jpg") as im:
|
|
|
|
exif = im._getexif()
|
2016-01-01 15:08:44 +03:00
|
|
|
|
|
|
|
for tag, value in expected_exif.items():
|
|
|
|
self.assertEqual(value, exif[tag])
|
|
|
|
|
2015-09-10 15:21:21 +03:00
|
|
|
def test_exif_gps_typeerror(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif_gps_typeerror.jpg") as im:
|
2015-07-29 16:38:26 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Should not raise a TypeError
|
|
|
|
im._getexif()
|
2015-07-29 16:38:26 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_progressive_compat(self):
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper())
|
2016-09-23 13:32:21 +03:00
|
|
|
self.assertFalse(im1.info.get("progressive"))
|
|
|
|
self.assertFalse(im1.info.get("progression"))
|
|
|
|
|
|
|
|
im2 = self.roundtrip(hopper(), progressive=0)
|
|
|
|
im3 = self.roundtrip(hopper(), progression=0) # compatibility
|
|
|
|
self.assertFalse(im2.info.get("progressive"))
|
|
|
|
self.assertFalse(im2.info.get("progression"))
|
|
|
|
self.assertFalse(im3.info.get("progressive"))
|
|
|
|
self.assertFalse(im3.info.get("progression"))
|
|
|
|
|
2014-09-23 20:52:03 +04:00
|
|
|
im2 = self.roundtrip(hopper(), progressive=1)
|
|
|
|
im3 = self.roundtrip(hopper(), progression=1) # compatibility
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im1, im2)
|
|
|
|
assert_image_equal(im1, im3)
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertTrue(im2.info.get("progressive"))
|
|
|
|
self.assertTrue(im2.info.get("progression"))
|
|
|
|
self.assertTrue(im3.info.get("progressive"))
|
|
|
|
self.assertTrue(im3.info.get("progression"))
|
|
|
|
|
|
|
|
def test_quality(self):
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper())
|
|
|
|
im2 = self.roundtrip(hopper(), quality=50)
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image(im1, im2.mode, im2.size)
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertGreaterEqual(im1.bytes, im2.bytes)
|
|
|
|
|
|
|
|
def test_smooth(self):
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper())
|
|
|
|
im2 = self.roundtrip(hopper(), smooth=100)
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image(im1, im2.mode, im2.size)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_subsampling(self):
|
|
|
|
def getsampling(im):
|
|
|
|
layer = im.layer
|
|
|
|
return layer[0][1:3] + layer[1][1:3] + layer[2][1:3]
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
# experimental API
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling=-1) # default
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 2, 1, 1, 1, 1))
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling=0) # 4:4:4
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (1, 1, 1, 1, 1, 1))
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling=1) # 4:2:2
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 1, 1, 1, 1, 1))
|
2017-08-27 20:03:36 +03:00
|
|
|
im = self.roundtrip(hopper(), subsampling=2) # 4:2:0
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 2, 1, 1, 1, 1))
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling=3) # default (undefined)
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 2, 1, 1, 1, 1))
|
|
|
|
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:4:4")
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (1, 1, 1, 1, 1, 1))
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:2:2")
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 1, 1, 1, 1, 1))
|
2017-08-27 20:03:36 +03:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:2:0")
|
|
|
|
self.assertEqual(getsampling(im), (2, 2, 1, 1, 1, 1))
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:1:1")
|
2014-06-10 13:10:47 +04:00
|
|
|
self.assertEqual(getsampling(im), (2, 2, 1, 1, 1, 1))
|
|
|
|
|
2019-06-13 18:54:11 +03:00
|
|
|
self.assertRaises(TypeError, self.roundtrip, hopper(), subsampling="1:1:1")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_exif(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/pil_sample_rgb.jpg") as im:
|
|
|
|
info = im._getexif()
|
|
|
|
self.assertEqual(info[305], "Adobe Photoshop CS Macintosh")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2014-07-16 19:36:56 +04:00
|
|
|
def test_mp(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/pil_sample_rgb.jpg") as im:
|
|
|
|
self.assertIsNone(im._getmp())
|
2014-07-16 19:36:56 +04:00
|
|
|
|
2014-06-10 13:10:47 +04:00
|
|
|
def test_quality_keep(self):
|
2014-09-02 22:49:24 +04:00
|
|
|
# RGB
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper.jpg") as im:
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im.save(f, quality="keep")
|
2014-09-02 22:49:24 +04:00
|
|
|
# Grayscale
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper_gray.jpg") as im:
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im.save(f, quality="keep")
|
2014-09-02 22:49:24 +04:00
|
|
|
# CMYK
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/pil_sample_cmyk.jpg") as im:
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im.save(f, quality="keep")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
def test_junk_jpeg_header(self):
|
|
|
|
# https://github.com/python-pillow/Pillow/issues/630
|
|
|
|
filename = "Tests/images/junk_jpeg_header.jpg"
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(filename):
|
|
|
|
pass
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2016-06-22 23:36:23 +03:00
|
|
|
def test_ff00_jpeg_header(self):
|
|
|
|
filename = "Tests/images/jpeg_ff00_header.jpg"
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(filename):
|
|
|
|
pass
|
2016-06-22 23:36:23 +03:00
|
|
|
|
2018-03-08 08:31:51 +03:00
|
|
|
def test_truncated_jpeg_should_read_all_the_data(self):
|
|
|
|
filename = "Tests/images/truncated_jpeg.jpg"
|
|
|
|
ImageFile.LOAD_TRUNCATED_IMAGES = True
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(filename) as im:
|
|
|
|
im.load()
|
|
|
|
ImageFile.LOAD_TRUNCATED_IMAGES = False
|
|
|
|
self.assertIsNotNone(im.getbbox())
|
2018-03-08 08:31:51 +03:00
|
|
|
|
|
|
|
def test_truncated_jpeg_throws_IOError(self):
|
|
|
|
filename = "Tests/images/truncated_jpeg.jpg"
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(filename) as im:
|
|
|
|
with self.assertRaises(IOError):
|
|
|
|
im.load()
|
2018-03-08 08:31:51 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Test that the error is raised if loaded a second time
|
|
|
|
with self.assertRaises(IOError):
|
|
|
|
im.load()
|
2019-07-13 01:37:17 +03:00
|
|
|
|
2016-05-23 03:53:26 +03:00
|
|
|
def _n_qtables_helper(self, n, test_file):
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(test_file) as im:
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im.save(f, qtables=[[n] * 64] * n)
|
|
|
|
with Image.open(f) as im:
|
|
|
|
self.assertEqual(len(im.quantization), n)
|
|
|
|
reloaded = self.roundtrip(im, qtables="keep")
|
|
|
|
self.assertEqual(im.quantization, reloaded.quantization)
|
2016-05-23 03:53:26 +03:00
|
|
|
|
2014-06-20 11:40:18 +04:00
|
|
|
def test_qtables(self):
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper.jpg") as im:
|
|
|
|
qtables = im.quantization
|
|
|
|
reloaded = self.roundtrip(im, qtables=qtables, subsampling=0)
|
|
|
|
self.assertEqual(im.quantization, reloaded.quantization)
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(im, self.roundtrip(im, qtables="web_low"), 30)
|
|
|
|
assert_image_similar(im, self.roundtrip(im, qtables="web_high"), 30)
|
|
|
|
assert_image_similar(im, self.roundtrip(im, qtables="keep"), 30)
|
2019-11-25 23:03:23 +03:00
|
|
|
|
|
|
|
# valid bounds for baseline qtable
|
|
|
|
bounds_qtable = [int(s) for s in ("255 1 " * 32).split(None)]
|
|
|
|
self.roundtrip(im, qtables=[bounds_qtable])
|
|
|
|
|
|
|
|
# values from wizard.txt in jpeg9-a src package.
|
|
|
|
standard_l_qtable = [
|
|
|
|
int(s)
|
|
|
|
for s in """
|
|
|
|
16 11 10 16 24 40 51 61
|
|
|
|
12 12 14 19 26 58 60 55
|
|
|
|
14 13 16 24 40 57 69 56
|
|
|
|
14 17 22 29 51 87 80 62
|
|
|
|
18 22 37 56 68 109 103 77
|
|
|
|
24 35 55 64 81 104 113 92
|
|
|
|
49 64 78 87 103 121 120 101
|
|
|
|
72 92 95 98 112 100 103 99
|
|
|
|
""".split(
|
|
|
|
None
|
|
|
|
)
|
|
|
|
]
|
|
|
|
|
|
|
|
standard_chrominance_qtable = [
|
|
|
|
int(s)
|
|
|
|
for s in """
|
|
|
|
17 18 24 47 99 99 99 99
|
|
|
|
18 21 26 66 99 99 99 99
|
|
|
|
24 26 56 99 99 99 99 99
|
|
|
|
47 66 99 99 99 99 99 99
|
|
|
|
99 99 99 99 99 99 99 99
|
|
|
|
99 99 99 99 99 99 99 99
|
|
|
|
99 99 99 99 99 99 99 99
|
|
|
|
99 99 99 99 99 99 99 99
|
|
|
|
""".split(
|
|
|
|
None
|
|
|
|
)
|
|
|
|
]
|
|
|
|
# list of qtable lists
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(
|
2019-11-25 23:03:23 +03:00
|
|
|
im,
|
|
|
|
self.roundtrip(
|
|
|
|
im, qtables=[standard_l_qtable, standard_chrominance_qtable]
|
|
|
|
),
|
|
|
|
30,
|
2019-06-13 18:54:11 +03:00
|
|
|
)
|
2019-11-25 23:03:23 +03:00
|
|
|
|
|
|
|
# tuple of qtable lists
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(
|
2019-11-25 23:03:23 +03:00
|
|
|
im,
|
|
|
|
self.roundtrip(
|
|
|
|
im, qtables=(standard_l_qtable, standard_chrominance_qtable)
|
|
|
|
),
|
|
|
|
30,
|
|
|
|
)
|
|
|
|
|
|
|
|
# dict of qtable lists
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(
|
2019-11-25 23:03:23 +03:00
|
|
|
im,
|
|
|
|
self.roundtrip(
|
|
|
|
im, qtables={0: standard_l_qtable, 1: standard_chrominance_qtable}
|
|
|
|
),
|
|
|
|
30,
|
2019-06-13 18:54:11 +03:00
|
|
|
)
|
2019-11-25 23:03:23 +03:00
|
|
|
|
|
|
|
self._n_qtables_helper(1, "Tests/images/hopper_gray.jpg")
|
|
|
|
self._n_qtables_helper(1, "Tests/images/pil_sample_rgb.jpg")
|
|
|
|
self._n_qtables_helper(2, "Tests/images/pil_sample_rgb.jpg")
|
|
|
|
self._n_qtables_helper(3, "Tests/images/pil_sample_rgb.jpg")
|
|
|
|
self._n_qtables_helper(1, "Tests/images/pil_sample_cmyk.jpg")
|
|
|
|
self._n_qtables_helper(2, "Tests/images/pil_sample_cmyk.jpg")
|
|
|
|
self._n_qtables_helper(3, "Tests/images/pil_sample_cmyk.jpg")
|
|
|
|
self._n_qtables_helper(4, "Tests/images/pil_sample_cmyk.jpg")
|
|
|
|
|
|
|
|
# not a sequence
|
|
|
|
self.assertRaises(ValueError, self.roundtrip, im, qtables="a")
|
|
|
|
# sequence wrong length
|
|
|
|
self.assertRaises(ValueError, self.roundtrip, im, qtables=[])
|
|
|
|
# sequence wrong length
|
|
|
|
self.assertRaises(ValueError, self.roundtrip, im, qtables=[1, 2, 3, 4, 5])
|
|
|
|
|
|
|
|
# qtable entry not a sequence
|
|
|
|
self.assertRaises(ValueError, self.roundtrip, im, qtables=[1])
|
|
|
|
# qtable entry has wrong number of items
|
|
|
|
self.assertRaises(ValueError, self.roundtrip, im, qtables=[[1, 2, 3, 4]])
|
2014-09-25 01:15:17 +04:00
|
|
|
|
2014-06-28 02:12:37 +04:00
|
|
|
@unittest.skipUnless(djpeg_available(), "djpeg not available")
|
2014-06-27 07:37:49 +04:00
|
|
|
def test_load_djpeg(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(TEST_FILE) as img:
|
|
|
|
img.load_djpeg()
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(img, Image.open(TEST_FILE), 0)
|
2014-06-27 07:37:49 +04:00
|
|
|
|
2014-06-28 02:12:37 +04:00
|
|
|
@unittest.skipUnless(cjpeg_available(), "cjpeg not available")
|
2014-06-27 07:37:49 +04:00
|
|
|
def test_save_cjpeg(self):
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(TEST_FILE) as img:
|
|
|
|
tempfile = self.tempfile("temp.jpg")
|
|
|
|
JpegImagePlugin._save_cjpeg(img, 0, tempfile)
|
|
|
|
# Default save quality is 75%, so a tiny bit of difference is alright
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(img, Image.open(tempfile), 17)
|
2014-06-27 07:37:49 +04:00
|
|
|
|
2014-08-27 11:46:34 +04:00
|
|
|
def test_no_duplicate_0x1001_tag(self):
|
|
|
|
# Arrange
|
|
|
|
from PIL import ExifTags
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2017-05-28 19:34:41 +03:00
|
|
|
tag_ids = {v: k for k, v in ExifTags.TAGS.items()}
|
2014-08-27 11:46:34 +04:00
|
|
|
|
|
|
|
# Assert
|
2019-06-13 18:54:11 +03:00
|
|
|
self.assertEqual(tag_ids["RelatedImageWidth"], 0x1001)
|
|
|
|
self.assertEqual(tag_ids["RelatedImageLength"], 0x1002)
|
2014-08-27 11:46:34 +04:00
|
|
|
|
2015-01-18 21:56:29 +03:00
|
|
|
def test_MAXBLOCK_scaling(self):
|
2016-12-03 17:45:05 +03:00
|
|
|
im = self.gen_random_image((512, 512))
|
2015-01-18 21:56:29 +03:00
|
|
|
f = self.tempfile("temp.jpeg")
|
|
|
|
im.save(f, quality=100, optimize=True)
|
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(f) as reloaded:
|
|
|
|
# none of these should crash
|
|
|
|
reloaded.save(f, quality="keep")
|
|
|
|
reloaded.save(f, quality="keep", progressive=True)
|
|
|
|
reloaded.save(f, quality="keep", optimize=True)
|
2015-01-18 21:56:29 +03:00
|
|
|
|
2015-07-19 15:56:04 +03:00
|
|
|
def test_bad_mpo_header(self):
|
|
|
|
""" Treat unknown MPO as JPEG """
|
|
|
|
# Arrange
|
|
|
|
|
|
|
|
# Act
|
|
|
|
# Shouldn't raise error
|
2015-09-15 02:52:02 +03:00
|
|
|
fn = "Tests/images/sugarshack_bad_mpo_header.jpg"
|
2020-02-03 12:11:32 +03:00
|
|
|
with pytest.warns(UserWarning, Image.open, fn) as im:
|
2015-07-19 15:56:04 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Assert
|
|
|
|
self.assertEqual(im.format, "JPEG")
|
2015-07-19 15:56:04 +03:00
|
|
|
|
2016-07-03 05:40:34 +03:00
|
|
|
def test_save_correct_modes(self):
|
|
|
|
out = BytesIO()
|
2019-06-13 18:54:11 +03:00
|
|
|
for mode in ["1", "L", "RGB", "RGBX", "CMYK", "YCbCr"]:
|
2016-07-03 05:40:34 +03:00
|
|
|
img = Image.new(mode, (20, 20))
|
|
|
|
img.save(out, "JPEG")
|
|
|
|
|
|
|
|
def test_save_wrong_modes(self):
|
2016-08-09 03:11:35 +03:00
|
|
|
# ref https://github.com/python-pillow/Pillow/issues/2005
|
|
|
|
out = BytesIO()
|
2019-06-13 18:54:11 +03:00
|
|
|
for mode in ["LA", "La", "RGBA", "RGBa", "P"]:
|
2016-08-09 03:11:35 +03:00
|
|
|
img = Image.new(mode, (20, 20))
|
2017-05-27 23:20:03 +03:00
|
|
|
self.assertRaises(IOError, img.save, out, "JPEG")
|
2016-08-09 03:11:35 +03:00
|
|
|
|
2016-09-22 12:41:32 +03:00
|
|
|
def test_save_tiff_with_dpi(self):
|
|
|
|
# Arrange
|
|
|
|
outfile = self.tempfile("temp.tif")
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper.tif") as im:
|
2016-09-22 12:41:32 +03:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
# Act
|
|
|
|
im.save(outfile, "JPEG", dpi=im.info["dpi"])
|
2016-09-22 12:41:32 +03:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
# Assert
|
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
reloaded.load()
|
|
|
|
self.assertEqual(im.info["dpi"], reloaded.info["dpi"])
|
2016-09-22 12:41:32 +03:00
|
|
|
|
2019-03-30 07:03:57 +03:00
|
|
|
def test_load_dpi_rounding(self):
|
|
|
|
# Round up
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/iptc_roundUp.jpg") as im:
|
|
|
|
self.assertEqual(im.info["dpi"], (44, 44))
|
2019-03-30 07:03:57 +03:00
|
|
|
|
|
|
|
# Round down
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/iptc_roundDown.jpg") as im:
|
|
|
|
self.assertEqual(im.info["dpi"], (2, 2))
|
2019-03-30 07:03:57 +03:00
|
|
|
|
|
|
|
def test_save_dpi_rounding(self):
|
|
|
|
outfile = self.tempfile("temp.jpg")
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper.jpg") as im:
|
|
|
|
im.save(outfile, dpi=(72.2, 72.2))
|
2019-03-30 07:03:57 +03:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
self.assertEqual(reloaded.info["dpi"], (72, 72))
|
2019-03-30 07:03:57 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
im.save(outfile, dpi=(72.8, 72.8))
|
2019-11-25 23:03:23 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
self.assertEqual(reloaded.info["dpi"], (73, 73))
|
2019-03-30 07:03:57 +03:00
|
|
|
|
2017-04-11 13:53:01 +03:00
|
|
|
def test_dpi_tuple_from_exif(self):
|
2017-03-14 12:26:11 +03:00
|
|
|
# Arrange
|
|
|
|
# This Photoshop CC 2017 image has DPI in EXIF not metadata
|
2017-04-11 13:53:01 +03:00
|
|
|
# EXIF XResolution is (2000000, 10000)
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/photoshop-200dpi.jpg") as im:
|
2017-03-14 12:26:11 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
self.assertEqual(im.info.get("dpi"), (200, 200))
|
2017-04-04 01:28:33 +03:00
|
|
|
|
2017-04-11 13:53:01 +03:00
|
|
|
def test_dpi_int_from_exif(self):
|
|
|
|
# Arrange
|
|
|
|
# This image has DPI in EXIF not metadata
|
|
|
|
# EXIF XResolution is 72
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif-72dpi-int.jpg") as im:
|
2017-04-11 13:53:01 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
self.assertEqual(im.info.get("dpi"), (72, 72))
|
2017-04-11 13:53:01 +03:00
|
|
|
|
2017-04-04 01:28:33 +03:00
|
|
|
def test_dpi_from_dpcm_exif(self):
|
|
|
|
# Arrange
|
|
|
|
# This is photoshop-200dpi.jpg with EXIF resolution unit set to cm:
|
|
|
|
# exiftool -exif:ResolutionUnit=cm photoshop-200dpi.jpg
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif-200dpcm.jpg") as im:
|
2017-04-04 01:28:33 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
self.assertEqual(im.info.get("dpi"), (508, 508))
|
2017-04-04 01:28:33 +03:00
|
|
|
|
2017-08-09 16:16:14 +03:00
|
|
|
def test_dpi_exif_zero_division(self):
|
|
|
|
# Arrange
|
|
|
|
# This is photoshop-200dpi.jpg with EXIF resolution set to 0/0:
|
|
|
|
# exiftool -XResolution=0/0 -YResolution=0/0 photoshop-200dpi.jpg
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif-dpi-zerodivision.jpg") as im:
|
2017-08-09 16:16:14 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
# This should return the default, and not raise a ZeroDivisionError
|
|
|
|
self.assertEqual(im.info.get("dpi"), (72, 72))
|
2017-08-09 16:16:14 +03:00
|
|
|
|
2017-04-04 01:28:33 +03:00
|
|
|
def test_no_dpi_in_exif(self):
|
|
|
|
# Arrange
|
|
|
|
# This is photoshop-200dpi.jpg with resolution removed from EXIF:
|
|
|
|
# exiftool "-*resolution*"= photoshop-200dpi.jpg
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/no-dpi-in-exif.jpg") as im:
|
2017-04-04 01:28:33 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
# "When the image resolution is unknown, 72 [dpi] is designated."
|
|
|
|
# http://www.exiv2.org/tags.html
|
|
|
|
self.assertEqual(im.info.get("dpi"), (72, 72))
|
2017-03-14 12:26:11 +03:00
|
|
|
|
2017-07-18 11:06:54 +03:00
|
|
|
def test_invalid_exif(self):
|
|
|
|
# This is no-dpi-in-exif with the tiff header of the exif block
|
|
|
|
# hexedited from MM * to FF FF FF FF
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/invalid-exif.jpg") as im:
|
2017-07-18 11:06:54 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# This should return the default, and not a SyntaxError or
|
|
|
|
# OSError for unidentified image.
|
|
|
|
self.assertEqual(im.info.get("dpi"), (72, 72))
|
2017-07-18 11:06:54 +03:00
|
|
|
|
2019-10-17 20:02:15 +03:00
|
|
|
def test_invalid_exif_x_resolution(self):
|
2019-10-28 19:48:37 +03:00
|
|
|
# When no x or y resolution is defined in EXIF
|
2020-01-27 02:59:20 +03:00
|
|
|
with Image.open("Tests/images/invalid-exif-without-x-resolution.jpg") as im:
|
2019-10-17 20:02:15 +03:00
|
|
|
|
2020-01-27 02:59:20 +03:00
|
|
|
# This should return the default, and not a ValueError or
|
|
|
|
# OSError for an unidentified image.
|
|
|
|
self.assertEqual(im.info.get("dpi"), (72, 72))
|
2019-10-17 20:02:15 +03:00
|
|
|
|
2019-01-12 03:40:32 +03:00
|
|
|
def test_ifd_offset_exif(self):
|
|
|
|
# Arrange
|
|
|
|
# This image has been manually hexedited to have an IFD offset of 10,
|
|
|
|
# in contrast to normal 8
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/exif-ifd-offset.jpg") as im:
|
2019-01-12 03:40:32 +03:00
|
|
|
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
# Act / Assert
|
|
|
|
self.assertEqual(im._getexif()[306], "2017:03:13 23:03:09")
|
2019-01-12 03:40:32 +03:00
|
|
|
|
2019-03-06 02:28:45 +03:00
|
|
|
def test_photoshop(self):
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/photoshop-200dpi.jpg") as im:
|
|
|
|
self.assertEqual(
|
|
|
|
im.info["photoshop"][0x03ED],
|
|
|
|
{
|
|
|
|
"XResolution": 200.0,
|
|
|
|
"DisplayedUnitsX": 1,
|
|
|
|
"YResolution": 200.0,
|
|
|
|
"DisplayedUnitsY": 1,
|
|
|
|
},
|
|
|
|
)
|
2019-03-06 02:28:45 +03:00
|
|
|
|
2019-11-30 02:08:32 +03:00
|
|
|
# Test that the image can still load, even with broken Photoshop data
|
|
|
|
# This image had the APP13 length hexedited to be smaller
|
|
|
|
with Image.open("Tests/images/photoshop-200dpi-broken.jpg") as im_broken:
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im_broken, im)
|
2019-11-30 02:08:32 +03:00
|
|
|
|
2019-04-05 12:02:45 +03:00
|
|
|
# This image does not contain a Photoshop header string
|
Improve handling of file resources
Follow Python's file object semantics. User code is responsible for
closing resources (usually through a context manager) in a deterministic
way.
To achieve this, remove __del__ functions. These functions used to
closed open file handlers in an attempt to silence Python
ResourceWarnings. However, using __del__ has the following drawbacks:
- __del__ isn't called until the object's reference count reaches 0.
Therefore, resource handlers remain open or in use longer than
necessary.
- The __del__ method isn't guaranteed to execute on system exit. See the
Python documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__
> It is not guaranteed that __del__() methods are called for objects
> that still exist when the interpreter exits.
- Exceptions that occur inside __del__ are ignored instead of raised.
This has the potential of hiding bugs. This is also in the Python
documentation:
> Warning: Due to the precarious circumstances under which __del__()
> methods are invoked, exceptions that occur during their execution
> are ignored, and a warning is printed to sys.stderr instead.
Instead, always close resource handlers when they are no longer in use.
This will close the file handler at a specified point in the user's code
and not wait until the interpreter chooses to. It is always guaranteed
to run. And, if an exception occurs while closing the file handler, the
bug will not be ignored.
Now, when code receives a ResourceWarning, it will highlight an area
that is mishandling resources. It should not simply be silenced, but
fixed by closing resources with a context manager.
All warnings that were emitted during tests have been cleaned up. To
enable warnings, I passed the `-Wa` CLI option to Python. This exposed
some mishandling of resources in ImageFile.__init__() and
SpiderImagePlugin.loadImageSeries(), they too were fixed.
2019-05-25 19:30:58 +03:00
|
|
|
with Image.open("Tests/images/app13.jpg") as im:
|
|
|
|
self.assertNotIn("photoshop", im.info)
|
2019-04-05 12:02:45 +03:00
|
|
|
|
2020-01-20 17:25:40 +03:00
|
|
|
def test_photoshop_malformed_and_multiple(self):
|
|
|
|
with Image.open("Tests/images/app13-multiple.jpg") as im:
|
|
|
|
self.assertIn("photoshop", im.info)
|
|
|
|
self.assertEqual(24, len(im.info["photoshop"]))
|
|
|
|
apps_13_lengths = [len(v) for k, v in im.applist if k == "APP13"]
|
|
|
|
self.assertEqual([65504, 24], apps_13_lengths)
|
|
|
|
|
2014-06-27 07:37:49 +04:00
|
|
|
|
2019-09-25 12:46:54 +03:00
|
|
|
@unittest.skipUnless(is_win32(), "Windows only")
|
2017-04-01 19:18:38 +03:00
|
|
|
class TestFileCloseW32(PillowTestCase):
|
|
|
|
def setUp(self):
|
|
|
|
if "jpeg_encoder" not in codecs or "jpeg_decoder" not in codecs:
|
|
|
|
self.skipTest("jpeg support not available")
|
2017-04-11 13:53:01 +03:00
|
|
|
|
2017-04-01 19:18:38 +03:00
|
|
|
def test_fd_leak(self):
|
|
|
|
tmpfile = self.tempfile("temp.jpg")
|
|
|
|
|
|
|
|
with Image.open("Tests/images/hopper.jpg") as im:
|
|
|
|
im.save(tmpfile)
|
|
|
|
|
|
|
|
im = Image.open(tmpfile)
|
|
|
|
fp = im.fp
|
|
|
|
self.assertFalse(fp.closed)
|
2018-06-08 12:17:48 +03:00
|
|
|
self.assertRaises(WindowsError, os.remove, tmpfile)
|
2017-04-01 19:18:38 +03:00
|
|
|
im.load()
|
|
|
|
self.assertTrue(fp.closed)
|
2017-04-11 13:53:01 +03:00
|
|
|
# this should not fail, as load should have closed the file.
|
2017-04-01 19:18:38 +03:00
|
|
|
os.remove(tmpfile)
|