You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I've been looking around at some PNG decoders and I think I've found a small bug in your iCCP chunk handling.
What did you expect to happen?
I would expect the library to read the iCCP chunk compression version byte correctly.
What actually happened?
This library incorrectly assumes that the NUL terminator is the compression byte. This does not cause issues in practice, since the compression byte should currently always be 0, but I thought I'd report this anyways.
The first one is a normal image with an embedded icc profile. The second is the same image, modified in a hex editor to change the compression version field from 0 to 1.
Here is the output from the first image:
DEBUG:PIL.PngImagePlugin:STREAM b'IHDR' 16 13
DEBUG:PIL.PngImagePlugin:STREAM b'iCCP' 41 460
DEBUG:PIL.PngImagePlugin:iCCP profile name b'Swapped red & green channel'
DEBUG:PIL.PngImagePlugin:Compression method 0
DEBUG:PIL.PngImagePlugin:STREAM b'PLTE' 513 759
DEBUG:PIL.PngImagePlugin:STREAM b'IDAT' 1284 3618
b'\x00\x00\x02\x84lcms\x02@\x00\x00mntrRGB XYZ \x07\xd5\x00\x08\x00\r\x00\x16\x00!\x00,acspSUNW\x00\x00\x00\x00none\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf6\xd6\x00\x01\x00\x00\x00\x00\xd3-Greg^\xdf\x16\x9a"\xbb\xfd\xab\xb6@n\xf998\rz\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ndesc\x00\x00\x00\xfc\x00\x00\x00\x84cprt\x00\x00\x01\x80\x00\x00\x00\x90wtpt\x00\x00\x02\x10\x00\x00\x00\x14bkpt\x00\x00\x02$\x00\x00\x00\x14rXYZ\x00\x00\x028\x00\x00\x00\x14gXYZ\x00\x00\x02L\x00\x00\x00\x14bXYZ\x00\x00\x02`\x00\x00\x00\x14rTRC\x00\x00\x02t\x00\x00\x00\x0egTRC\x00\x00\x02t\x00\x00\x00\x0ebTRC\x00\x00\x02t\x00\x00\x00\x0edesc\x00\x00\x00\x00\x00\x00\x00\'"sGRB": red and green channels swapped\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0067 bytes of wasted space, courtesy of Apple Computer, dum de dum.\x00\x00text\x00\x00\x00\x00Copyright 2005 Greg Roelofs. Licensed under Creative Commons Attribution-NonCommercial, http://creativecommons.org/licenses/by-nc/2.5/ \x00XYZ \x00\x00\x00\x00\x00\x00\xf3Q\x00\x01\x00\x00\x00\x01\x16\xccXYZ \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00XYZ \x00\x00\x00\x00\x00\x00b\x98\x00\x00\xb7\x86\x00\x00\x18\xdaXYZ \x00\x00\x00\x00\x00\x00o\xa1\x00\x008\xf5\x00\x00\x03\x90XYZ \x00\x00\x00\x00\x00\x00$\xa0\x00\x00\x0f\x84\x00\x00\xb6\xc9curv\x00\x00\x00\x00\x00\x00\x00\x01\x023\x00\x00'
<PIL.PngImagePlugin.PngImageFile image mode=P size=64x64 at 0x26C30640E10>
As can be seen, PIL thinks the compression byte never changes. The issue is here, where there is an off-by-one error. s[i] should be s[i + 1] for the compression byte.
The text was updated successfully, but these errors were encountered:
radarhere
changed the title
PNG iCCP Chunk Profile Compression Type Verification Seems Wrong
PNG iCCP chunk profile compression type verification seems wrong
Feb 20, 2024
What did you do?
Hello, I've been looking around at some PNG decoders and I think I've found a small bug in your iCCP chunk handling.
What did you expect to happen?
I would expect the library to read the iCCP chunk compression version byte correctly.
What actually happened?
This library incorrectly assumes that the NUL terminator is the compression byte. This does not cause issues in practice, since the compression byte should currently always be 0, but I thought I'd report this anyways.
What are your OS, Python and Pillow versions?
Here are my 2 test files:
The first one is a normal image with an embedded icc profile. The second is the same image, modified in a hex editor to change the compression version field from 0 to 1.
Here is the output from the first image:
Here is the output from the second image:
As can be seen, PIL thinks the compression byte never changes. The issue is here, where there is an off-by-one error.
s[i]
should bes[i + 1]
for the compression byte.The text was updated successfully, but these errors were encountered: