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
{{ message }}
Repository navigation
Unable to open DDS image: Unimplemented pixel format #7423
I'm guessing the version of DDS that I am attempting to render is not supported solely based off of the error message. I am passing byte data and not the files themselves, but am unsure of how else to get this to render. Attempted to use Pillow, but no luck.
"b'\x00\x00\x00\x00'" is not what I expect for a pixel format. Is there a program you know of that can view the file successfully? Does that program list any information about what the pixel format is? I'm expecting a short string starting with DXT, ATI or BC.
In having no idea what I'm doing, I came across where PIL is reading the fourcc value and updated where it's checking the dds file to each of the supported values (DXT1, DXT3, DXT5, ATI1, ATI2, BC5S, DX10) just in case the original image had left off this data or something.
Thinking that maybe GIMP/paint.net didn't care, but PIL does. GIMP and paint.net render the correct image for all of the different fourcc values, except for DX10 - which doesn't open correctly.
PIL renders an image when I use any of the above values (except for DX10), but it's just noise.
This is a different dds file, but the exact same format:
Expected (in GIMP):
PIL (using DXT1 and rendered in my GUI. All formats show some variation of this):
My guess is PIL just doesn't support this DDS format.
I've realised that the spec describing the pixel format flags states that DDPF_FOURCC indicates that "dwFourCC contains valid data" - the image does not have this flag in pfflags, and this explains why fourcc is empty.
I guessed that the file structure is the header, followed by 1024 palette bytes, followed by the indexes to the palette, and created PR #7426. For your image,
Which matches what I see in GIMP for that DDS file (although GIMP has a black background instead of a transparent one).
This DDS file is used in a video game
Presumably this means the image can't be included in our test suite and distributed under the Pillow license. Instead I've manually put together a file with the same structure.
Thanks radar - I really appreciate you digging into this. That is the correct image. GIMP renders it with a black background, while paint.net renders it with a transparent one (transparent should be correct).
Presumably this means the image can't be included in our test suite and distributed under the Pillow license. Instead I've manually put together a file with the same structure.
Yes, this is correct. I do not own the rights to this image.
I just tried to apply your PR as a patch in my virtual environment, but when trying to run the same script above, I am now seeing this error:
Activity
radarhere commentedon Sep 26, 2023
How was the DDS image file created?
"b'\x00\x00\x00\x00'" is not what I expect for a pixel format. Is there a program you know of that can view the file successfully? Does that program list any information about what the pixel format is? I'm expecting a short string starting with DXT, ATI or BC.
jmctune commentedon Sep 26, 2023
Hello and thanks for commenting so quickly.
This DDS file is used in a video game and dumped directly from its archive. I'm attempting to read and render the image in a GUI.
This image opens in both GIMP and paint.net correctly. In GIMP, I see the following:
Hopefully this provides the answer you're looking for, but please let me know if I can provide more.
jmctune commentedon Sep 26, 2023
In having no idea what I'm doing, I came across where PIL is reading the
fourccvalue and updated where it's checking the dds file to each of the supported values (DXT1, DXT3, DXT5, ATI1, ATI2, BC5S, DX10) just in case the original image had left off this data or something.Thinking that maybe GIMP/paint.net didn't care, but PIL does. GIMP and paint.net render the correct image for all of the different
fourccvalues, except for DX10 - which doesn't open correctly.PIL renders an image when I use any of the above values (except for DX10), but it's just noise.
This is a different dds file, but the exact same format:
Expected (in GIMP):

PIL (using DXT1 and rendered in my GUI. All formats show some variation of this):

My guess is PIL just doesn't support this DDS format.
radarhere commentedon Sep 27, 2023
I've realised that the spec describing the pixel format flags states that DDPF_FOURCC indicates that "dwFourCC contains valid data" - the image does not have this flag in
pfflags, and this explains whyfourccis empty.pfflagsinstead lines up withPillow/src/PIL/DdsImagePlugin.py
Line 50 in b723e9e
meaning there is palette data in the image. Gimp agrees with this, telling me in the "Image" menu that the "Image" "Mode" is "Indexed..."
DDPF_PALETTEINDEXED8 is not mentioned in the latest spec, but is mentioned in https://learn.microsoft.com/en-us/previous-versions/ms783269(v=vs.85). I guess this file is something that Microsoft has removed official support for.
radarhere commentedon Sep 27, 2023
I guessed that the file structure is the header, followed by 1024 palette bytes, followed by the indexes to the palette, and created PR #7426. For your image,
now gives

Which matches what I see in GIMP for that DDS file (although GIMP has a black background instead of a transparent one).
Presumably this means the image can't be included in our test suite and distributed under the Pillow license. Instead I've manually put together a file with the same structure.
jmctune commentedon Sep 27, 2023
Thanks radar - I really appreciate you digging into this. That is the correct image. GIMP renders it with a black background, while paint.net renders it with a transparent one (transparent should be correct).
Yes, this is correct. I do not own the rights to this image.
I just tried to apply your PR as a patch in my virtual environment, but when trying to run the same script above, I am now seeing this error:
I ran the same script you used above:
Does something have to be done differently to verify this? I double-checked that the patch did indeed apply correctly:
Without the patch, I see the same error as before (Unimplemented pixel format..).
radarhere commentedon Sep 27, 2023
My PR takes #7307 into consideration, which hasn't been released yet.
Just change
self._mode = "P"toself.mode = "P", removing the underscore.jmctune commentedon Sep 27, 2023
Worked like a charm! Thanks again!