PFM Format Output iw3

[Syer10]

I recently asked AutoDepth Image Viewer to support using iw3 as a backend.
https://steamcommunity.com/app/2552330/discussions/0/684115079180016863/

AutoDepth Image Viewer currently works with .pfm files to show the depth on an image. iw3 currently can output a SBS image and an grayscale depth image, they could add support for that but they mentioned that it would be easier to work with files in the .pfm format. It should be a standard format that can be pretty easily added.

[nagadomi]

I have several opinions on this, but all of them are either negative or suggest alternatives.

1. Using a standalone depth model is simpler and safer than using iw3 as a backend

If the goal is simply to use a depth model, it's easier and less risky to use a model directly instead of calling iw3 as a backend.
I sometimes make major internal changes in iw3 or modify its default behavior.
Also, the depth models used by iw3 are managed in separate repositories, so using or referencing them directly is simpler.

• https://github.com/nagadomi/ZoeDepth_iw3
• https://github.com/nagadomi/MiDaS_iw3
• https://github.com/nagadomi/Depth-Anything_iw3
• https://github.com/nagadomi/ml-depth-pro_iw3
• https://github.com/nagadomi/Video-Depth-Anything_iw3
• https://github.com/nagadomi/Depth-Anything-3_iw3

2. 16-bit Grayscale PNG is a safer external format than PFM

PFM has no formal international standard and is implementation-dependent, although most implementations follow Netpbm and usually work fine.
Pillow can output PFM, but I'm not sure about compatibility regarding the scale field and endianness.

In contrast, 16-bit Grayscale PNG is ISO-standardized.
In 3D graphics, Bump, Height, and Displacement maps are commonly distributed as 16-bit grayscale PNGs, so most viewers or frameworks can load them without issues.
With 65,536 levels, the precision is generally sufficient for depth data. At resolutions like 1920x1080, spatial sampling error is far larger than 1/65535.
If it looks rough, it's probably being read as 8-bit or the normal generation has a problem.

3. For a viewer, supporting common formats like RGB-D or SBS makes more sense

This approach separates viewing from depth/3D conversion and makes data reusable across different viewers.

Devices like Looking Glass and many 3D monitors support RGB-D (SBS layout: left = RGB, right = depth map).
iw3 also supports RGB-D output #402 , so using that would align better with existing tools.

Depth in these formats is usually 8-bit, so direct mesh displacement might look jagged, but it seems that tessellation or depth smoothing is used to improve it.

SBS is common for VR image viewers but not ideal for mesh-based renderers.