Photoshop, Working Spaces, and Game Asset Creation
I recently ran into a problem where an exporter I’d written was creating output that wasn’t what the artists were expecting. In particular, the output from the automated tool looked brighter than the by-hand process they’d been performing.
The mismatch originated from use of the single channel view. When you view a single channel of an RGB image in Photoshop, it uses its grayscale working space (working space being gamma, more or less) to display the channel. This can cause problems if you weren’t expecting to author anything in grayscale, and hadn’t bothered to set that working space to something compatible with your output. In this case, the color space was set to Dot Gain 20%, which is a calculation explicitly intended for print work! It was very noticeable: if you selected a single channel to view, even the white areas would appear much different than the RGB view.
Copying data from this single channel view into an RGB image, or vice versa, causes a conversion between your RGB color space and your Gray color space, which in this case were sRGB and Dot Gain 20%, respectively. That means that Photoshop will actually change the color values to maintain something that looks visually identical– remember, they’re displaying at different gammas. So you’re inadvertently changing your image. In this case, it caused different than intended behavior in a variety of single channel applications (specular term, emissive term, etc.).
The problem, fortunately, is quite simple to fix: if you’re going to be taking image data back and forth between RGB and grayscale color spaces, just make sure your color spaces are compatible. In this case, we wanted to work with sRGB– it’s a logical choice for game development– so we picked sGray to go with it.
I didn’t see sGray documented anywhere, but it turns out my guess was correct: it’s simply sRGB’s gamma calculation, but for a grayscale working space. sRGB’s gamma calculation is already well-documented, so I won’t go into it here.