Maybe the solution is to use something completely different, as long-term it doesn’t seem we can rely on this utility
Practical Info
This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
At the moment I believe AMD has two different implementations of AVX-512 (one for Zen 4 (Ryzen 7000), and one for Zen 5 (Ryzen 9000)) with different performance characteristics.
I believe AVX-512 is slower on Zen 4, so it will be important testing that generation.
Oh that is potentially interesting for VSE! For image proxies, today VSE uses JPG format. That lacks alpha channel support, and it lacks HDR support. While doing proxies as EXR files for HDR images is one possible approach, JpegXL, if it was there, is another alternative. Looking forward to when it lands!
The libjxl dependency is kind of a real mess it looks like. Which for a project created in the last 5 years is a real shame. It lacks proper Windows build support and might not support Windows arm64 at all, it’s hard to tell. It will probably take a decent amount of effort to work through even once OIIO 3.x lands (most likely for the library refresh for 4.4 early next year).
Good to know. One of their build pages for windows still says that “the MSVC compiler is currently not supported” [1] and you’d have to use clang tooling, which is fine, just raises some eyebrows on why that would even be the case nowadays.
I did a test build when you mentioned building for MSVC was messy, while perhaps not straight forward (it has quite a few more deps than one would expect from a run of the mill image lib), but saw no red flags and was able to get a workable build with a pure msvc 2022 environment, (2019 may throw a wrench in there)
if we are certain this a direction we want to go in i’ll pick this up after the 4.3 lib update is out the door.
AVIF(AV1 Image File Format) is generally considered to be better than JPEG XL for a number of reasons. lossless compression, High quality, transparency, HDR, wide color gamut, Metadata support
Both AVIF and JPEG XL (JXL) are excellent formats.
There is no absolute winner.
JXL is very efficient in lossless and near lossless.
AVIF is able to reach very small file sizes and images are still looking acceptable.
There is quality range where JXL and AVIF reach subjectively similar efficiency (it depends on personal opinion)
Some people say that AVIF compress artificial images better than JXL, other say that photos are more efficiently compressed in JXL than in AVIF.
AVIF uses integer precision: 8, 10 or 12 bits/channel.
JXL can go up to 32 bits (floats) per channel.
JXL can do CMYK, AVIF can’t.
Animated AVIF benefits from efficient AV1 video compression.
JXL can be animated too, but it is not as efficient in animations like AVIF.
AVIF is supported almost by all browsers today, JXL works on Apple devices and few minor browsers so far.
I’d like that both JXL and AVIF are supported so that users have freedom to choose which one they prefer.
Thanks for detailing some of the differences between the two formats.
Support in other applications shouldn’t be of much consideration for this use case (Generating lower quality proxies for the video editor) as it’s not intended for the user to look at them outside of Blender.
There are two different avx512 implementation s on zen5 processors. For mobile devices (strix point apu), it is 256 bit physical datapath, on desktop and server (both zen5 and zen5c cores) it is 512 bit datapath. And zen4 also using 256bit datapath.