JPEG XL output format support #10044

cyruscook · 2021-09-20T22:24:13Z

Add support for writing JPEG XL formatted images.
More information about the JPEG XL format can be found here: https://jpeg.org/jpegxl/index.html .

Supporting JPEG XL as an output format will allow darktable users to be able to create JPEG XL images which will offer large benefits for any purposes requiring fast transmission or efficient storage of images as JPEG XL images offer far better compression than JPEG images while retaining more quality, and also support features such as progressive decoding.
JPEG XL is currently supported by Chromium (behind a flag) and Firefox Nightly, however, if darktable users hosting websites offer user agents the option to download and render JPEG XL images this will provide motivation for better support in web browsers.
JPEG XL already has support for many image viewers such as Gimp and Eye of Gnome.

Considerations:

This PR requires linking darktable builds with libjxl.
libjxl's encoding API is not yet stable so the code submitted here could require some maintenance.
libjxl provides a statement that security is not a priority in their development. Therefore the security aspects of including JPEG XL support should be considered. Any vulnerability would require user interaction: the user would have to export an unsafe image with the jxl format selected. There is still a risk here. I can easily imagine a scenario where someone posts malicious image files online, asking other people to edit it for them. I would appreciate input on this.
libjxl is in active development and there are still frequent bugs. In libjxl 0.5 encoding an image with an encoding effort setting over 4 can cause a crash. Since 0.6 is not yet released I have added a check that will limit the range of the encoding effort setting between 3 and 4. If bugs like this frequently occur this could result in extra maintenance required for this code.

I hope this PR is at the required standard as submitted, however there was a large lack of documentation surrounding a lot of the areas I was contributing to, so please do let me know if there are any more changes I should make.

src/CMakeLists.txt

cmake/modules/FindOpenJPEG.cmake

src/imageio/format/jxl.c

kmilos · 2021-09-21T08:01:36Z

src/imageio/format/jxl.c

+
+int flags(dt_imageio_module_data_t *data)
+{
+  // fixme: For now exiv2 does not support writing to bmff containers.


libjxl should support adding the Exif data directly as cjxl seems to do it (see also avif.c which is also not using exiv2 for this)

libjxl does not have any API for adding exif data when encoding images, cjxl has custom code to add the exif data.
I will try and do the same.

Would be nice to have indeed, as exiv2 probably won't have write support for a while...

I have added support for writing exif (as provided by the exif parameter to write_image) to the outputted file, however XMP is still not supported as the XMP logic happens outside of the image format module so I feel would be out of scope for this PR. As suggested in another comment, however, perhaps in the future I can make a necessary PR to exiv2 to support this. Let me know if this resolves this particular review @kmilos .

Yes, this is the same reason XMP in AVIF is also not supported yet, even though libavif provides and API to write it...

I'd love to hear the core devs comment on this PR - it looks like a "complete" and great job to me, but personally I feel a bit uneasy including the extra cruft of that manual BMFF container creation and Exif box writing in dt, there's quite a bit of burden to assure compliance there...

Would be nice to have indeed, as exiv2 probably won't have write support for a while...

The container format is isobmff like avif and heif are using. I think it is just a matter of making sure that exiv2 knows the file extension and then goes to the isobmff parser ...

exiv2 cannot write to isobmff containers currently, read only. libheif and libavif have their own methods of writing Exif and XMP boxes. libjxl does not (yet).

Metadata (exif/xmp, compressed or uncompressed) read/write should be added to the libjxl api soon. It's probably better to wait until that arrives instead of implementing it independently here.

1div0

LG2M

src/imageio/format/jxl.c

kmilos · 2021-09-22T07:55:48Z

src/imageio/format/jxl.c

+  void *runner = JxlThreadParallelRunnerCreate(NULL, num_threads);
+  JXL_ASSERT(JxlEncoderSetParallelRunner(encoder, JxlThreadParallelRunner, runner));
+
+  cmsHPROFILE out_profile = dt_colorspaces_get_output_profile(imgid, over_type, over_filename)->profile;


Perhaps we should also consider setting the color encoding the "native" way using JxlEncoderSetColorEncoding() if possible first and then fall back to ICC - see also avif.c?

What would be the benefit of doing this? I would just have to manually gather all the data that is already included in the icc profile and provide that to libjxl instead right?

There might be a risk that some 3rd party apps don't handle ICC profiles for example, so the "native" way of encoding the color profile in the stream might be preferable? This seems to be the case w/ AVIF/HEIF images, but then again, that might be the legacy of the video side of those containers where video players of course don't usually understand ICC profiles so there was always a preference for the "nclx" way of encoding the color space (this is btw using the same CICP enums as JPEG XL). OTOH, some 3rd party apps behave the opposite (ICC is renederd fine, while CICP is not)...

See e.g these for potential pitfalls:

https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361/17
https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361/19

I guess there should be a way for the JXL output plugin to generate both, just like the current AVIF one does based on the output profile selection.

And you don't have to "manually gather" anything, it's all already contained in over_type, it's just about how one chooses to encode it, see again avif.c:

https://discuss.pixls.us/t/experimenting-with-hlg-and-hdr10-for-still-images/23361/15

Thank You, that makes more sense.

Could you also clarify the purpose of the if(imgid > 0) check just above the code you sent (https://github.com/darktable-org/darktable/blob/master/src/imageio/format/avif.c#L284).
I saw the same check in the code of lots of the other output format modules but I didn't understand the significance and didn't do anything similar in the jxl module.

Could you also clarify the purpose of the if(imgid > 0) check just above

Not sure, sorry; we'll have to wait for someone else to chip in on that one...

The icc profile can be big making the image bigger. The nclx container just takes a few bytes. We want to safe bandwidth with those new formats!

jxl does not use the "nclx" box in a container, but encodes all non-ICC, non-Exif etc. rendering related metadata in the codestream directly if you chose not go with the other option, so you actually have to decode it first even inside exiv2 just to read that metadata :( I'd keep the ICC option supported, a few kB is not that big deal for high res HDR images (jxl plans to brotli compress ICC and Exif boxes anyway)...

I hope ab289b9 resolves this? @kmilos

The icc profile also gets encoded in the codestream - it is considered rendering related metadata so part of the codestream, regardless of whether it is done as an Enum colorspace or an ICC profile.

It is a good idea to use Enum colorspaces whenever possible (which should be usually the case, since any reasonable RGB colorspace does have an Enum encoding, including sRGB, Adobe RGB 1998, Display P3, DCI-P3, Rec.2020 PQ or HLG, ProPhoto, etc).

src/imageio/format/jxl.c

data/darktableconfig.xml.in

TurboGit

First pass.

BTW, is that otherwise ready for integration ?

src/imageio/format/jxl.c

src/CMakeLists.txt

src/imageio/format/jxl.c

cyruscook · 2021-10-04T18:26:02Z

Thank You @TurboGit , will apply suggestions soon.

BTW, is that otherwise ready for integration ?

No, need to add code to replace the current ICC profile usage.
Also, potentially need a response to this: #10044 (comment)

TurboGit · 2021-10-04T18:28:54Z

Ok, I'll put this with wip tag. Ping me when ready. TIA.

cryptomilk · 2021-10-12T06:48:09Z

cmake/modules/FindJXL.cmake

@@ -0,0 +1,37 @@
+# Find libjxl


As libjxl is using CMake they should write out cmake config files and then you should find libjxl using cmake config mode.

See https://cmake.org/cmake/help/latest/command/install.html#export

You can take a look how libavif is doing it :-)

Hi, sorry, could you please clarify what you are suggesting? If it is a change to libjxl that is probably out of scope for this PR but if libjxl adopt the change in the future I will happily change the darktable libjxl code.

@cryptomilk FYI, looks like there is a PR in progress to address this. However, we should probably stick with the custom FindJXL.cmake. I might consider changing all the prefixes to "JPEGXL" though to match upstream, Krita, and WebKit, and ease future migration...

cryptomilk · 2021-10-12T07:05:09Z

src/imageio/format/jxl.c

+
+      for(int k = 0; k < channels; k++) pixels[(y * width * channels) + (x * channels) + k] = buf[k];
+    }
+  }


JPEG XL only supports 32bit?

It seems the encoder does all the desired conversion and quantization by its own, so passing just the 32-bit float should be ok.

But maybe we do need an "advanced" option to control that quantization?

Got this one wrong, it looks like float really is the jxl internal working type, and adaptive quantization is already controlled by the quality parameters. 8b and 16b integer data is converted to float if the input files were already quantized like that (PPM, PNG...). So there is no real need for dt to do any conversion (apart from any HDR scaling gotchas).

The format you use to pass the buffer can be float in all cases (which is what libjxl will use internally anyway). The bitdepth you actually use for lossless encoding can be anything (8-bit, 10-bit, 16-bit, up to 24-bit integer or up to lossless 32-bit float) - of course higher bit depth will make bigger files. For lossy encoding, the nominal bitdepth doesn't really matter (it doesn't change how the image actually gets encoded, it's just a header field that is used as a suggested bitdepth to represent the image in after decoding).

Thanks @jonsneyers for your insights. It sounds like we might want to add the 8/10/12/16-bit integer options then as well.

Yes, but implementation-wise, you can always just use floats to pass the data, and adjust what is stored (in case of lossless compression) by simply changing the bits_per_sample in the encoder option struct.

kmilos · 2021-10-12T07:29:20Z

Btw, maybe it's an idea to update for any 0.6 API changes and require it as min version?

cryptomilk · 2021-10-12T07:37:24Z

I think they should create cmake configs for discovering libjxl and then we should require that as the min version. I did the same with libavif back in the time ;-)

kmilos · 2021-10-12T07:47:00Z

I think they should create cmake configs for discovering libjxl

Sure. You can chime in at https://github.com/libjxl/libjxl/issues, there are a few packaging related issues raised recently already.

cyruscook · 2021-10-12T21:48:46Z

I think it is ready now - is there any more feedback from anyone?

kmilos

Getting there ;)

DefineOptions.cmake

src/imageio/format/jxl.c

kmilos · 2021-10-13T08:22:19Z

src/imageio/format/jxl.c

+  JxlEncoderOptions *options = JxlEncoderOptionsCreate(encoder, NULL);
+  JXL_ASSERT(JxlEncoderOptionsSetLossless(options, params->lossless ? JXL_TRUE : JXL_FALSE));
+
+  int decode_effort = params->decoding_effort;


Think it might be better to follow the API and cjxl command line options and actually use decode_speed as a direct parameter instead of decode_effort instead of this hidden acrobatics.

kmilos · 2021-10-13T08:23:52Z

src/imageio/format/jxl.c

+  // We store quality but jxl wants distance, so we reverse the scale
+  quality = (quality - 15) * -1;


Same as above, let's stick to the API and cjxl options, as that is what people will refer to:

https://github.com/libjxl/libjxl/blob/0f387788921c76e9e3490c5aba3fd80cf2fb3cfe/tools/cjxl.cc#L328-L353

IMHO we should use the same values as cjxl's --quality, --effort, and --faster_decoding (passed straight to jxl::CompressParams)

Good idea.

By the way, Thank You so much for your helpful reviews! Getting through them slowly! 😅

Np, hope I'm not 'nagging' too much, keep up the great work ;)

Actually, the API is setting butteraugli distance directly, and the conversion from quality is more complicated than this. I wonder if we should update the parameters to "distance" (potentially even remove "lossless" and use distance==0 to set it), "encode effort", and "decode speed", as these are then simply passed through and documented by JXL API (and are also present for cjxl)...

0 distance and lossless mode is not the same thing.

0 distance and lossless mode is not the same thing.

Indeed not, but the API documentation says:

Sets the distance level for lossy compression: target max butteraugli distance, lower = higher quality. Range: 0 .. 15. 0.0 = mathematically lossless (however, use JxlEncoderOptionsSetLossless to use true lossless). 1.0 = visually lossless. Recommended range: 0.5 .. 3.0. Default value: 1.0. If JxlEncoderOptionsSetLossless is used, this value is unused and implied to be 0.

So I think it should be safe (implied) to never set the actual distance to 0, but call JxlEncoderOptionsSetLossless when the GUI setting is at 0.

The actual distance cannot be set to too small values, because at some point lossy encoding makes no sense anymore and will become larger than lossless. So making the gui setting distance 0 correspond to lossless makes sense, and is also what cjxl does. The minimum non-lossless distance is 0.1 or so (or maybe we lowered it to 0.01, but still, anything below 0.3 or so probably does not really make sense).

src/imageio/format/jxl.c

kmilos · 2021-10-13T12:17:42Z

Speaking of GIMP, it looks like only sRGB is basically supported from the codestream ATM, all other color spaces must come from ICC, which is why I prefer to have that option more accessible/default...

@novomesk Would love to hear you comments on the color encoding for export here as well, thanks.

novomesk · 2021-10-13T14:00:21Z

@kmilos
The code in GIMP attempt to detect known GIMP profiles, in order to avoid the dialog which is asking user to keep original profile or to convert to GIMP profile. That's merely for user's convenience.

src/imageio/format/jxl.c

kmilos · 2021-10-14T09:01:36Z

src/imageio/format/jxl.c

+  basic_info.exponent_bits_per_sample = 8;
+  basic_info.intensity_target = 255.f;
+  basic_info.min_nits = 0.f;
+  basic_info.relative_to_max_display = JXL_FALSE;


These I have no experience with:

I thought 1.f is the reference?

How does relative_to_max_display work out for the PQ transfer curve case?

To be honest I am just using the values from here: https://github.com/libjxl/libjxl/blob/fd06f61d0e49a28b8b0894e227994b40d2e446d0/lib/jxl/encode.cc#L158-L160
The way I understand it is that intensity target and min nits are allowed to be just the min/max possible intensity if you do not want to calculate the actual min/max intensity.
I'm afraid I'm not able to provide any detailed comments on this as I do not have any experience either.
Perhaps someone else can give a more knowledgable opinion?

Intensity target is the brightness of white, in nits. For SDR the value 255 is fine, for HDR it would be the maximum nits (something like 1000 nits for Rec.2100 HLG, or 10000 nits for PQ). Surprisingly, ICC profiles don't specify this, so we added it in the jxl header because otherwise an image viewer cannot really know what the intended display brightness is.

Basically the linear float value (in nominal range 0.f-1.f), multiplied by the intensity target gives you the brightness in nits of the pixel (assuming it's a gray one). That's why we picked the value 255 for SDR: it is a confusing but convenient value, since it is both a reasonable max brightness in nits to expect from an SDR display, and if you multiply values in 0.f-1.f with it (after applying the transfer curve), you also happen to get values that can just be truncated to get 8-bit integer values.

This whole HDR business is so messy... Most photography/videography is still based on mid-gray anchoring, which makes 1.0 = "diffuse white" (for SDR this is the same as "max white"), but then permits values much greater than 1.0 for highlights. Unfortunately a lot of SW (and ICC) don't work this way, and I believe they assume 1.0 is max white (like you seem to do here as well). So not 100% sure what to do here, because from #3880 it sounds like darktable hasn't converged on how to handle this internally yet...

Side note: one is wasting a whole lot of dynamic range if limiting values to 0-1.0 only (still leaving plentiful 126 stops in the float case luckily), which is undoubtedly problematic if quantizing to float16 with that restriction (14 stops instead of available 30, so worse than 16-bit integer actually).

Thanks for the excellent explanation Jon.
I think this is probably something that I cannot do anything about without more clear guides as how darktable as an entire project wants to handle this...
For now I guess this will work ok except on some images which darktable already does not seem to properly support.
Perhaps if someone has an example image which will fail with the current code I can try and fix it with that as a reference?
Otherwise for now I think it is best left.

kmilos · 2021-10-14T09:02:21Z

src/imageio/format/jxl.c

+  // We store quality but jxl wants distance, so we reverse the scale
+  quality = (quality - 15) * -1;


Np, hope I'm not 'nagging' too much, keep up the great work ;)

src/imageio/format/jxl.c

novomesk · 2021-10-14T16:33:13Z

I have one observation:
Encoding is always with basic_info.uses_original_profile = JXL_TRUE;

That's not wrong but mode without original profile gives sometimes much better lossy compression.
Mode with uses_original_profile == JXL_FALSE require that pixels are converted to sRGB with linear or non-linear TRC (it depends on integer or float data type) prior saving.

I just wanted to let you know, feel free to make own decision whether to implement other mode or not.

kmilos · 2021-10-14T17:14:50Z

That's not wrong but mode without original profile gives sometimes much better lossy compression.
Mode with uses_original_profile == JXL_FALSE require that pixels are converted to sRGB with linear or non-linear TRC (it depends on integer or float data type) prior saving.

Interesting... That conversion is done automatically by the JXL encoder, or we'd have to do it manually before filling the buffer for JxlEncoderAddImageFrame()?

For this initial PR I'd personally stick to keeping everything nicely aligned and not increase complexity so we can demonstrate good interoperability and image quality first and foremost.

novomesk · 2021-10-14T17:31:27Z

or we'd have to do it manually before filling the buffer

https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/encode.h#L223

You have to convert the pixels manually.

TurboGit

Works for me, time to move forward and have more field testing. Thanks a lot, nice to see JXL on darktable.

kmilos · 2022-10-24T18:32:29Z

Yay! Thanks @cyruscook for doing all the hard initial work!

victoryforce · 2022-10-24T19:39:22Z

Great, congratulations! Now I can finalize and PRize the native jxl reading support that has been waiting to not interfere with this PR.

paolobenve · 2022-10-24T20:53:42Z

Trying to compile on ubuntu 22.04, after installing libjxl-dev, I get:

$ sudo ./build.sh --prefix /opt/darktable-test/ --build-type Release && sudo git config --global --add safe.directory /home/paolo/git/darktable && sudo cmake --build "/home/paolo/git/darktable/build" --target install -- -j12
[....]
/home/paolo/git/darktable/src/imageio/format/jxl.c: In function ‘write_image’:
/home/paolo/git/darktable/src/imageio/format/jxl.c:122:7: error: unknown type name ‘JxlEncoderError’; did you mean ‘JxlEncoder’?
  122 |       JxlEncoderError err = JxlEncoderGetError(encoder);                                                          \
      |       ^~~~~~~~~~~~~~~
/home/paolo/git/darktable/src/imageio/format/jxl.c:122:7: note: in definition of macro ‘LIBJXL_ASSERT’
  122 |       JxlEncoderError err = JxlEncoderGetError(encoder);                                                          \
      |       ^~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
gmake[2]: *** [lib/darktable/plugins/imageio/format/CMakeFiles/jxl_format.dir/build.make:76: lib/darktable/plugins/imageio/format/CMakeFiles/jxl_format.dir/jxl.c.o] Errore 1
gmake[1]: *** [CMakeFiles/Makefile2:6552: lib/darktable/plugins/imageio/format/CMakeFiles/jxl_format.dir/all] Errore 2

After removing the build directory and compiling again, the error is still there.

I had previously compiled dt without libjxl-dev installed: compilation ended ok, but obviously without any jxl support in dt.

ptilopteri · 2022-10-24T21:17:10Z

also fails on openSUSE Tumbleweed:
CMake Error: Error processing file: /data/dt-build/darktable/build/CMakeFiles/VerifyGlobs.cmake
gmake: *** [Makefile:4270: cmake_check_build_system] Error 1

ptilopteri · 2022-10-24T21:27:46Z

and, after multiple wipes and re-fetches, it now compiles properly ???

kmilos · 2022-10-25T13:47:37Z

@paolobenve It doesn't look like you're using libjxl 0.7.0 - AFAIK it is only available for Ubuntu 22.10 at the moment.

paolobenve · 2022-10-25T16:51:48Z

@paolobenve It doesn't look like you're using libjxl 0.7.0 - AFAIK it is only available for Ubuntu 22.10 at the moment.

No, it seems 0.7.0:

$ aptitude show libjxl
Package: libjxl                          
Version: 0.7.0-20220426.105500-0xiota0~ubuntu22.04
New: yes
State: installed
Automatically installed: no
Multi-Arch: same
Priority: optional
Section: libs
Maintainer: JPEG XL Maintainers <jpegxl@google.com>
Architecture: amd64
Uncompressed Size: 2974 k
Depends: libbrotli1 (>= 0.6.0), libc6 (>= 2.35), libgcc-s1 (>= 3.4), libhwy0 (>= 0.16.0), libstdc++6 (>= 12)
Description: etc.

kmilos · 2022-10-25T16:55:47Z

20220426

This is God knows what version/snapshot (April 26, while 0.7.0 was released just recently on Sept 21), from an unknown PPA...

In any case, beyond the scope of this PR.

paolobenve · 2022-10-26T01:48:48Z

This is God knows what version/snapshot (April 26, while 0.7.0 was released just recently on Sept 21), from an unknown PPA...

At the end I dedided to compile libjxl 0.7.x, following instructions in https://github.com/libjxl/libjxl/tree/v0.7.x Apparently everything was ok.

But when I try to compile dt I get various warnings:

during config:

CMake Warning at src/libs/CMakeLists.txt:95 (find_package):
  By not providing "FindSDL2.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "SDL2", but
  CMake did not find one.

  Could not find a package configuration file provided by "SDL2" with any of
  the following names:

    SDL2Config.cmake
    sdl2-config.cmake

  Add the installation prefix of "SDL2" to CMAKE_PREFIX_PATH or set
  "SDL2_DIR" to a directory containing one of the above files.  If "SDL2"
  provides a separate development package or SDK, be sure it has been
  installed.

when beginning compile (many many times, referring to different CMakeLists.txt lines):

CMake Warning at src/CMakeLists.txt:934 (add_library):
  Cannot generate a safe runtime search path for target lib_darktable because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libjxl.so] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /usr/local/lib
    runtime library [libjxl_threads.so] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /usr/local/lib

  Some of these libraries may not be found correctly.

Actually, compilation end with this error:

gmake[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libjxl.so', needed by 'bin/libdarktable.so'.  Stop.
gmake[1]: *** [CMakeFiles/Makefile2:2443: bin/CMakeFiles/lib_darktable.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 36%] Built target validate_noiseprofiles_json
[ 36%] Built target validate_wbpresets_json
gmake: *** [Makefile:156: all] Error 2

What am I missing?

magicgoose · 2022-12-11T09:17:27Z

Has anyone been able to use it on Arch Linux? Does that require rebuilding from source at the moment? None of the available darktable packages seem to have a libjxl dependency, neither required nor optional. And the JPEG-XL choice is not there in GUI.

cyruscook · 2022-12-11T12:30:57Z

@magicgoose it seems like it will require building from source, make sure you have libjxl available when building it.
It seems whoever is making the arch Linux releases does not have libjxl installed, so dark table is being built without support (my guess).

trougnouf · 2022-12-11T12:56:27Z

@magicgoose it seems like it will require building from source, make sure you have libjxl available when building it. It seems whoever is making the arch Linux releases does not have libjxl installed, so dark table is being built without support (my guess).

Reported on https://bugs.archlinux.org/task/76799

magicgoose · 2022-12-23T20:19:05Z

Now works with the latest darktable version 🎉

TurboGit added this to the 3.8 milestone Sep 21, 2021

TurboGit added documentation-pending a documentation work is required feature: enhancement current features to improve release notes: pending labels Sep 21, 2021

kmilos reviewed Sep 21, 2021

View reviewed changes

cyruscook force-pushed the pr-jxl-format branch from 40dfc93 to f9fb31a Compare September 21, 2021 17:44

1div0 reviewed Sep 21, 2021

View reviewed changes

cyruscook force-pushed the pr-jxl-format branch from f9fb31a to 6dc3bde Compare September 21, 2021 18:11

kmilos reviewed Sep 21, 2021

View reviewed changes

src/imageio/format/jxl.c Outdated Show resolved Hide resolved

kmilos reviewed Sep 22, 2021

View reviewed changes

kmilos reviewed Sep 27, 2021

View reviewed changes

src/imageio/format/jxl.c Outdated Show resolved Hide resolved

data/darktableconfig.xml.in Show resolved Hide resolved

cyruscook force-pushed the pr-jxl-format branch from 49e5327 to 311ba25 Compare September 29, 2021 12:27

TurboGit requested changes Oct 4, 2021

View reviewed changes

TurboGit added the wip pull request in making, tests and feedback needed label Oct 4, 2021

cryptomilk reviewed Oct 12, 2021

View reviewed changes

kmilos suggested changes Oct 13, 2021

View reviewed changes

kmilos suggested changes Oct 14, 2021

View reviewed changes

kmilos reviewed Oct 14, 2021

View reviewed changes

src/imageio/format/jxl.c Outdated Show resolved Hide resolved

kmilos added 9 commits October 24, 2022 15:03

Drop the 6-byte Exif JPEG APP1 header

a0e8f64

Update the quality to distance mapping

9f35d49

Update for export actions

484f57d

Enable JPEG XL for gallery export

db62c54

Update READMEs and CI for libjxl

ec06209

Extract common white point assignment

04d017c

Refactor bpp and pixel type UI

e9ef06b

Defaults are for lossy JPEG XL export, usually without original profile

48c40ed

Updates after feedback

1e20064

kmilos force-pushed the pr-jxl-format branch from fda0c79 to 1e20064 Compare October 24, 2022 13:35

TurboGit approved these changes Oct 24, 2022

View reviewed changes

TurboGit merged commit 28547c0 into darktable-org:master Oct 24, 2022

TurboGit removed the release notes: pending label Nov 5, 2022

kmilos mentioned this pull request Nov 7, 2022

JXL (required version >= 0.7.0) Build fails with 4.1.0+875~gaa14affc8 - #12806

Closed

elstoc removed the documentation-pending a documentation work is required label Nov 21, 2022

beling mentioned this pull request Nov 24, 2022

JPEG XL (*.jxl) file format support Beep6581/RawTherapee#6273

Open

kmilos mentioned this pull request Sep 25, 2023

Build from GIT fails to complete #15307

Closed

		// We store quality but jxl wants distance, so we reverse the scale
		quality = (quality - 15) * -1;

JPEG XL output format support #10044

JPEG XL output format support #10044

Conversation

cyruscook commented Sep 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

1div0 left a comment

Choose a reason for hiding this comment

kmilos Sep 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kmilos Sep 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TurboGit left a comment

Choose a reason for hiding this comment

cyruscook commented Oct 4, 2021

TurboGit commented Oct 4, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kmilos commented Oct 12, 2021

cryptomilk commented Oct 12, 2021

kmilos commented Oct 12, 2021

cyruscook commented Oct 12, 2021

kmilos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kmilos Oct 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kmilos Oct 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kmilos commented Oct 13, 2021 • edited Loading

novomesk commented Oct 13, 2021

Choose a reason for hiding this comment

cyruscook Oct 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

novomesk commented Oct 14, 2021

kmilos commented Oct 14, 2021 • edited Loading

novomesk commented Oct 14, 2021

TurboGit left a comment

Choose a reason for hiding this comment

kmilos commented Oct 24, 2022

victoryforce commented Oct 24, 2022

paolobenve commented Oct 24, 2022 • edited Loading

ptilopteri commented Oct 24, 2022

ptilopteri commented Oct 24, 2022

kmilos commented Oct 25, 2022

paolobenve commented Oct 25, 2022

kmilos commented Oct 25, 2022 • edited Loading

paolobenve commented Oct 26, 2022

magicgoose commented Dec 11, 2022

cyruscook commented Dec 11, 2022

kmilos Sep 22, 2021 •

edited

Loading

kmilos Sep 22, 2021 •

edited

Loading

kmilos Oct 13, 2021 •

edited

Loading

kmilos Oct 14, 2021 •

edited

Loading

kmilos commented Oct 13, 2021 •

edited

Loading

cyruscook Oct 14, 2021 •

edited

Loading

kmilos commented Oct 14, 2021 •

edited

Loading

paolobenve commented Oct 24, 2022 •

edited

Loading

kmilos commented Oct 25, 2022 •

edited

Loading