I thought it might be neat to transform the albedo texture by using PCA to spread out the colors, manipulating that, and then undoing the transform. I can't say it's all that great on its own but maybe you'll find a use for it.
The 16-bit PNG was slightly smoothed to interpolate the 8-bit values to have 16-bit detail, used Iain Fergusson's 2019 Beta 3 or whatever denoise filter in G'MIC with every noise level set to 0 except for small which was set very low. This seemed necessary because banding was very extreme in the transformed texture, even if it wasn't present when undoing the transform.
So far in the .blend in the PCA Test material there's groups what transform to stretch out the color range of the skin on the chest, not taking into account the paler skin on the hands and feet or the eyes, then gives options to transform this, and then transforms back. There's another what tries to transform using the original color range then untransform using a different texture's color range, doesn't look great though. There's another what uses the transformed values as weights for a grayscale conversion of the original texture, then divides the original texture by this, and then multiplies it by the grayscale conversion with a gamma adjustment applied to it, and this seems to make a natural skin darkening effect, probably by coincidence. There's also a hue and saturation manipulation function what works by assigning 3 custom primary colors to the 3 values, with 2 colors either made automatically from the first or with all 3 manually set. It's probably not all that different from a Hue / Sat / Val node but it's more natural being able to just pick a color and have it get the hue and sat and val from that all at once.
Information for the PCA transforms was obtained using ColorSpace from couleur.org on the texture what's been converted to linear sRGB to make a selection on the image, run a 3D color space visualization under Color -> Color Spaces, then 3D Visualization -> 3D Color Space, then Visualization -> Get selection from viewer, and then get the information relevant to the PCA transform by going to Informations -> Colors informations.
From there, the E0-E2 vectors can be transformed to 3 rotations by treating it as a rotation matrix, I used https://github.com/gaschler/rotationconverter this tool to do it automatically for me, and set it for degrees and use the Euler angles (degrees) output for a mapping node, but it seems to need inverted values when it's set to Texture and not Point and it seems to need to be set to Texture in order to do the translation before rotation. The mean color is used as the translation to center the data on the mean color.
Could also, like, transform a YUV or YCbCr matrix to rotations and use that in a mapping node for a quick conversion and rotate on the X axis to rotate the hue and scale Y and Z to adjust chroma, though the default YUV seems to become greenish when chroma is at 0. I don't think it was an issue with my implementation though, I seem to recall having similar issues with it when I actually used a normal matrix in a GLSL shader a while back. Though I think it turned yellowish, not greenish.
PCA Test.zip human_female_albedo-16bitSmoothed.zip
I thought it might be neat to transform the albedo texture by using PCA to spread out the colors, manipulating that, and then undoing the transform. I can't say it's all that great on its own but maybe you'll find a use for it.
The 16-bit PNG was slightly smoothed to interpolate the 8-bit values to have 16-bit detail, used Iain Fergusson's 2019 Beta 3 or whatever denoise filter in G'MIC with every noise level set to 0 except for small which was set very low. This seemed necessary because banding was very extreme in the transformed texture, even if it wasn't present when undoing the transform.
So far in the .blend in the PCA Test material there's groups what transform to stretch out the color range of the skin on the chest, not taking into account the paler skin on the hands and feet or the eyes, then gives options to transform this, and then transforms back. There's another what tries to transform using the original color range then untransform using a different texture's color range, doesn't look great though. There's another what uses the transformed values as weights for a grayscale conversion of the original texture, then divides the original texture by this, and then multiplies it by the grayscale conversion with a gamma adjustment applied to it, and this seems to make a natural skin darkening effect, probably by coincidence. There's also a hue and saturation manipulation function what works by assigning 3 custom primary colors to the 3 values, with 2 colors either made automatically from the first or with all 3 manually set. It's probably not all that different from a Hue / Sat / Val node but it's more natural being able to just pick a color and have it get the hue and sat and val from that all at once.
Information for the PCA transforms was obtained using ColorSpace from couleur.org on the texture what's been converted to linear sRGB to make a selection on the image, run a 3D color space visualization under Color -> Color Spaces, then 3D Visualization -> 3D Color Space, then Visualization -> Get selection from viewer, and then get the information relevant to the PCA transform by going to Informations -> Colors informations.
From there, the E0-E2 vectors can be transformed to 3 rotations by treating it as a rotation matrix, I used https://github.com/gaschler/rotationconverter this tool to do it automatically for me, and set it for degrees and use the Euler angles (degrees) output for a mapping node, but it seems to need inverted values when it's set to Texture and not Point and it seems to need to be set to Texture in order to do the translation before rotation. The mean color is used as the translation to center the data on the mean color.
Could also, like, transform a YUV or YCbCr matrix to rotations and use that in a mapping node for a quick conversion and rotate on the X axis to rotate the hue and scale Y and Z to adjust chroma, though the default YUV seems to become greenish when chroma is at 0. I don't think it was an issue with my implementation though, I seem to recall having similar issues with it when I actually used a normal matrix in a GLSL shader a while back. Though I think it turned yellowish, not greenish.