Created attachment 236254 [details] v1 (apply via "git am") JPEG XL excels at compressing high quality/fidelity images and tries to replace legacy JPEG and JPEG 2000 (aka JP2). Based on upstream PR but combined into files/patch-jxl to aid rebases and avoid too many intermediate commits. See also https://avif.io/blog/comparisons/avif-vs-jpegxl/ I've already enabled JXL by default in many other ports.
Need feedback from darktable40 maintainer as well. Either one works. The patch is split by port but landing together is recommended for consistency.
Comment on attachment 236254 [details] v1 (apply via "git am") Thanks Jan, but rejected for darktable. The option is misnamed, and I do not want feature patches that implement FreeBSD-specific matter, it should be available to everyone. So improve on https://github.com/darktable-org/darktable/pull/10044 and get it in, then we'll receive it later. If it's merged formally on a relevant branch upstream, we can cherry-pick. But I am not taking 35 kB patches. We are not forking darktable in FreeBSD. One big fork by a former contributor is enough. Also, if the option enables JPEG XL, it needs to be named that. Port/package users will not care about the implementing library's name, and it might change, we have had that on multiple occasions on other ports. The user also need not know the requisites under the hood, and I as maintainer had never heard of JXL before today. Sorry, wrong addressee. Regarding 3.8 I do not want to pre-empt dumbbell@s decision, but on an obsolete release and branch adding features downstream makes even less sense.
mandree@ for darktable40: + means feedback given, but patch rejected.
(In reply to Matthias Andree from comment #2) > The option is misnamed I disagree. JXL option name is intentional, see ports b0f70ceb2e9a. For example, darktable* already uses OPENJPEG for JPEG 2000, and OPENJPEG cannot be renamed because jasper used unconditionally in LIB_DEPENDS also provides JPEG 2000 support. Another example is HEIF option which is sometimes used for AVIF support. > I do not want feature patches that implement FreeBSD-specific matter OK. Low maintenance is a perfectly valid reason.
(In reply to Jan Beich from comment #4) It's also a pars-pro-toto name that does not name the feature, but the provider, even if libjxl is the reference implementation. The other reason in the commit you referred to is that other libraries had different requirements, but in the end this only proves that our abstraction level is insufficient. And I repeat my earlier point: beyond maintenance, I am concerned about the divergence and locally bringing in stuff that is still under discussion upstream (and an upstream that has taken features happily), and that seems limiting. If we were offering a -devel port where we experiment, that would be in scope, but in a mainline stable port, a locally default-enabled option for a v0.x reference library seems a bit daring.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d410d3f2f6b2c6fa2cca725b91ea97077884072f commit d410d3f2f6b2c6fa2cca725b91ea97077884072f Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2023-01-28 08:56:26 +0000 Commit: Matthias Andree <mandree@FreeBSD.org> CommitDate: 2023-01-28 09:02:33 +0000 graphics/darktable: fix stage-qa libjxl complaint Approved by: portmgr@ (blanket fix-depends) Reported by: Jan Beich The actual file support was previously requested in PR: 266125 as a misnamed option, but now JPEG XL is enabled unconditionally. graphics/darktable/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)