20,473
edits
Talk:OniSplit: Difference between revisions
reporting a pretty important bug, 18 years late
(signed unsigned posts, sorted topics by date of first message in descending order) |
(reporting a pretty important bug, 18 years late) |
||
| Line 1: | Line 1: | ||
Talk page archives: [[/Archive1|#1]] | Talk page archives: [[/Archive1|#1]] | ||
==Textures are darkened when extracted from formats with sub-8-bit channels== | |||
When OniSplit reads the game's textures in any format with <8-bit channel sizes, namely ARGB4444, RGB555 and ARGB1555, and expands the 4- or 5-bit R, G or B channel to 8 bits in response to the {{nbhy}}extract command, it is simply zero-padding the lower bits which results in an overall darkening of the image. The clearest way to see this is with TXMPDAODAN_SHIELD in level0, where all the pixel data in the original RGB555 format says "FF FF". That's meant to be pure white, right? Well when OniSplit extracts this to PNG, etc., it converts the value 11111 found in each channel to 11111000 or 0xF8, resulting in pixels of the color {248, 248, 248} which is a noticeably off-white color. No texture will be able to contain a brighter color than that using OniSplit's math where 11111 << 3 = 11111000. Looking at a histogram of any extracted texture should bear this out, but it's also something the naked eye can see pretty easily if there's bright colors in the image and you have an accurate reference version of the image being extracted. Apparently the community has been missing this ~3% darkening all these years? | |||
Standard practice in this situation is to use "bit replication" where the most significant bits are copied into the space left behind when a value is left-shifted, e.g. a 5-bit channel value 00101 becomes 00101001, not 00101000. This approach properly spreads out the resulting colors across the entire 0-255 range, allowing the 2-byte pixel value FF FF to become pure white while also preserving 00 00 as pure black. There is another scaling algorithm which is even more accurate but slower. | |||
I believe that any new/edited textures passed in through OniSplit will also experience slight darkening, but only if they are converted to one of the above formats with <8-bit channels. Extracted textures that were darkened by being converted to PNG, etc. will regain their brightness when imported back in with {{nbhy}}create because e.g. 11111000 simply goes back to 11111, and this will be displayed by Oni as full-white on a 32-bit display. This may be why no one noticed the issue before now, but probably the key reason is that modders prefer to create every texture in RGB888. But if a user imports an image using the {{nbhy}}format option to create the TXMP.oni in ARGB4444, RGB555 or ARGB1555, it looks like OniSplit will convert it with a downward bias: 0-7 → 0, 8-15 → 1, and finally 248-255 → 31 because it is simply performing a ">> 3" on the number. This is known to darken the image, so the standard practice is to use "rounded scaling" to create a center bias, which I won't detail here. Just wanted to make a note that if someone is fixing the 4-/5-bit → 8-bit conversion math for OniSplit, the math for converting 8-bit → 4-/5-bit should be looked at as well. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:50, 5 April 2026 (UTC) | |||
==Smaller version steps possible== | ==Smaller version steps possible== | ||