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
|
2020-02-17 21:31:38 +03:00
|
|
|
from PIL import ExifTags, 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,
|
2020-02-18 01:03:32 +03:00
|
|
|
skip_unless_feature,
|
2019-09-25 12:46:54 +03:00
|
|
|
unittest,
|
|
|
|
)
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2014-09-23 20:52:03 +04:00
|
|
|
TEST_FILE = "Tests/images/hopper.jpg"
|
2012-10-16 00:26:38 +04:00
|
|
|
|
|
|
|
|
2020-02-18 01:03:32 +03:00
|
|
|
@skip_unless_feature("jpg")
|
2014-06-10 13:10:47 +04:00
|
|
|
class TestFileJpeg(PillowTestCase):
|
|
|
|
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()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.mode == "RGB"
|
|
|
|
assert im.size == (128, 128)
|
|
|
|
assert im.format == "JPEG"
|
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.applist[0] == ("APP0", b"JFIF\x00\x01\x01\x01\x00`\x00`\x00\x00")
|
|
|
|
assert im.applist[1] == (
|
|
|
|
"COM",
|
|
|
|
b"File written by Adobe Photoshop\xa8 4.0\x00",
|
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
|
|
|
)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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))]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert c == 0.0
|
|
|
|
assert m > 0.8
|
|
|
|
assert y > 0.8
|
|
|
|
assert k == 0.0
|
2019-11-25 23:03:23 +03:00
|
|
|
# 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))
|
|
|
|
]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert k > 0.9
|
2019-11-25 23:03:23 +03:00
|
|
|
# roundtrip, and check again
|
|
|
|
im = self.roundtrip(im)
|
|
|
|
c, m, y, k = [x / 255.0 for x in im.getpixel((0, 0))]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert c == 0.0
|
|
|
|
assert m > 0.8
|
|
|
|
assert y > 0.8
|
|
|
|
assert k == 0.0
|
2019-11-25 23:03:23 +03:00
|
|
|
c, m, y, k = [
|
|
|
|
x / 255.0 for x in im.getpixel((im.size[0] - 1, im.size[1] - 1))
|
|
|
|
]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
|
|
|
2020-02-22 16:06:21 +03:00
|
|
|
assert test(72) == (72, 72)
|
|
|
|
assert test(300) == (300, 300)
|
|
|
|
assert test(100, 200) == (100, 200)
|
|
|
|
assert test(0) is None # 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"]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert len(icc_profile) == 3144
|
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
|
|
|
# Roundtrip via physical file.
|
|
|
|
f = self.tempfile("temp.jpg")
|
|
|
|
im1.save(f, icc_profile=icc_profile)
|
|
|
|
with Image.open(f) as im2:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im2.info.get("icc_profile") == icc_profile
|
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
|
|
|
# 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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not im1.info.get("icc_profile")
|
|
|
|
assert 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]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert len(icc_profile) == n # sanity
|
2014-09-23 20:52:03 +04:00
|
|
|
im1 = self.roundtrip(hopper(), icc_profile=icc_profile)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im1.bytes >= im2.bytes
|
|
|
|
assert 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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not im1.info.get("progressive")
|
|
|
|
assert not im2.info.get("progressive")
|
|
|
|
assert im3.info.get("progressive")
|
2016-09-25 07:10:27 +03:00
|
|
|
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im1, im3)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert exif[gps_index] == expected_exif_gps
|
2015-10-07 12:24:15 +03:00
|
|
|
|
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():
|
2020-02-22 16:06:21 +03:00
|
|
|
assert value == exif[tag]
|
2016-01-01 15:08:44 +03:00
|
|
|
|
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())
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not im1.info.get("progressive")
|
|
|
|
assert not im1.info.get("progression")
|
2016-09-23 13:32:21 +03:00
|
|
|
|
|
|
|
im2 = self.roundtrip(hopper(), progressive=0)
|
|
|
|
im3 = self.roundtrip(hopper(), progression=0) # compatibility
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not im2.info.get("progressive")
|
|
|
|
assert not im2.info.get("progression")
|
|
|
|
assert not im3.info.get("progressive")
|
|
|
|
assert not im3.info.get("progression")
|
2016-09-23 13:32:21 +03:00
|
|
|
|
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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im2.info.get("progressive")
|
|
|
|
assert im2.info.get("progression")
|
|
|
|
assert im3.info.get("progressive")
|
|
|
|
assert im3.info.get("progression")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im1.bytes >= im2.bytes
|
2014-06-10 13:10:47 +04:00
|
|
|
|
|
|
|
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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (2, 2, 1, 1, 1, 1)
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling=3) # default (undefined)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (2, 2, 1, 1, 1, 1)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:4:4")
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (1, 1, 1, 1, 1, 1)
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:2:2")
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (2, 1, 1, 1, 1, 1)
|
2017-08-27 20:03:36 +03:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:2:0")
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (2, 2, 1, 1, 1, 1)
|
2014-09-23 20:52:03 +04:00
|
|
|
im = self.roundtrip(hopper(), subsampling="4:1:1")
|
2020-02-22 16:06:21 +03:00
|
|
|
assert getsampling(im) == (2, 2, 1, 1, 1, 1)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(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()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im._getmp() is None
|
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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.getbbox() is not None
|
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:
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(IOError):
|
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.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
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(IOError):
|
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.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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert len(im.quantization) == n
|
2019-11-25 23:03:23 +03:00
|
|
|
reloaded = self.roundtrip(im, qtables="keep")
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(ValueError):
|
|
|
|
self.roundtrip(im, qtables="a")
|
2019-11-25 23:03:23 +03:00
|
|
|
# sequence wrong length
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(ValueError):
|
|
|
|
self.roundtrip(im, qtables=[])
|
2019-11-25 23:03:23 +03:00
|
|
|
# sequence wrong length
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(ValueError):
|
|
|
|
self.roundtrip(im, qtables=[1, 2, 3, 4, 5])
|
2019-11-25 23:03:23 +03:00
|
|
|
|
|
|
|
# qtable entry not a sequence
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(ValueError):
|
|
|
|
self.roundtrip(im, qtables=[1])
|
2019-11-25 23:03:23 +03:00
|
|
|
# qtable entry has wrong number of items
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(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
|
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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert tag_ids["RelatedImageWidth"] == 0x1001
|
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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))
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(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()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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.
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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.
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert "photoshop" not in 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:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert "photoshop" in im.info
|
|
|
|
assert 24 == len(im.info["photoshop"])
|
2020-01-20 17:25:40 +03:00
|
|
|
apps_13_lengths = [len(v) for k, v in im.applist if k == "APP13"]
|
2020-02-22 16:06:21 +03:00
|
|
|
assert [65504, 24] == apps_13_lengths
|
2020-01-20 17:25:40 +03:00
|
|
|
|
2014-06-27 07:37:49 +04:00
|
|
|
|
2019-09-25 12:46:54 +03:00
|
|
|
@unittest.skipUnless(is_win32(), "Windows only")
|
2020-02-18 01:03:32 +03:00
|
|
|
@skip_unless_feature("jpg")
|
2017-04-01 19:18:38 +03:00
|
|
|
class TestFileCloseW32(PillowTestCase):
|
|
|
|
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
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not fp.closed
|
|
|
|
with pytest.raises(WindowsError):
|
|
|
|
os.remove(tmpfile)
|
2017-04-01 19:18:38 +03:00
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert 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)
|