JPEG-XL not indexed into DB

[scepterus]

🐛 Bug Report

• 📁 I've Included a ZIP file containing my librephotos log files
• _backend_logs (2).zip
• ❌ I have looked for similar issues (including closed ones)
• 🎬 (If applicable) I've provided pictures or links to videos that clearly demonstrate the issue

📝 Description of issue:

After DB corruption, I scanned the same folders, and only PNGs and Videos are added to library. During the scan, it says it sees 16K photos, but what ends up in the library is about 500.

🔁 How can we reproduce it:

Clear the DB, have PNGs Videos and JPEG-XL in the folder that is scanned, and run a full scan.

Please provide additional information:

• 💻 Operating system: TrueNAS Scale
• ⚙ Architecture (x86 or ARM): X86_64
• 🔢 Librephotos version: Latest-Gpu
• 📸 Librephotos installation method (Docker, Kubernetes, .deb, etc.): Docker
  • 🐋 If Docker or Kubernets, provide docker-compose image tag: Latest
• 📁 How is you picture library mounted (Local file system (Type), NFS, SMB, etc.): ZFS
• ☁ If you are virtualizing librephotos, Virtualization platform (Proxmox, Xen, HyperV, etc.):

[derneuere]

The reason is, that libvips on ubuntu 22.04 does not yet have jpegxl, because that library too does not exist in that version of Ubuntu. I will have to compile this from scratch, but I think a better workaround for you would to just use the regular image in order to scan JPEG-XL.

[scepterus]

I do not understand what you are suggesting I do exactly.

[derneuere]

I suggest switching back to the CPU-based image instead of using the GPU-based image if you only use JPEG-XL. The issue with JPEG-XL support is already resolved in the CPU version. Unfortunately, the fix for the GPU image is not trivial. I spent over a month working on it, and straightforward solutions—like upgrading to a more recent Ubuntu version—don’t work due to compatibility issues with older CUDA versions and PyTorch.