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

Added reading DDS BGR;15 images #7574

Closed
wants to merge 2 commits into from

Conversation

radarhere
Copy link
Member

Resolves #7517

The issue found a DDS image with masks that mean the image is BGR;15.

I've created a test image using a modified Pillow.

self._mode = "RGB"
rawmode += masks[0xFF0000] + masks[0xFF00] + masks[0xFF]
if masks[:3] == (31744, 992, 31) and self.mode == "RGB":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The magic numbers here could use some explanation if you ask me.

Copy link
Member Author

@radarhere radarhere Nov 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know what you're said sounds like a perfectly straightforward request, but I can't think of a short way to explain it that isn't just explaining what masks are, or what BGR;15 is.

There are 4 bit masks - https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-pixelformat - R, G, B and A.

Each mask filters the pixel values to transform them into the value for each channel.

These masks are filtering 5 bits for R, 5 bits for G and 5 bits for B - BGR;15.

31744 = 0b0111110000000000
  992 = 0b0000001111100000
   31 = 0b0000000000011111

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks like great material for a code comment right there :)

You could also replace the decimal constants with those binary constants – then it's immediately more clear for a reader.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clearer, yes, it just feels verbose... I've pushed a commit.

if masks[:3] == (31744, 992, 31) and self.mode == "RGB":
rawmode = "BGR;15"
else:
masks = {mask: ["R", "G", "B", "A"][i] for i, mask in enumerate(masks)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
masks = {mask: ["R", "G", "B", "A"][i] for i, mask in enumerate(masks)}
masks = {mask: "RGBA"[i] for i, mask in enumerate(masks)}

would be more efficient, since the (possibly-mutable-but-the-interpreter-can't-tell) list doesn't need to regenerated for every call of this function, but it could use the same "RGBA" string constant used just below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a version of this.

# Each channel is derived using a mask of the pixel values
masks = {
mask: "RGB"[i]
for i, mask in enumerate(struct.unpack("<3I", header.read(12)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous version always read 16 bytes for masks – this will now read either 12 or 16 bytes. That seems odd?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't always necessary to read the last 4 bytes, and therefore seems more efficient to not do so where possible.

If you are concerned about the file pointer position, that's not relevant, as it is just reading from

header = BytesIO(header_bytes)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would actually be more efficient and clearer to not do another read-and-struct-unpack? (Would also mean that the entire DDS_PIXELFORMAT is always consumed.)

Comment on lines +163 to +168
rawmode = (
masks[0b0000000000011111]
+ masks[0b0000001111100000]
+ masks[0b0111110000000000]
+ ";15"
)
Copy link
Contributor

@akx akx Nov 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this now support esoteric formats like GRB;15 (and if so, will everything be handled correctly down the line)? If not, then I think just "RGB;15" would be better?

EDIT: right, the whole point here was BGR;15 – my bad, too little coffee.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will support RGB;15 and BGR;15

Pillow/src/libImaging/Unpack.c

Lines 1576 to 1577 in 697c24b

{"RGB", "RGB;15", 16, ImagingUnpackRGB15},
{"RGB", "BGR;15", 16, ImagingUnpackBGR15},

for i, mask in enumerate(struct.unpack("<3I", header.read(12)))
}
if self.mode == "RGB" and all(
mask in (0b0000000000011111, 0b0000001111100000, 0b0111110000000000)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This did become less clear to read, you're right. Wonder if these and the 0xFF0000 masks from below could benefit from becoming constants á la (I didn't double check whether I have RGB/BGR right here):

R_MASK_555 = 0b0000000000011111
G_MASK_555 = 0b000001111100000
B_MASK_555 = 0b111110000000000
R_MASK_888 = 0x000000FF
G_MASK_888 = 0x0000FF00
B_MASK_888 = 0x00FF0000
A_MASK_888 = 0xFF000000

# Try 8 bits for each mask
if self.mode == "RGBA":
# The fourth mask, alpha,
# is only valid when the correct flags are present
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the correct flags?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-pixelformat seems inconsistent on this to me

DDPF_ALPHAPIXELS | Texture contains alpha data; dwRGBAlphaBitMask contains valid data.

Alpha mask for reading alpha data. dwFlags must include DDPF_ALPHAPIXELS or DDPF_ALPHA

The code is checking for DDPF_ALPHAPIXELS

if not pfflags & DDPF_ALPHAPIXELS:

+ ";15"
)
else:
# Try 8 bits for each mask
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the trying here? Rather, what happens if trying fails?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the issue related to this issue has found 5 bit masks, it seems possible that there could be other mask values used in files, beyond 5 bit and 8 bits.

If it fails, an error is raised, and ultimately an UnidentifiedImageError.

Copy link
Contributor

@akx akx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple comment suggestions based on the discussion, to make this clearer for future Pillow archaeologists without having to look at PRs :)

+ ";15"
)
else:
# Try 8 bits for each mask
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Try 8 bits for each mask
# Assume 8 bits for each mask

# Try 8 bits for each mask
if self.mode == "RGBA":
# The fourth mask, alpha,
# is only valid when the correct flags are present
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# is only valid when the correct flags are present
# is only valid when `pfflags & DDPF_ALPHAPIXELS`

@radarhere
Copy link
Member Author

My initial version of this was PR just added support for the specific scenario of the issue.

However, the second version with more explanation of how the code works makes it clear that this solution is incomplete, so I'm closing this in favour of a complete solution in #7589

@radarhere radarhere closed this Nov 30, 2023
@radarhere radarhere deleted the dds_bgr15 branch November 30, 2023 10:37
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

Successfully merging this pull request may close these issues.

PIL.UnidentifiedImageError: cannot identify image file (DDS file)
2 participants