imageio: Can not imwrite a JPG with e.g. ".part" suffix

@FirefoxMetzger Hey, in 2.11.0 and later, I can not write a JPG with a “.part” suffix. This is with current master:

(testenv) estan@edison:~$ python3 -c 'from imageio import imwrite; imwrite("/tmp/a.jpg.part", [[[1,1,1]]], format="jpg")'
Traceback (most recent call last):
  File "/home/estan/imageio/imageio/core/imopen.py", line 188, in imopen
    return loader(request, **kwargs)
  File "/home/estan/imageio/imageio/core/imopen.py", line 177, in loader
    return config.plugin_class(request, **kwargs)
  File "/home/estan/imageio/imageio/config/plugins.py", line 108, in partial_legacy_plugin
    return LegacyPlugin(request, legacy_plugin)
  File "/home/estan/imageio/imageio/core/legacy_plugin_wrapper.py", line 74, in __init__
    raise InitializationError(
imageio.core.request.InitializationError: `JPEG-PIL` can not write to `/tmp/a.jpg.part`.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/estan/imageio/imageio/v2.py", line 195, in imwrite
    with imopen(uri, "wi", plugin=format) as file:
  File "/home/estan/imageio/imageio/core/imopen.py", line 206, in imopen
    raise err_type(err_msg) from err_from
RuntimeError: `jpg` can not handle the given uri.
(testenv) estan@edison:~$

This used to work fine with 2.10.5 and earlier versions.

If I pass format="jpg" to imwrite then I expect it to not care about the output file suffix.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16 (12 by maintainers)

Most upvoted comments

@almarklein In this case, how about calling it extension as in

"""
extension : str
    Treat the provided ImageResource as if it had the given extension. This
    affects the order in which backends are considered, and when
    writing this may also influence the format used when encoding.
"""

My main concern about format is that the name is easily misunderstood as dictating the format. This would only be true when writing with backends that support more than one format (so far they all decide the encoder to use based on the extension), but would be false for backends that support only one format (they simply write that format regardless of extension). It would also be false when reading anything (backends check the file header and ignore the extension). A name like extension or ignore_extension=False would be more explicit and avoid this false perception.

FirefoxMetzger on Apr 22, 2022

Hm, what do you guys think of deprecating format_hint and replacing it with format that would always be authoritative?

Plus one for me!

Some thoughts: we might also consider a different approach for reading and writing. When writing a file, the user defines what to write. This is the extension by default, but indeed specifying a format should use that given format, i.e. by authoritative.

For reading, it’s different, because the file is already in a specific format. We have mechanics in place to try and auto-detect the format, but need a way for the user to specify the format when it fails. A (non-athorative) hint seems nice, but what if it’s ignored (imageio keeps using the extension) and it still fails? There is more room for discussion here, but I think it should be authoritative for reading as well …

almarklein on Apr 11, 2022

Hm, what do you guys think of deprecating format_hint and replacing it with format that would always be authoritative? So if you specify format=".jpg" when writing, it will write a jpg to the resource regardless of extension. Similarly when you specify format=".jpg" when reading it will try to read the resource as jpg regardless of file header or extension. Would that be intuitive?

FirefoxMetzger on Apr 11, 2022