Fix plJPEG image channels order #127
Conversation
|
This one probably needs updates in PlasmaShop as well, for JPEG rendering and also JPEG decal alpha masking. |
|
That should be handled by H-uru/PlasmaShop#44 |
|
We've had to explain why certain mipmaps have the blue/red channels reversed when viewed in PRPShop on the OU discord. Perhaps it is time to revisit this and H-uru/PlasmaShop#44, and @Deledrius's successor H-uru/PlasmaShop#69? |
| @@ -189,6 +189,15 @@ void plJPEG::DecompressJPEG(hsStream* S, void* buf, size_t size) { | |||
| offs += out_stride; | |||
| } | |||
|
|
|||
| // Data stored as RGB on disk but Plasma uses BGR | |||
| uint32_t* dp = reinterpret_cast<uint32_t*>(buf); | |||
There was a problem hiding this comment.
As in the PlasmaShop PR, we should probably add an assert to ensure the buf is properly aligned for the cast...
There was a problem hiding this comment.
libHSPlasma doesn't seem to have a standard assertion macro like Plasma does, so I added a throw hsBadParamException if the alignment doesn't smell right.
Yeah, this fix has been ready for years now. :( |
Plasma's plMipmaps store image data in BGR(A) for all uncompressed image types. However, JPEGs are stored as RGB on disk, so we must flip the channels for images that we read in. RLE images are unaffected because they operate on the pixel level.
Co-authored-by: Michael Hansen <[email protected]>
|
Ugh, MSVC 2013 doesn't support |
Plasma's plMipmaps store image data in BGR(A) for all uncompressed image types. However, JPEGs are stored as RGB on disk, so we must flip the channels for images that we read in. RLE images are unaffected because they operate on the pixel level. Indeed, the previous behavior would be inconsistent in that Cyan's lossy JPEG mipmaps would appear in RGB while Cyan's RLE mipmaps would appear in BGR.