Open Hati- opened 1 month ago
Hmm, my knowledge with this stuff is very limited. I'm just using DirectXTexNet (a wrapper for DirectXTex). All of the functionality I'm using is built in.
If the texture is a normal map and you either have RecalculateZChannel or have the format set to OpenGL, AND you're not exporting as DDS, then it'll run through ImageMagick. Otherwise it just exports with defaults from DirectXTex.
What are some textures/formats you're seeing this on?
I'm exporting textures and not normals, mostly to PNG. The gamma error is most noticeable on dark images, so using class_gadriel.pct
is good for demonstration.
I checked the headers of every filetype and here's my findings:
This corresponds with what you see when viewing the image files. When viewing the PNG and HDR files the image is incorrectly brighter. When viewing any of the other formats the image looks correct.
When exporting images they seem to have the wrong gamma value embedded in the image header, causing them to be brighter in image viewers supporting this header value. Looking at the header of exported images they have a gamma value of
1
. Changing this to0.454545
(1/2.2), which is the encoding gamma most systems use, makes the image appear correct and not too bright anymore. If the image viewer doesn't support this header then I think they assume an encoding gamma of0.454545
, which makes them render correctly despite there being a malformed gamma in the header.I'm no expert with gamma, image formats, or DXGI, so I could be entirely wrong, but this should perhaps be looked into.
If you have Magick you can use
magick identify -verbose image_file.png
to view the image headers and its gamma value.You can use this png file to determine if an image viewer handles embedded encoding gamma or not.
If it shows a pear then the image viewer uses the embedded encoding gamma to render the image. If it shows an apple then it does not use the embedded encoding gamma. The embedded encoding gamma of that png file is
0.02
.