2023-12-21 14:13:31 +03:00
|
|
|
from __future__ import annotations
|
2024-01-20 14:23:03 +03:00
|
|
|
|
2019-10-07 16:28:36 +03:00
|
|
|
import os
|
2022-02-21 05:49:01 +03:00
|
|
|
import warnings
|
2019-07-06 23:40:53 +03:00
|
|
|
from io import BytesIO
|
2024-01-31 12:12:58 +03:00
|
|
|
from pathlib import Path
|
2024-02-17 07:00:38 +03:00
|
|
|
from types import ModuleType
|
|
|
|
from typing import Generator
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2019-11-02 10:10:55 +03:00
|
|
|
import pytest
|
2020-08-07 13:28:33 +03:00
|
|
|
|
2022-10-28 15:11:25 +03:00
|
|
|
from PIL import Image, ImageFile, TiffImagePlugin, UnidentifiedImageError
|
2021-01-28 12:57:24 +03:00
|
|
|
from PIL.TiffImagePlugin import RESOLUTION_UNIT, X_RESOLUTION, Y_RESOLUTION
|
2019-07-06 23:40:53 +03:00
|
|
|
|
2020-01-30 17:56:07 +03:00
|
|
|
from .helper import (
|
|
|
|
assert_image_equal,
|
|
|
|
assert_image_equal_tofile,
|
|
|
|
assert_image_similar,
|
|
|
|
assert_image_similar_tofile,
|
|
|
|
hopper,
|
|
|
|
is_pypy,
|
|
|
|
is_win32,
|
|
|
|
)
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2024-02-17 07:00:38 +03:00
|
|
|
ElementTree: ModuleType | None
|
2021-06-30 04:28:00 +03:00
|
|
|
try:
|
2022-10-13 05:20:11 +03:00
|
|
|
from defusedxml import ElementTree
|
2021-06-30 04:28:00 +03:00
|
|
|
except ImportError:
|
|
|
|
ElementTree = None
|
|
|
|
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2020-03-02 17:02:19 +03:00
|
|
|
class TestFileTiff:
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_sanity(self, tmp_path: Path) -> None:
|
2020-03-02 17:02:19 +03:00
|
|
|
filename = str(tmp_path / "temp.tif")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("RGB").save(filename)
|
2014-06-10 13:10:47 +04: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(filename) as im:
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.mode == "RGB"
|
|
|
|
assert im.size == (128, 128)
|
|
|
|
assert im.format == "TIFF"
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("1").save(filename)
|
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
|
2012-10-16 00:26:38 +04:00
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("L").save(filename)
|
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
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("P").save(filename)
|
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
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("RGB").save(filename)
|
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
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
hopper("I").save(filename)
|
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
|
|
|
|
2020-03-02 17:02:19 +03:00
|
|
|
@pytest.mark.skipif(is_pypy(), reason="Requires CPython")
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_unclosed_file(self) -> None:
|
|
|
|
def open() -> None:
|
2018-11-17 13:56:06 +03:00
|
|
|
im = Image.open("Tests/images/multipage.tiff")
|
|
|
|
im.load()
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2023-03-02 23:50:52 +03:00
|
|
|
with pytest.warns(ResourceWarning):
|
|
|
|
open()
|
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
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_closed_file(self) -> None:
|
2022-02-21 05:49:01 +03:00
|
|
|
with warnings.catch_warnings():
|
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 = Image.open("Tests/images/multipage.tiff")
|
|
|
|
im.load()
|
|
|
|
im.close()
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_seek_after_close(self) -> None:
|
2022-04-17 05:14:53 +03:00
|
|
|
im = Image.open("Tests/images/multipage.tiff")
|
|
|
|
im.close()
|
|
|
|
|
|
|
|
with pytest.raises(ValueError):
|
|
|
|
im.n_frames
|
|
|
|
with pytest.raises(ValueError):
|
|
|
|
im.seek(1)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_context_manager(self) -> None:
|
2022-02-21 05:49:01 +03:00
|
|
|
with warnings.catch_warnings():
|
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/multipage.tiff") as im:
|
|
|
|
im.load()
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_mac_tiff(self) -> None:
|
2016-09-23 14:12:03 +03:00
|
|
|
# Read RGBa images from macOS [@PIL136]
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil136.tiff"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(filename) as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.mode == "RGBA"
|
|
|
|
assert im.size == (55, 43)
|
|
|
|
assert im.tile == [("raw", (0, 0, 55, 43), 8, ("RGBa", 0, 1))]
|
2019-11-25 23:03:23 +03:00
|
|
|
im.load()
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar_tofile(im, "Tests/images/pil136.png", 1)
|
2017-12-13 15:47:11 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_bigtiff(self, tmp_path: Path) -> None:
|
2022-03-01 01:23:12 +03:00
|
|
|
with Image.open("Tests/images/hopper_bigtiff.tif") as im:
|
|
|
|
assert_image_equal_tofile(im, "Tests/images/hopper.tif")
|
|
|
|
|
2023-04-10 02:06:20 +03:00
|
|
|
with Image.open("Tests/images/hopper_bigtiff.tif") as im:
|
|
|
|
# multistrip support not yet implemented
|
|
|
|
del im.tag_v2[273]
|
|
|
|
|
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
im.save(outfile, save_all=True, append_images=[im], tiffinfo=im.tag_v2)
|
|
|
|
|
2024-06-09 08:16:17 +03:00
|
|
|
def test_seek_too_large(self) -> None:
|
2024-03-16 05:33:04 +03:00
|
|
|
with pytest.raises(ValueError, match="Unable to seek to frame"):
|
|
|
|
Image.open("Tests/images/seek_too_large.tif")
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_set_legacy_api(self) -> None:
|
2018-06-06 15:34:09 +03:00
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(Exception) as e:
|
2024-06-22 03:09:11 +03:00
|
|
|
ifd.legacy_api = False
|
2020-02-22 16:06:21 +03:00
|
|
|
assert str(e.value) == "Not allowing setting of legacy api"
|
2017-09-01 13:36:51 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_xyres_tiff(self) -> None:
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil168.tif"
|
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:
|
|
|
|
# legacy api
|
2020-02-22 16:06:21 +03:00
|
|
|
assert isinstance(im.tag[X_RESOLUTION][0], tuple)
|
|
|
|
assert isinstance(im.tag[Y_RESOLUTION][0], tuple)
|
2015-09-11 20:09: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
|
|
|
# v2 api
|
2020-02-22 16:06:21 +03:00
|
|
|
assert isinstance(im.tag_v2[X_RESOLUTION], TiffImagePlugin.IFDRational)
|
|
|
|
assert isinstance(im.tag_v2[Y_RESOLUTION], TiffImagePlugin.IFDRational)
|
2015-09-11 20:09:14 +03:00
|
|
|
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.info["dpi"] == (72.0, 72.0)
|
2015-09-11 20:09:14 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_xyres_fallback_tiff(self) -> None:
|
2017-01-19 19:24:28 +03:00
|
|
|
filename = "Tests/images/compression.tif"
|
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:
|
|
|
|
# v2 api
|
2020-02-22 16:06:21 +03:00
|
|
|
assert isinstance(im.tag_v2[X_RESOLUTION], TiffImagePlugin.IFDRational)
|
|
|
|
assert isinstance(im.tag_v2[Y_RESOLUTION], TiffImagePlugin.IFDRational)
|
|
|
|
with pytest.raises(KeyError):
|
|
|
|
im.tag_v2[RESOLUTION_UNIT]
|
2017-01-19 19:24:28 +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
|
|
|
# Legacy.
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.info["resolution"] == (100.0, 100.0)
|
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
|
|
|
# Fallback "inch".
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.info["dpi"] == (100.0, 100.0)
|
2017-01-19 19:24:28 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_int_resolution(self) -> None:
|
2015-09-14 15:10:27 +03:00
|
|
|
filename = "Tests/images/pil168.tif"
|
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:
|
|
|
|
# Try to read a file where X,Y_RESOLUTION are ints
|
|
|
|
im.tag_v2[X_RESOLUTION] = 71
|
|
|
|
im.tag_v2[Y_RESOLUTION] = 71
|
|
|
|
im._setup()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.info["dpi"] == (71.0, 71.0)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2021-04-17 08:42:06 +03:00
|
|
|
@pytest.mark.parametrize(
|
2022-04-10 22:23:55 +03:00
|
|
|
"resolution_unit, dpi",
|
2021-04-17 08:42:06 +03:00
|
|
|
[(None, 72.8), (2, 72.8), (3, 184.912)],
|
|
|
|
)
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_load_float_dpi(self, resolution_unit: int | None, dpi: float) -> None:
|
2021-04-17 08:42:06 +03:00
|
|
|
with Image.open(
|
2022-04-10 22:23:55 +03:00
|
|
|
"Tests/images/hopper_float_dpi_" + str(resolution_unit) + ".tif"
|
2021-04-17 08:42:06 +03:00
|
|
|
) as im:
|
2022-04-10 22:23:55 +03:00
|
|
|
assert im.tag_v2.get(RESOLUTION_UNIT) == resolution_unit
|
2021-05-10 02:36:57 +03:00
|
|
|
assert im.info["dpi"] == (dpi, dpi)
|
2021-04-17 08:42:06 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_float_dpi(self, tmp_path: Path) -> None:
|
2020-03-02 17:02:19 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/hopper.tif") as im:
|
2021-05-10 02:36:57 +03:00
|
|
|
dpi = (72.2, 72.2)
|
|
|
|
im.save(outfile, dpi=dpi)
|
2019-03-30 07:03:57 +03:00
|
|
|
|
2021-04-17 08:42:06 +03:00
|
|
|
with Image.open(outfile) as reloaded:
|
2021-05-10 02:36:57 +03:00
|
|
|
assert reloaded.info["dpi"] == dpi
|
2019-03-30 07:03:57 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_setting_missing_resolution(self) -> None:
|
2016-09-16 21:07:25 +03:00
|
|
|
b = BytesIO()
|
2021-02-11 13:43:54 +03:00
|
|
|
with Image.open("Tests/images/10ct_32bit_128.tiff") as im:
|
|
|
|
im.save(b, format="tiff", resolution=123.45)
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(b) as im:
|
2021-05-10 02:36:57 +03:00
|
|
|
assert im.tag_v2[X_RESOLUTION] == 123.45
|
|
|
|
assert im.tag_v2[Y_RESOLUTION] == 123.45
|
2016-09-16 21:07:25 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_invalid_file(self) -> None:
|
2015-07-13 16:37:44 +03:00
|
|
|
invalid_file = "Tests/images/flower.jpg"
|
|
|
|
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(SyntaxError):
|
|
|
|
TiffImagePlugin.TiffImageFile(invalid_file)
|
2015-07-13 16:37:44 +03:00
|
|
|
|
2016-10-22 20:55:50 +03:00
|
|
|
TiffImagePlugin.PREFIXES.append(b"\xff\xd8\xff\xe0")
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(SyntaxError):
|
|
|
|
TiffImagePlugin.TiffImageFile(invalid_file)
|
2016-01-02 04:27:40 +03:00
|
|
|
TiffImagePlugin.PREFIXES.pop()
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_bad_exif(self) -> None:
|
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/hopper_bad_exif.jpg") as i:
|
|
|
|
# Should not raise struct.error.
|
2023-02-23 16:30:38 +03:00
|
|
|
with pytest.warns(UserWarning):
|
|
|
|
i._getexif()
|
2015-06-06 17:04:39 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_rgba(self, tmp_path: Path) -> None:
|
2015-12-01 20:14:32 +03:00
|
|
|
im = hopper("RGBA")
|
2020-03-02 17:02:19 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
2015-12-01 20:14:32 +03:00
|
|
|
im.save(outfile)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_unsupported_mode(self, tmp_path: Path) -> None:
|
2015-07-13 16:37:44 +03:00
|
|
|
im = hopper("HSV")
|
2020-03-02 17:02:19 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
2020-04-07 09:58:21 +03:00
|
|
|
with pytest.raises(OSError):
|
2020-02-22 16:06:21 +03:00
|
|
|
im.save(outfile)
|
2015-06-06 17:04:39 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_8bit_s(self) -> None:
|
2023-05-04 00:54:30 +03:00
|
|
|
with Image.open("Tests/images/8bit.s.tif") as im:
|
|
|
|
im.load()
|
|
|
|
assert im.mode == "L"
|
|
|
|
assert im.getpixel((50, 50)) == 184
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_little_endian(self) -> None:
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/16bit.cropped.tif") as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.getpixel((0, 0)) == 480
|
|
|
|
assert im.mode == "I;16"
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
b = im.tobytes()
|
2014-06-10 13:10:47 +04:00
|
|
|
# Bytes are in image native order (little endian)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert b[0] == ord(b"\xe0")
|
|
|
|
assert b[1] == ord(b"\x01")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_big_endian(self) -> None:
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/16bit.MM.cropped.tif") as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.getpixel((0, 0)) == 480
|
|
|
|
assert im.mode == "I;16B"
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
b = im.tobytes()
|
2014-06-10 13:10:47 +04:00
|
|
|
# Bytes are in image native order (big endian)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert b[0] == ord(b"\x01")
|
|
|
|
assert b[1] == ord(b"\xe0")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_16bit_r(self) -> None:
|
2022-03-20 05:34:48 +03:00
|
|
|
with Image.open("Tests/images/16bit.r.tif") as im:
|
|
|
|
assert im.getpixel((0, 0)) == 480
|
|
|
|
assert im.mode == "I;16"
|
|
|
|
|
|
|
|
b = im.tobytes()
|
|
|
|
assert b[0] == ord(b"\xe0")
|
|
|
|
assert b[1] == ord(b"\x01")
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_16bit_s(self) -> None:
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/16bit.s.tif") as im:
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.mode == "I"
|
|
|
|
assert im.getpixel((0, 0)) == 32767
|
|
|
|
assert im.getpixel((0, 1)) == 0
|
2015-09-19 03:12:00 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_12bit_rawmode(self) -> None:
|
2020-08-31 00:37:17 +03:00
|
|
|
"""Are we generating the same interpretation
|
|
|
|
of the image as Imagemagick is?"""
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/12bit.cropped.tif") as im:
|
|
|
|
# to make the target --
|
|
|
|
# convert 12bit.cropped.tif -depth 16 tmp.tif
|
|
|
|
# convert tmp.tif -evaluate RightShift 4 12in16bit2.tif
|
|
|
|
# imagemagick will auto scale so that a 12bit FFF is 16bit FFF0,
|
|
|
|
# so we need to unshift so that the integer values are the same.
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal_tofile(im, "Tests/images/12in16bit.tif")
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_32bit_float(self) -> None:
|
2015-10-14 16:49:03 +03:00
|
|
|
# Issue 614, specific 32-bit float format
|
2019-06-13 18:54:11 +03:00
|
|
|
path = "Tests/images/10ct_32bit_128.tiff"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(path) as im:
|
|
|
|
im.load()
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.getpixel((0, 0)) == -0.4526388943195343
|
|
|
|
assert im.getextrema() == (-3.140936851501465, 3.140684127807617)
|
2014-06-10 13:10:47 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_unknown_pixel_mode(self) -> None:
|
2020-04-07 09:58:21 +03:00
|
|
|
with pytest.raises(OSError):
|
2021-02-11 13:43:54 +03:00
|
|
|
with Image.open("Tests/images/hopper_unknown_pixel_mode.tif"):
|
|
|
|
pass
|
2019-01-04 04:29:23 +03:00
|
|
|
|
2022-10-03 08:57:42 +03:00
|
|
|
@pytest.mark.parametrize(
|
|
|
|
"path, n_frames",
|
|
|
|
(
|
|
|
|
("Tests/images/multipage-lastframe.tif", 1),
|
|
|
|
("Tests/images/multipage.tiff", 3),
|
|
|
|
),
|
|
|
|
)
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_n_frames(self, path: str, n_frames: int) -> None:
|
2022-10-03 08:57:42 +03:00
|
|
|
with Image.open(path) as im:
|
|
|
|
assert im.n_frames == n_frames
|
|
|
|
assert im.is_animated == (n_frames != 1)
|
2015-06-07 18:01:34 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_eoferror(self) -> None:
|
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/multipage-lastframe.tif") as im:
|
|
|
|
n_frames = im.n_frames
|
2017-09-06 06:19: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
|
|
|
# Test seeking past the last frame
|
2020-02-22 16:06:21 +03:00
|
|
|
with pytest.raises(EOFError):
|
|
|
|
im.seek(n_frames)
|
|
|
|
assert im.tell() < n_frames
|
2017-09-06 06:19: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
|
|
|
# Test that seeking to the last frame does not raise an error
|
|
|
|
im.seek(n_frames - 1)
|
2015-06-07 18:01:34 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_multipage(self) -> None:
|
2014-08-21 08:43:46 +04:00
|
|
|
# issue #862
|
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/multipage.tiff") as im:
|
|
|
|
# file is a multipage tiff: 10x10 green, 10x10 red, 20x20 blue
|
2014-08-21 08:43:46 +04: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.seek(0)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (10, 10)
|
|
|
|
assert im.convert("RGB").getpixel((0, 0)) == (0, 128, 0)
|
2014-08-21 08:43:46 +04: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.seek(1)
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (10, 10)
|
|
|
|
assert im.convert("RGB").getpixel((0, 0)) == (255, 0, 0)
|
2014-08-21 08:43:46 +04: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.seek(0)
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (10, 10)
|
|
|
|
assert im.convert("RGB").getpixel((0, 0)) == (0, 128, 0)
|
2019-03-13 10:54:09 +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.seek(2)
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (20, 20)
|
|
|
|
assert im.convert("RGB").getpixel((0, 0)) == (0, 0, 255)
|
2014-08-21 08:43:46 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_multipage_last_frame(self) -> None:
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open("Tests/images/multipage-lastframe.tif") as im:
|
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (20, 20)
|
|
|
|
assert im.convert("RGB").getpixel((0, 0)) == (0, 0, 255)
|
2014-08-21 08:43:46 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_frame_order(self) -> None:
|
2021-05-07 17:25:47 +03:00
|
|
|
# A frame can't progress to itself after reading
|
|
|
|
with Image.open("Tests/images/multipage_single_frame_loop.tiff") as im:
|
|
|
|
assert im.n_frames == 1
|
|
|
|
|
|
|
|
# A frame can't progress to a frame that has already been read
|
|
|
|
with Image.open("Tests/images/multipage_multiple_frame_loop.tiff") as im:
|
|
|
|
assert im.n_frames == 2
|
|
|
|
|
|
|
|
# Frames don't have to be in sequence
|
|
|
|
with Image.open("Tests/images/multipage_out_of_order.tiff") as im:
|
|
|
|
assert im.n_frames == 3
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test___str__(self) -> None:
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil136.tiff"
|
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:
|
|
|
|
# Act
|
|
|
|
ret = str(im.ifd)
|
2014-07-27 23:18:42 +04: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 isinstance(ret, str)
|
2015-02-08 20:09:39 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_dict(self) -> None:
|
2016-04-03 16:41:28 +03:00
|
|
|
# Arrange
|
|
|
|
filename = "Tests/images/pil136.tiff"
|
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:
|
|
|
|
# v2 interface
|
|
|
|
v2_tags = {
|
|
|
|
256: 55,
|
|
|
|
257: 43,
|
|
|
|
258: (8, 8, 8, 8),
|
|
|
|
259: 1,
|
|
|
|
262: 2,
|
|
|
|
296: 2,
|
|
|
|
273: (8,),
|
|
|
|
338: (1,),
|
|
|
|
277: 4,
|
|
|
|
279: (9460,),
|
|
|
|
282: 72.0,
|
|
|
|
283: 72.0,
|
|
|
|
284: 1,
|
|
|
|
}
|
2020-02-22 16:06:21 +03:00
|
|
|
assert dict(im.tag_v2) == v2_tags
|
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
|
|
|
|
|
|
|
# legacy interface
|
|
|
|
legacy_tags = {
|
|
|
|
256: (55,),
|
|
|
|
257: (43,),
|
|
|
|
258: (8, 8, 8, 8),
|
|
|
|
259: (1,),
|
|
|
|
262: (2,),
|
|
|
|
296: (2,),
|
|
|
|
273: (8,),
|
|
|
|
338: (1,),
|
|
|
|
277: (4,),
|
|
|
|
279: (9460,),
|
|
|
|
282: ((720000, 10000),),
|
|
|
|
283: ((720000, 10000),),
|
|
|
|
284: (1,),
|
|
|
|
}
|
2020-02-22 16:06:21 +03:00
|
|
|
assert dict(im.tag) == legacy_tags
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test__delitem__(self) -> None:
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil136.tiff"
|
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:
|
|
|
|
len_before = len(dict(im.ifd))
|
|
|
|
del im.ifd[256]
|
|
|
|
len_after = len(dict(im.ifd))
|
2020-02-22 16:06:21 +03:00
|
|
|
assert len_before == len_after + 1
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2022-10-03 08:57:42 +03:00
|
|
|
@pytest.mark.parametrize("legacy_api", (False, True))
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_load_byte(self, legacy_api: bool) -> None:
|
2022-10-03 08:57:42 +03:00
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
|
|
|
data = b"abc"
|
|
|
|
ret = ifd.load_byte(data, legacy_api)
|
|
|
|
assert ret == b"abc"
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_load_string(self) -> None:
|
2015-09-11 20:09:14 +03:00
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
2014-07-27 23:18:42 +04:00
|
|
|
data = b"abc\0"
|
2015-09-14 14:35:09 +03:00
|
|
|
ret = ifd.load_string(data, False)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert ret == "abc"
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_load_float(self) -> None:
|
2015-09-11 20:09:14 +03:00
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
2014-07-27 23:18:42 +04:00
|
|
|
data = b"abcdabcd"
|
2015-09-14 14:35:09 +03:00
|
|
|
ret = ifd.load_float(data, False)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert ret == (1.6777999408082104e22, 1.6777999408082104e22)
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_load_double(self) -> None:
|
2015-09-11 20:09:14 +03:00
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
2014-07-27 23:18:42 +04:00
|
|
|
data = b"abcdefghabcdefgh"
|
2015-09-14 14:35:09 +03:00
|
|
|
ret = ifd.load_double(data, False)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert ret == (8.540883223036124e194, 8.540883223036124e194)
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_ifd_tag_type(self) -> None:
|
2020-10-14 15:37:54 +03:00
|
|
|
with Image.open("Tests/images/ifd_tag_type.tiff") as im:
|
|
|
|
assert 0x8825 in im.tag_v2
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_exif(self, tmp_path: Path) -> None:
|
2024-02-17 07:00:38 +03:00
|
|
|
def check_exif(exif: Image.Exif) -> None:
|
2021-04-19 12:46:49 +03:00
|
|
|
assert sorted(exif.keys()) == [
|
|
|
|
256,
|
|
|
|
257,
|
|
|
|
258,
|
|
|
|
259,
|
|
|
|
262,
|
|
|
|
271,
|
|
|
|
272,
|
|
|
|
273,
|
|
|
|
277,
|
|
|
|
278,
|
|
|
|
279,
|
|
|
|
282,
|
|
|
|
283,
|
|
|
|
284,
|
|
|
|
296,
|
|
|
|
297,
|
|
|
|
305,
|
|
|
|
339,
|
|
|
|
700,
|
|
|
|
34665,
|
|
|
|
34853,
|
|
|
|
50735,
|
|
|
|
]
|
|
|
|
assert exif[256] == 640
|
|
|
|
assert exif[271] == "FLIR"
|
|
|
|
|
|
|
|
gps = exif.get_ifd(0x8825)
|
|
|
|
assert list(gps.keys()) == [0, 1, 2, 3, 4, 5, 6, 18]
|
|
|
|
assert gps[0] == b"\x03\x02\x00\x00"
|
|
|
|
assert gps[18] == "WGS-84"
|
|
|
|
|
2021-07-04 05:33:55 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
with Image.open("Tests/images/ifd_tag_type.tiff") as im:
|
|
|
|
exif = im.getexif()
|
|
|
|
check_exif(exif)
|
|
|
|
|
|
|
|
im.save(outfile, exif=exif)
|
|
|
|
|
2021-07-04 06:32:41 +03:00
|
|
|
outfile2 = str(tmp_path / "temp2.tif")
|
2021-07-04 05:33:55 +03:00
|
|
|
with Image.open(outfile) as im:
|
|
|
|
exif = im.getexif()
|
|
|
|
check_exif(exif)
|
|
|
|
|
2021-07-04 06:32:41 +03:00
|
|
|
im.save(outfile2, exif=exif.tobytes())
|
|
|
|
|
|
|
|
with Image.open(outfile2) as im:
|
|
|
|
exif = im.getexif()
|
|
|
|
check_exif(exif)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_modify_exif(self, tmp_path: Path) -> None:
|
2022-05-27 00:54:54 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
with Image.open("Tests/images/ifd_tag_type.tiff") as im:
|
|
|
|
exif = im.getexif()
|
2023-12-29 06:15:40 +03:00
|
|
|
exif[264] = 100
|
2022-05-27 00:54:54 +03:00
|
|
|
|
|
|
|
im.save(outfile, exif=exif)
|
|
|
|
|
|
|
|
with Image.open(outfile) as im:
|
|
|
|
exif = im.getexif()
|
2023-12-29 06:15:40 +03:00
|
|
|
assert exif[264] == 100
|
2022-05-27 00:54:54 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_reload_exif_after_seek(self) -> None:
|
2022-05-27 00:54:54 +03:00
|
|
|
with Image.open("Tests/images/multipage.tiff") as im:
|
|
|
|
exif = im.getexif()
|
|
|
|
del exif[256]
|
|
|
|
im.seek(1)
|
|
|
|
|
|
|
|
assert 256 in exif
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_exif_frames(self) -> None:
|
2021-04-19 12:46:49 +03:00
|
|
|
# Test that EXIF data can change across frames
|
|
|
|
with Image.open("Tests/images/g4-multi.tiff") as im:
|
|
|
|
assert im.getexif()[273] == (328, 815)
|
|
|
|
|
|
|
|
im.seek(1)
|
|
|
|
assert im.getexif()[273] == (1408, 1907)
|
|
|
|
|
2021-08-06 16:50:52 +03:00
|
|
|
@pytest.mark.parametrize("mode", ("1", "L"))
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_photometric(self, mode: str, tmp_path: Path) -> None:
|
2021-08-05 16:27:08 +03:00
|
|
|
filename = str(tmp_path / "temp.tif")
|
2021-08-06 16:50:52 +03:00
|
|
|
im = hopper(mode)
|
2021-08-05 16:27:08 +03:00
|
|
|
im.save(filename, tiffinfo={262: 0})
|
|
|
|
with Image.open(filename) as reloaded:
|
|
|
|
assert reloaded.tag_v2[262] == 0
|
|
|
|
assert_image_equal(im, reloaded)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_seek(self) -> None:
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil136.tiff"
|
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:
|
|
|
|
im.seek(0)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.tell() == 0
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_seek_eof(self) -> None:
|
2014-10-01 17:50:33 +04:00
|
|
|
filename = "Tests/images/pil136.tiff"
|
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
|
|
|
assert im.tell() == 0
|
|
|
|
with pytest.raises(EOFError):
|
|
|
|
im.seek(-1)
|
|
|
|
with pytest.raises(EOFError):
|
|
|
|
im.seek(1)
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test__limit_rational_int(self) -> None:
|
2014-12-29 18:48:01 +03:00
|
|
|
from PIL.TiffImagePlugin import _limit_rational
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2014-07-27 23:18:42 +04:00
|
|
|
value = 34
|
2014-12-29 18:48:01 +03:00
|
|
|
ret = _limit_rational(value, 65536)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert ret == (34, 1)
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test__limit_rational_float(self) -> None:
|
2014-12-29 18:48:01 +03:00
|
|
|
from PIL.TiffImagePlugin import _limit_rational
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2014-07-27 23:18:42 +04:00
|
|
|
value = 22.3
|
2014-12-29 18:48:01 +03:00
|
|
|
ret = _limit_rational(value, 65536)
|
2020-02-22 16:06:21 +03:00
|
|
|
assert ret == (223, 10)
|
2014-07-27 23:18:42 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_4bit(self) -> None:
|
2014-10-02 11:43:22 +04:00
|
|
|
test_file = "Tests/images/hopper_gray_4bpp.tif"
|
2014-10-02 11:45:41 +04:00
|
|
|
original = hopper("L")
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(test_file) as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (128, 128)
|
|
|
|
assert im.mode == "L"
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(im, original, 7.3)
|
2014-10-02 11:43:22 +04:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_gray_semibyte_per_pixel(self) -> None:
|
2016-03-29 13:56:37 +03:00
|
|
|
test_files = (
|
|
|
|
(
|
2016-04-21 23:13:10 +03:00
|
|
|
24.8, # epsilon
|
|
|
|
( # group
|
2016-03-29 13:56:37 +03:00
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper2.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper2I.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper2R.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper2IR.tif",
|
2019-06-13 18:54:11 +03:00
|
|
|
),
|
2016-03-29 13:56:37 +03:00
|
|
|
),
|
|
|
|
(
|
2016-04-21 23:13:10 +03:00
|
|
|
7.3, # epsilon
|
|
|
|
( # group
|
2016-03-29 13:56:37 +03:00
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper4.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper4I.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper4R.tif",
|
|
|
|
"Tests/images/tiff_gray_2_4_bpp/hopper4IR.tif",
|
2019-06-13 18:54:11 +03:00
|
|
|
),
|
2016-03-29 13:56:37 +03:00
|
|
|
),
|
|
|
|
)
|
|
|
|
original = hopper("L")
|
|
|
|
for epsilon, group in test_files:
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(group[0]) as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.size == (128, 128)
|
|
|
|
assert im.mode == "L"
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_similar(im, original, epsilon)
|
2019-11-25 23:03:23 +03:00
|
|
|
for file in group[1:]:
|
|
|
|
with Image.open(file) as im2:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im2.size == (128, 128)
|
|
|
|
assert im2.mode == "L"
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal(im, im2)
|
2016-03-29 13:56:37 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_with_underscores(self, tmp_path: Path) -> None:
|
2019-06-13 18:54:11 +03:00
|
|
|
kwargs = {"resolution_unit": "inch", "x_resolution": 72, "y_resolution": 36}
|
2020-03-02 17:02:19 +03:00
|
|
|
filename = str(tmp_path / "temp.tif")
|
2014-12-28 17:30:12 +03:00
|
|
|
hopper("RGB").save(filename, **kwargs)
|
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:
|
|
|
|
# legacy interface
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.tag[X_RESOLUTION][0][0] == 72
|
|
|
|
assert im.tag[Y_RESOLUTION][0][0] == 36
|
2015-09-11 20:09: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
|
|
|
# v2 interface
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.tag_v2[X_RESOLUTION] == 72
|
|
|
|
assert im.tag_v2[Y_RESOLUTION] == 36
|
2014-12-28 17:30:12 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_roundtrip_tiff_uint16(self, tmp_path: Path) -> None:
|
2016-04-11 22:35:16 +03:00
|
|
|
# Test an image of all '0' values
|
|
|
|
pixel_value = 0x1234
|
2016-06-25 16:50:40 +03:00
|
|
|
infile = "Tests/images/uint16_1_4660.tif"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(infile) as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.getpixel((0, 0)) == pixel_value
|
2016-09-03 05:23:42 +03:00
|
|
|
|
2020-03-02 17:02:19 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
2019-11-25 23:03:23 +03:00
|
|
|
im.save(tmpfile)
|
2016-09-03 05:23:42 +03:00
|
|
|
|
2021-02-21 14:15:56 +03:00
|
|
|
assert_image_equal_tofile(im, tmpfile)
|
2016-09-03 05:23:42 +03:00
|
|
|
|
2024-04-06 12:59:06 +03:00
|
|
|
def test_iptc(self, tmp_path: Path) -> None:
|
|
|
|
# Do not preserve IPTC_NAA_CHUNK by default if type is LONG
|
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
im = hopper()
|
|
|
|
ifd = TiffImagePlugin.ImageFileDirectory_v2()
|
|
|
|
ifd[33723] = 1
|
|
|
|
ifd.tagtype[33723] = 4
|
|
|
|
im.tag_v2 = ifd
|
|
|
|
im.save(outfile)
|
|
|
|
|
|
|
|
with Image.open(outfile) as im:
|
|
|
|
assert 33723 not in im.tag_v2
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_rowsperstrip(self, tmp_path: Path) -> None:
|
2023-12-29 14:59:43 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
im = hopper()
|
|
|
|
im.save(outfile, tiffinfo={278: 256})
|
|
|
|
|
|
|
|
with Image.open(outfile) as im:
|
2024-03-02 05:12:17 +03:00
|
|
|
assert isinstance(im, TiffImagePlugin.TiffImageFile)
|
2023-12-29 14:59:43 +03:00
|
|
|
assert im.tag_v2[278] == 256
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_strip_raw(self) -> None:
|
2018-07-17 07:10:57 +03:00
|
|
|
infile = "Tests/images/tiff_strip_raw.tif"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(infile) as im:
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal_tofile(im, "Tests/images/tiff_adobe_deflate.png")
|
2018-07-17 07:10:57 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_strip_planar_raw(self) -> None:
|
2018-10-24 22:24:03 +03:00
|
|
|
# gdal_translate -of GTiff -co INTERLEAVE=BAND \
|
|
|
|
# tiff_strip_raw.tif tiff_strip_planar_raw.tiff
|
2018-07-17 20:27:11 +03:00
|
|
|
infile = "Tests/images/tiff_strip_planar_raw.tif"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(infile) as im:
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal_tofile(im, "Tests/images/tiff_adobe_deflate.png")
|
2018-07-17 20:27:11 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_strip_planar_raw_with_overviews(self) -> None:
|
2018-07-17 20:27:11 +03:00
|
|
|
# gdaladdo tiff_strip_planar_raw2.tif 2 4 8 16
|
|
|
|
infile = "Tests/images/tiff_strip_planar_raw_with_overviews.tif"
|
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(infile) as im:
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal_tofile(im, "Tests/images/tiff_adobe_deflate.png")
|
2018-07-17 20:27:11 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_tiled_planar_raw(self) -> None:
|
2018-10-24 22:24:03 +03:00
|
|
|
# gdal_translate -of GTiff -co TILED=YES -co BLOCKXSIZE=32 \
|
|
|
|
# -co BLOCKYSIZE=32 -co INTERLEAVE=BAND \
|
2018-07-17 20:27:11 +03:00
|
|
|
# tiff_tiled_raw.tif tiff_tiled_planar_raw.tiff
|
|
|
|
infile = "Tests/images/tiff_tiled_planar_raw.tif"
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(infile) as im:
|
2020-01-30 17:56:07 +03:00
|
|
|
assert_image_equal_tofile(im, "Tests/images/tiff_adobe_deflate.png")
|
2018-07-17 07:10:57 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_planar_configuration_save(self, tmp_path: Path) -> None:
|
2022-01-18 11:40:57 +03:00
|
|
|
infile = "Tests/images/tiff_tiled_planar_raw.tif"
|
|
|
|
with Image.open(infile) as im:
|
|
|
|
assert im._planar_configuration == 2
|
|
|
|
|
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
im.save(outfile)
|
|
|
|
|
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
assert_image_equal_tofile(reloaded, infile)
|
|
|
|
|
2022-10-03 08:57:42 +03:00
|
|
|
@pytest.mark.parametrize("mode", ("P", "PA"))
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_palette(self, mode: str, tmp_path: Path) -> None:
|
2022-10-03 08:57:42 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
2019-05-11 07:43:48 +03:00
|
|
|
|
2022-10-03 08:57:42 +03:00
|
|
|
im = hopper(mode)
|
|
|
|
im.save(outfile)
|
2019-05-11 07:43:48 +03:00
|
|
|
|
2022-10-03 08:57:42 +03:00
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
assert_image_equal(im.convert("RGB"), reloaded.convert("RGB"))
|
2020-03-04 13:33:00 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_tiff_save_all(self) -> None:
|
2019-10-07 16:28:36 +03:00
|
|
|
mp = BytesIO()
|
2016-09-29 04:16:04 +03:00
|
|
|
with Image.open("Tests/images/multipage.tiff") as im:
|
|
|
|
im.save(mp, format="tiff", save_all=True)
|
|
|
|
|
|
|
|
mp.seek(0, os.SEEK_SET)
|
|
|
|
with Image.open(mp) as im:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert im.n_frames == 3
|
2016-04-21 23:10:08 +03:00
|
|
|
|
Allow to save tiff stacks from separate images
This is a quick solution that will allow to save tiff stacks from
separate images, e.g. from Numpy arrays.
Previously, tiff stacks could be saved only from multiframe images.
This behavior is similar to what is possible now with GIFs.
Note however, that for correct results, all the appended images should
have the same encoder{info,config} properties.
Example:
import numpy as np
from PIL import Image
a = np.ones((100,100,100), dtype=np.uint8)
imlist = []
for m in a:
imlist.append(Image.fromarray(m))
imlist[0].save("test.tif", compression="tiff_deflate", save_all=True,
append_images=imlist[1:])
(Should result in a 100-frame, 100x100 tiff stack.)
Signed-off-by: Leonid Bloch <leonid.bloch@esrf.fr>
2017-02-16 03:54:43 +03:00
|
|
|
# Test appending images
|
2019-10-07 16:28:36 +03:00
|
|
|
mp = BytesIO()
|
2019-06-13 18:54:11 +03:00
|
|
|
im = Image.new("RGB", (100, 100), "#f00")
|
|
|
|
ims = [Image.new("RGB", (100, 100), color) for color in ["#0f0", "#00f"]]
|
2017-11-04 02:46:15 +03:00
|
|
|
im.copy().save(mp, format="TIFF", save_all=True, append_images=ims)
|
|
|
|
|
|
|
|
mp.seek(0, os.SEEK_SET)
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(mp) as reread:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert reread.n_frames == 3
|
2017-11-04 02:46:15 +03:00
|
|
|
|
|
|
|
# Test appending using a generator
|
2024-02-17 07:00:38 +03:00
|
|
|
def im_generator(ims: list[Image.Image]) -> Generator[Image.Image, None, None]:
|
2019-09-30 17:56:31 +03:00
|
|
|
yield from ims
|
2019-06-13 18:54:11 +03:00
|
|
|
|
2019-10-07 16:28:36 +03:00
|
|
|
mp = BytesIO()
|
2022-04-10 22:17:35 +03:00
|
|
|
im.save(mp, format="TIFF", save_all=True, append_images=im_generator(ims))
|
Allow to save tiff stacks from separate images
This is a quick solution that will allow to save tiff stacks from
separate images, e.g. from Numpy arrays.
Previously, tiff stacks could be saved only from multiframe images.
This behavior is similar to what is possible now with GIFs.
Note however, that for correct results, all the appended images should
have the same encoder{info,config} properties.
Example:
import numpy as np
from PIL import Image
a = np.ones((100,100,100), dtype=np.uint8)
imlist = []
for m in a:
imlist.append(Image.fromarray(m))
imlist[0].save("test.tif", compression="tiff_deflate", save_all=True,
append_images=imlist[1:])
(Should result in a 100-frame, 100x100 tiff stack.)
Signed-off-by: Leonid Bloch <leonid.bloch@esrf.fr>
2017-02-16 03:54:43 +03:00
|
|
|
|
|
|
|
mp.seek(0, os.SEEK_SET)
|
2019-11-25 23:03:23 +03:00
|
|
|
with Image.open(mp) as reread:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert reread.n_frames == 3
|
Allow to save tiff stacks from separate images
This is a quick solution that will allow to save tiff stacks from
separate images, e.g. from Numpy arrays.
Previously, tiff stacks could be saved only from multiframe images.
This behavior is similar to what is possible now with GIFs.
Note however, that for correct results, all the appended images should
have the same encoder{info,config} properties.
Example:
import numpy as np
from PIL import Image
a = np.ones((100,100,100), dtype=np.uint8)
imlist = []
for m in a:
imlist.append(Image.fromarray(m))
imlist[0].save("test.tif", compression="tiff_deflate", save_all=True,
append_images=imlist[1:])
(Should result in a 100-frame, 100x100 tiff stack.)
Signed-off-by: Leonid Bloch <leonid.bloch@esrf.fr>
2017-02-16 03:54:43 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_saving_icc_profile(self, tmp_path: Path) -> None:
|
2016-08-22 13:47:49 +03:00
|
|
|
# Tests saving TIFF with icc_profile set.
|
|
|
|
# At the time of writing this will only work for non-compressed tiffs
|
2017-05-27 23:55:14 +03:00
|
|
|
# as libtiff does not support embedded ICC profiles,
|
|
|
|
# ImageFile._save(..) however does.
|
2019-06-13 18:54:11 +03:00
|
|
|
im = Image.new("RGB", (1, 1))
|
|
|
|
im.info["icc_profile"] = "Dummy value"
|
2016-04-01 13:47:28 +03:00
|
|
|
|
2016-08-22 13:47:49 +03:00
|
|
|
# Try save-load round trip to make sure both handle icc_profile.
|
2020-03-02 17:02:19 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
2019-06-13 18:54:11 +03:00
|
|
|
im.save(tmpfile, "TIFF", compression="raw")
|
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(tmpfile) as reloaded:
|
2020-02-22 16:06:21 +03:00
|
|
|
assert b"Dummy value" == reloaded.info["icc_profile"]
|
2016-08-22 13:47:49 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_icc_profile(self, tmp_path: Path) -> None:
|
2021-03-10 12:16:49 +03:00
|
|
|
im = hopper()
|
|
|
|
assert "icc_profile" not in im.info
|
|
|
|
|
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
icc_profile = b"Dummy value"
|
|
|
|
im.save(outfile, icc_profile=icc_profile)
|
|
|
|
|
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
assert reloaded.info["icc_profile"] == icc_profile
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_save_bmp_compression(self, tmp_path: Path) -> None:
|
2022-04-21 00:58:12 +03:00
|
|
|
with Image.open("Tests/images/hopper.bmp") as im:
|
|
|
|
assert im.info["compression"] == 0
|
|
|
|
|
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
im.save(outfile)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_discard_icc_profile(self, tmp_path: Path) -> None:
|
2021-03-10 12:16:49 +03:00
|
|
|
outfile = str(tmp_path / "temp.tif")
|
|
|
|
|
|
|
|
with Image.open("Tests/images/icc_profile.png") as im:
|
|
|
|
assert "icc_profile" in im.info
|
|
|
|
|
|
|
|
im.save(outfile, icc_profile=None)
|
|
|
|
|
|
|
|
with Image.open(outfile) as reloaded:
|
|
|
|
assert "icc_profile" not in reloaded.info
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_getxmp(self) -> None:
|
2021-06-12 05:17:38 +03:00
|
|
|
with Image.open("Tests/images/lab.tif") as im:
|
2021-06-30 04:28:00 +03:00
|
|
|
if ElementTree is None:
|
2023-10-06 09:31:06 +03:00
|
|
|
with pytest.warns(
|
|
|
|
UserWarning,
|
|
|
|
match="XMP data cannot be read without defusedxml dependency",
|
|
|
|
):
|
2021-06-30 04:23:57 +03:00
|
|
|
assert im.getxmp() == {}
|
2021-06-30 04:28:00 +03:00
|
|
|
else:
|
2024-05-20 16:11:50 +03:00
|
|
|
assert "xmp" in im.info
|
2021-06-30 04:28:00 +03:00
|
|
|
xmp = im.getxmp()
|
|
|
|
|
|
|
|
description = xmp["xmpmeta"]["RDF"]["Description"]
|
|
|
|
assert description[0]["format"] == "image/tiff"
|
|
|
|
assert description[3]["BitsPerSample"]["Seq"]["li"] == ["8", "8", "8"]
|
2021-06-12 05:17:38 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_get_photoshop_blocks(self) -> None:
|
2022-02-10 04:00:23 +03:00
|
|
|
with Image.open("Tests/images/lab.tif") as im:
|
|
|
|
assert list(im.get_photoshop_blocks().keys()) == [
|
|
|
|
1061,
|
|
|
|
1002,
|
|
|
|
1005,
|
|
|
|
1062,
|
|
|
|
1037,
|
|
|
|
1049,
|
|
|
|
1011,
|
|
|
|
1034,
|
|
|
|
10000,
|
|
|
|
1013,
|
|
|
|
1016,
|
|
|
|
1032,
|
|
|
|
1054,
|
|
|
|
1050,
|
|
|
|
1064,
|
|
|
|
1041,
|
|
|
|
1044,
|
|
|
|
1036,
|
|
|
|
1057,
|
|
|
|
4000,
|
|
|
|
4001,
|
|
|
|
]
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_tiff_chunks(self, tmp_path: Path) -> None:
|
2023-12-29 06:15:40 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
|
|
|
|
|
|
|
im = hopper()
|
|
|
|
with open(tmpfile, "wb") as fp:
|
|
|
|
for y in range(0, 128, 32):
|
|
|
|
chunk = im.crop((0, y, 128, y + 32))
|
|
|
|
if y == 0:
|
|
|
|
chunk.save(
|
|
|
|
fp,
|
|
|
|
"TIFF",
|
|
|
|
tiffinfo={
|
|
|
|
TiffImagePlugin.IMAGEWIDTH: 128,
|
|
|
|
TiffImagePlugin.IMAGELENGTH: 128,
|
|
|
|
},
|
|
|
|
)
|
|
|
|
else:
|
|
|
|
fp.write(chunk.tobytes())
|
|
|
|
|
|
|
|
assert_image_equal_tofile(im, tmpfile)
|
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_close_on_load_exclusive(self, tmp_path: Path) -> None:
|
2017-04-04 10:27:20 +03:00
|
|
|
# similar to test_fd_leak, but runs on unixlike os
|
2020-03-02 17:02:19 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
2017-01-02 23:56:19 +03:00
|
|
|
|
|
|
|
with Image.open("Tests/images/uint16_1_4660.tif") as im:
|
|
|
|
im.save(tmpfile)
|
|
|
|
|
|
|
|
im = Image.open(tmpfile)
|
|
|
|
fp = im.fp
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not fp.closed
|
2017-01-02 23:56:19 +03:00
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert fp.closed
|
2017-01-02 23:56:19 +03:00
|
|
|
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_close_on_load_nonexclusive(self, tmp_path: Path) -> None:
|
2020-03-02 17:02:19 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
2017-05-27 21:55:42 +03:00
|
|
|
|
2017-04-04 10:27:20 +03:00
|
|
|
with Image.open("Tests/images/uint16_1_4660.tif") as im:
|
|
|
|
im.save(tmpfile)
|
|
|
|
|
2019-06-13 18:54:11 +03:00
|
|
|
with open(tmpfile, "rb") as f:
|
2017-08-26 03:20:30 +03:00
|
|
|
im = Image.open(f)
|
|
|
|
fp = im.fp
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not fp.closed
|
2017-08-26 03:20:30 +03:00
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not fp.closed
|
2017-04-04 10:27:20 +03:00
|
|
|
|
2019-11-02 10:10:55 +03:00
|
|
|
# Ignore this UserWarning which triggers for four tags:
|
|
|
|
# "Possibly corrupt EXIF data. Expecting to read 50404352 bytes but..."
|
|
|
|
@pytest.mark.filterwarnings("ignore:Possibly corrupt EXIF data")
|
2021-08-24 11:33:43 +03:00
|
|
|
# Ignore this UserWarning:
|
|
|
|
@pytest.mark.filterwarnings("ignore:Truncated File Read")
|
2020-10-19 13:32:56 +03:00
|
|
|
@pytest.mark.skipif(
|
|
|
|
not os.path.exists("Tests/images/string_dimension.tiff"),
|
|
|
|
reason="Extra image files not installed",
|
|
|
|
)
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_string_dimension(self) -> None:
|
2019-09-29 07:15:48 +03:00
|
|
|
# Assert that an error is raised if one of the dimensions is a string
|
2021-04-01 17:41:46 +03:00
|
|
|
with Image.open("Tests/images/string_dimension.tiff") as im:
|
|
|
|
with pytest.raises(OSError):
|
2021-03-07 21:04:25 +03:00
|
|
|
im.load()
|
|
|
|
|
2022-01-01 06:54:23 +03:00
|
|
|
@pytest.mark.timeout(6)
|
|
|
|
@pytest.mark.filterwarnings("ignore:Truncated File Read")
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_timeout(self) -> None:
|
2022-01-01 06:54:23 +03:00
|
|
|
with Image.open("Tests/images/timeout-6646305047838720") as im:
|
|
|
|
ImageFile.LOAD_TRUNCATED_IMAGES = True
|
|
|
|
im.load()
|
|
|
|
ImageFile.LOAD_TRUNCATED_IMAGES = False
|
|
|
|
|
2022-10-28 15:11:25 +03:00
|
|
|
@pytest.mark.parametrize(
|
|
|
|
"test_file",
|
|
|
|
[
|
|
|
|
"Tests/images/oom-225817ca0f8c663be7ab4b9e717b02c661e66834.tif",
|
|
|
|
],
|
|
|
|
)
|
|
|
|
@pytest.mark.timeout(2)
|
2024-02-17 07:00:38 +03:00
|
|
|
def test_oom(self, test_file: str) -> None:
|
2022-10-28 15:11:25 +03:00
|
|
|
with pytest.raises(UnidentifiedImageError):
|
2022-10-28 18:02:24 +03:00
|
|
|
with pytest.warns(UserWarning):
|
2022-10-28 18:03:38 +03:00
|
|
|
with Image.open(test_file):
|
2022-10-28 18:02:24 +03:00
|
|
|
pass
|
2022-10-28 15:11:25 +03:00
|
|
|
|
|
|
|
|
2020-03-02 17:02:19 +03:00
|
|
|
@pytest.mark.skipif(not is_win32(), reason="Windows only")
|
|
|
|
class TestFileTiffW32:
|
2024-01-31 12:12:58 +03:00
|
|
|
def test_fd_leak(self, tmp_path: Path) -> None:
|
2020-03-02 17:02:19 +03:00
|
|
|
tmpfile = str(tmp_path / "temp.tif")
|
2016-11-04 19:09:30 +03:00
|
|
|
|
2017-05-27 21:55:42 +03:00
|
|
|
# this is an mmaped file.
|
2016-11-04 19:09:30 +03:00
|
|
|
with Image.open("Tests/images/uint16_1_4660.tif") as im:
|
|
|
|
im.save(tmpfile)
|
|
|
|
|
|
|
|
im = Image.open(tmpfile)
|
2017-01-02 23:56:19 +03:00
|
|
|
fp = im.fp
|
2020-02-22 16:06:21 +03:00
|
|
|
assert not fp.closed
|
2020-04-07 09:58:21 +03:00
|
|
|
with pytest.raises(OSError):
|
2020-02-22 16:06:21 +03:00
|
|
|
os.remove(tmpfile)
|
2017-01-02 23:37:41 +03:00
|
|
|
im.load()
|
2020-02-22 16:06:21 +03:00
|
|
|
assert fp.closed
|
2017-04-03 18:05:56 +03:00
|
|
|
|
|
|
|
# this closes the mmap
|
|
|
|
im.close()
|
2017-05-27 21:55:42 +03:00
|
|
|
|
2017-04-03 18:05:56 +03:00
|
|
|
# this should not fail, as load should have closed the file pointer,
|
|
|
|
# and close should have closed the mmap
|
2016-11-04 19:09:30 +03:00
|
|
|
os.remove(tmpfile)
|