Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image.putalpha should handle 16/32-bit to RGBA conversion #4926

Closed
bertsky opened this issue Sep 16, 2020 · 5 comments
Closed

Image.putalpha should handle 16/32-bit to RGBA conversion #4926

bertsky opened this issue Sep 16, 2020 · 5 comments

Comments

@bertsky
Copy link

bertsky commented Sep 16, 2020

This is similar to #2705 (which covered P→PA conversion):

IMHO images in 16-bit (I;16) or 32-bit (I / F) modes should be automatically converted to RGBA when putalpha is attempted on them.

Current (7.2.0) behaviour:

>>> img = PIL.Image.new('F', (200,100), 1.0)
>>> img.putalpha(PIL.Image.new('L', (200,100), 255))
Traceback (most recent call last):
  File "/lib/python3.6/site-packages/PIL/Image.py", line 1627, in putalpha
    self.im.setmode(mode)
ValueError: image has wrong mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/lib/python3.6/site-packages/PIL/Image.py", line 1630, in putalpha
    im = self.im.convert(mode)
ValueError: conversion from F to LA not supported

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

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/lib/python3.6/site-packages/PIL/Image.py", line 1637, in putalpha
    raise ValueError("illegal image mode") from e
ValueError: illegal image mode

If this is too difficult or unwise for other reasons (like quantization), then at least the documentation should state which base modes are supported.

In the very least, the above ugly multi-catch error message should be avoided.

@wiredfool
Copy link
Member

I don't agree that there should be an automatic conversion, as we currently don't do implicit conversions that would lose data, which would be the case going from I;16 or F to an 8 bit image format.

The multiple errors are something that should probably be cleaned up though.

@bertsky
Copy link
Author

bertsky commented Oct 22, 2020

I don't agree that there should be an automatic conversion, as we currently don't do implicit conversions that would lose data, which would be the case going from I;16 or F to an 8 bit image format.

Not necessarily – 16-bit grayscale content could well be preserved in a 24-bit color image without too much loss in precision. But I agree that it would be unexpected (and need some form of color management to get back to an equivalent luminance in the end).

And since reporting this, I have also learned that Pillow does not even convert correctly (loosing only precision), but clips off the significant part of the dynamic range – without warning. See:

Given that, I am actually glad Pillow does raise an exception here at least.

@radarhere
Copy link
Member

I've created #5090 to reduce the chain from three errors to two.

@radarhere
Copy link
Member

That PR has now been merged.

So the exception would now be

>>> from PIL import Image
>>> img = Image.new('F', (200,100), 1.0)
>>> img.putalpha(Image.new('L', (200,100), 255))
Traceback (most recent call last):
  File "PIL/Image.py", line 1620, in putalpha
ValueError: image has wrong mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "PIL/Image.py", line 1623, in putalpha
ValueError: conversion from F to LA not supported

Is that enough to resolve this?

@bertsky
Copy link
Author

bertsky commented Dec 29, 2020

Thanks @radarhere!

Yes, I guess we can close – as long as the other conversion-related issues are not resolved, it does not make sense attempting anything out of the ordinary here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants