JacobDev1

I have little control over the encoders because I'm not using the API. This makes the problem quite tricky to solve. Limiting the maximum number of encoders is definitely an...

The "Low RAM" mode may be slower, but I can assure you it does utilize all threads given to it. Thread saturation is a separate topic. The solution you proposed...

What is the highest resolution in those images you're processing? You can enable the "Low RAM" mode to handle this edge case for now and/or use Effort 7. Effort 8...

I consider 8 k to be "high-res" because it requires over 8 GB of RAM to be processed with Effort 9. Review my [libjxl issue](https://github.com/libjxl/libjxl/issues/3746) for more details. I will...

Thanks. If `libjxl` devs add streaming encoding to `cjxl`, this will lower the RAM usage by a lot. If not, I'll try to work around this. We'll see.

This issue is related to #49 For now, I'll wait for the next `libjxl` release with hopes streaming encoding gets added to `cjxl`. If that won't happen, I'll prototype solutions...

The next update will address this problem. "Multithreading" modes will be replaced by this option: "JPEG XL - Optimize RAM Usage". This optimizer will switch to single-worker mode when streaming...

The next update will extend the RAM optimizer, allowing for balancing between encoding speed and RAM usage. The new optimizer will dynamically adjust the number of concurrent encoders based on...

Quality in `cjxl` is internally mapped to distance. Using one or the other results in an identical file. Quality is just a commonly understood abstraction. This is the `libjxl` implementation:...

If you really need distance, you can use the table above for the reference. If more people ask, I'll consider it, but generally people prefer to use the Quality rate...