Replies: 4 comments
-
Beta Was this translation helpful? Give feedback.
-
|
New issue #1723 |
Beta Was this translation helpful? Give feedback.
-
|
I see why we're using (I suppose for non-HDR images the "full dynamic range" would be the same as 0-255 for each channel, just converted to a |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see what you're getting at. Yes, if the original image is a 16-bit or a floating-point image, then you could technical drop some precision on image load. I don't think it's worth worrying about, as most texture images will be regular 8-bit. In our specific use, we have a JPG image, which is already lossy to begin with. Given that, I think it makes sense just to keep things as they are. Still, dropping the round-trip conversion in your own implementation doesn't sound like a bad idea at all. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I was working through the 2nd book, section 4.5, and I noticed that the
rtw_imageclass is usingstbi_loadfto load the image pixel data intofloats, and converts them tounsigned chars in theconvert_to_byesfunction by multiplying them by 256, and then in theimage_textureclass, it converts thoseunsigned chars todoubles by dividing them by 255. This seems like unnecessary work. Is there a reason it's done this way?Also, it keeps around both copies of the pixel data, despite only using the
unsigned int bdataarray after construction. Is there some future direction where the book will use bothfdataandbdata?Beta Was this translation helpful? Give feedback.
All reactions