“ Export also can be 8-bit JPG with 100% quality. Which are enough for 16bit textures (yes — 8bit JPG images can give 16bit textures — if you know mathematics and image processing basics).”
from my “ Full Photogrammetry Guide for 3D Artists” at 80lv: (https://80.lv/articles/full-photogrammetry-guide-for-3d-artists/ )
You can find this a bit strange. But lets talk not about “Spherical cow” but about real world scan data. ;)
If you ever made any photogrammetry scan, you already found that you probably never scanned objects that have flat color or even long subtle gradient from light blue to more lighter blue. Or if you ever tried that, you already have found that such surface is a nightmare for scanning, because only structured light or even LIDAR scanners only can give you good results. Photogrammetry just failed on them. No details, or rough blobby surfaces.
Yes, photogrammetry required strong and good visible textures to all its steps. From aligning to meshing.
And now lets check what we have in our 16bit data from Camera RAWs. For that we will open RAW from camera with CameraRAW in Photoshop at 16bit. After that lets make clone of this image to a new document, change color from 16bit to 8bit and copy this 8bit layer back to original 16bit document (with shift key pressed). Now we need change layer blend mode from Normal to Difference and voila, we see LSR part of our 16bit data.
You’ll say — wait, it black! Yes! This least significant bit store so small details that you probably never see. But if you still thinking that this bits stored something important. Just flatten your layers and use Equalize for Normalize this information into 0–100% range. What you see? I see noise… or something that looks like noise. :)
So this is a first reason do not care so much about 16bit. Because you always can add some noise to LSB if you want have same as source 16bit :D
Ok, now about how 8bit source can give you 16bit textures.
This is a pure mathematics. Every color correction that you making in 16bit will give you 16bit data, just because you always will have chance to “shift” 8bit “snapped” color somewere in between that will give you 16bit value (8bit just round this value to nearest 8bit value). But you will say that such transformation will remain original 8bit histogram. And mostly youl’ll be right.
And now a “magic”. Every image transformation made in 16bit (excluding 90-180–270–360 degree rotation) because of subpixel transformations will create new pixels in 16bit range.
And that was always happen in photogrammetry Texturing step and/or in texture baking steps.
BTW, this even happen if you just downscale your texture with any method excluding “nearest neighbor”.
That’s why in my workflow where i bake albedo/diffuse texture from textured high resolution mesh is not requred 16bit at all. Just because xNormal will give me same 16bit texture as it will give me if i will bake from 16bit texture. And because my scans already de-lighted. And i do not need strong color correction that can required as much as possible bits for better work.
BTW, here how “good” 16bit data look. For this kind of textures you need 16 or better 32bit float format:
Left “16bit” right LSB part of it. Or to be correct left is a MSB, right LSB.
