16-bit PNG tRNS key: convert("RGBA") misses the keyed pixel and makes another transparent
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 58/100
Hướng nghiên cứu
Start by reading the PNG decoder and transparency handling, then inspect the existing tests for 16-bit PNG and the related 2- and 4-bit gray case in #10320. Add regression coverage for 16-bit RGB and grayscale tRNS keys, checking that only matching pixels become transparent after convert("RGBA"). The issue provides a reproducer and expected alpha values; the fix is done when both cases behave as expected without breaking existing PNG tests.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What did you do?
I'm building an image-optimization tool that prepares screenshots and photos for PDFs: it picks the output format, carries the DPI so pages place at the right size, and checks that lossless steps keep every pixel. Its test suite generates each input type Pillow opens and runs it through the tool, which is where this came up. The tool reads transparency through convert("RGBA"), and on a 16-bit RGB PNG with a tRNS key the keyed pixels stayed opaque.
import io, struct, zlib
from PIL import Image
def png(width, depth, colour_type, row, trns):
def chunk(kind, data):
return struct.pack(">I", len(data)) + kind + data + struct.pack(">I", zlib.crc32(kind + data))
ihdr = struct.pack(">IIBBBBB", width, 1, depth, colour_type, 0, 0, 0)
return (b"\x89PNG\r\n\x1a\n" + chunk(b"IHDR", ihdr) + chunk(b"tRNS", trns)
+ chunk(b"IDAT", zlib.compress(b"\x00" + row)) + chunk(b"IEND", b""))
# 16-bit RGB: pixel 0 is the tRNS colour, pixel 1 is not
key = (0x1234, 0x5678, 0x9ABC)
row = struct.pack(">6H", *key, 0x3434, 0x7878, 0xBCBC)
with Image.open(io.BytesIO(png(2, 16, 2, row, struct.pack(">3H", *key)))) as im:
print(im.mode, im.info["transparency"], [im.getpixel((x, 0)) for x in range(2)])
print([im.convert("RGBA").getpixel((x, 0))[3] for x in range(2)])
# 16-bit greyscale: pixel 0 is the tRNS grey level, pixel 1 is not
row = struct.pack(">2H", 0x1234, 0x0034)
with Image.open(io.BytesIO(png(2, 16, 0, row, struct.pack(">H", 0x1234)))) as im:
print(im.mode, im.info["transparency"], [im.getpixel((x, 0)) for x in range(2)])
print([im.convert("RGBA").getpixel((x, 0))[3] for x in range(2)])
What did you expect to happen?
Alpha [0, 255] in both cases: the pixel equal to the tRNS value is transparent and the other is opaque, as for 8-bit files.
What actually happened?
RGB (4660, 22136, 39612) [(18, 86, 154), (52, 120, 188)]
[255, 0]
I;16 4660 [4660, 52]
[255, 0]
The keyed pixel stays opaque, and the pixel whose 8-bit value equals the key's low byte (0x34, 0x78, 0xBC) becomes transparent. 16-bit RGB opens as 8-bit RGB while info["transparency"] keeps the 16-bit tuple. #10320 covers the 2- and 4-bit gray case; this is the 16-bit one, and I'm not asking for 16-bit RGB support (#1888).
Related: #10329 (16-bit APNG frames merged on save).
What are your OS, Python and Pillow versions?
- OS: Ubuntu 24.04 (Linux x86_64)
- Python: 3.13.13
- Pillow: 13.0.0 (also reproduces on 12.3.0)
--------------------------------------------------------------------
Pillow 13.0.0
Python 3.13.13 (main, May 10 2026, 19:26:54) [Clang 22.1.3 ]
--------------------------------------------------------------------
Python executable is ~/.venv/bin/python
Environment Python files loaded from ~/.venv
System Python files loaded from ~/.local/share/uv/python/cpython-3.13.13-linux-x86_64-gnu
--------------------------------------------------------------------
Python Pillow modules loaded from ~/.venv/lib/python3.13/site-packages/PIL
Binary Pillow modules loaded from ~/.venv/lib/python3.13/site-packages/PIL
--------------------------------------------------------------------
--- PIL CORE support ok, compiled for 13.0.0
--- TKINTER support ok, loaded 9.0
--- FREETYPE2 support ok, loaded 2.14.3
--- LITTLECMS2 support ok, loaded 2.19
--- WEBP support ok, loaded 1.6.0
--- AVIF support ok, loaded 1.4.2
--- JPEG support ok, compiled for libjpeg-turbo 3.2.0
--- OPENJPEG (JPEG2000) support ok, loaded 2.5.4
--- ZLIB (PNG/ZIP) support ok, loaded 1.3, compiled for zlib-ng 2.3.3
--- LIBTIFF support ok, loaded 4.7.2
--- RAQM (Bidirectional Text) support ok, loaded 0.11.0, fribidi 1.0.13, harfbuzz 14.5.0
*** LIBIMAGEQUANT (Quantization method) support not installed
--- XCB (X protocol) support ok
--------------------------------------------------------------------
- Ngôn ngữ chính
- Python
- Star
- 13.9k
- Fork
- 2.6k
- Merge trung bình
- 1 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 173
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của python-pillow/Pillow
-
Warn that pre-applying arabic_reshaper + python-bidi corrupts text on a Raqm buildCó thể đã có người làm @Syamjith-NK đã nhận 61 ngày trước. Đang mởDocumentation Font Rendering PNG Third Party Framework
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
python-pillow/Pillow#9907 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Image.putpixel incorrectly labels supported arguments in type annotationsCó thể đã có người làm @radarhere đã nhận 189 ngày trước. Đang mởPNG
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
python-pillow/Pillow#9584 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`ImageDraw.arc()` segfaults on a tuple subclass whose `__len__` is too largeCó thể đã có người làm @Parsiffall1 đã nhận hôm nay. Đang mở
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 58/100
python-pillow/Pillow#10358 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
JPEG saved with keep_rgb=True and dpi reopens with incorrect colorsCó thể đã có người làm @Muguett-DBY đã nhận 1 ngày trước. Đang mở🤖-assisted JPEG
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 25/100
python-pillow/Pillow#10344 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
JPEG dpi read from EXIF uses XResolution for both axesCó thể đã có người làm @unvisible789 đã nhận 3 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 20/100
python-pillow/Pillow#10331 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của python-pillow/Pillow
Issue tương tự
-
changelog investigate
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
ramnes/notion-sdk-py#433 ·
-
docs pkg:core
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 84/100
pydantic/pydantic-ai#11929 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
intake/intake-esm#789 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
MemMachine/MemMachine#1877 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
openedx/openedx-authz#579 ·
Maintainer thường phản hồi trong vòng 1 ngày