Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

JPEG saved with keep_rgb=True and dpi reopens with incorrect colors

Đang mở
  • Có gì không ổn?
#10,344 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Muguett-DBY đang làm issue này rồi.

Từ ngày 28/10/2026.

  • #10345 của @Muguett-DBY — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
c, python
Lĩnh vực
backend

Hướng nghiên cứu

Start with the JPEG encoder path in src/libImaging/JpegEncode.c and the decoder’s color-space selection; the issue links both relevant code locations and cites libjpeg-turbo’s default selection. Compare JPEGs saved with and without DPI and keep_rgb=True, then run the reproducer in the issue. Done means both files reopen with approximately red pixels while retaining the requested DPI behavior; pull request #10345 is already open.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

🤖-assisted JPEG
What did you do?

Saved the same RGB image to JPEG with keep_rgb=True, once with DPI and once without it, then reopened both files:

from io import BytesIO

from PIL import Image

image = Image.new("RGB", (16, 16), (255, 0, 0))
for dpi in (None, (72, 72)):
    out = BytesIO()
    options = {"keep_rgb": True, "quality": 100, "subsampling": 0}
    if dpi is not None:
        options["dpi"] = dpi
    image.save(out, "JPEG", **options)
    out.seek(0)
    with Image.open(out) as reopened:
        print(dpi, reopened.getpixel((0, 0)))
What did you expect to happen?

Both images should reopen approximately red. Setting DPI should not visibly change the colors.

What actually happened?

On both installations below, the output was:

None (255, 0, 0)
(72, 72) (76, 255, 28)

The DPI version contains both a JFIF APP0 marker and an Adobe APP14 marker with transform 0; the version without DPI contains only the Adobe marker. As a diagnostic, removing the JFIF marker from the generated bytes made Pillow reopen the pixel as (255, 0, 0), but also removed the DPI. I don't know whether the right fix is in the writer, the reader, or both.

FFmpeg 9.0.2 decodes both generated JPEGs as (255, 0, 0) on the same machine. This suggests a difference in decoding the DPI version; I have not isolated the responsible layer.

The generated file has component IDs R, G and B. As a diagnostic, forcing the low-level JPEG decoder input mode to RGB also restores the expected red in both Pillow versions.

Looking at libjpeg-turbo 3.2.0, its default color-space selection gives the JFIF marker precedence over Adobe APP14, selecting YCbCr when both are present. Pillow enables JFIF when both DPI values are positive.

#7679 notes that setting DPI forces JFIF even for non-JFIF color spaces. The JPEG encoder source is identical between the 13.0.0 tag and current main, although I haven't built main to reproduce this there.

What are your OS, Python and Pillow versions?
  • Windows 11, Python 3.15.2, Pillow 13.0.0, libjpeg-turbo 3.2.0.
  • Also reproduced with Python 3.12.14, Pillow 12.3.0, libjpeg-turbo 3.1.4.1.

Reproducer and investigation assisted by Codex.

Ngôn ngữ chính
Python
Star
13.9k
Fork
2.6k
Merge trung bình
1 ngày 7 giờ
Pull request đã merge (30 ngày)
174

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của python-pillow/Pillow

Tất cả issue của python-pillow/Pillow

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.