Right, from Image MAgick, we can see :

gilles@U22:/mnt/data/Images/HEIF$ identify test.heif 
test.heif HEIC 3237x2007 3237x2007+0+0 10-bit YCbCr 0.020u 0:00.011

From the console, when loading file on editor, libheif identify this file with 8 bits color depth:

digikam.dimg: "/mnt/data/Images/HEIF/test.heif" : "HEIF" file identified
digikam.dimg.heif: HEIF image size: ( 3237 x 2007 )
digikam.dimg.heif: Decoded HEIF image properties: size( 3237 x 2007 ), Alpha: false , Color depth : 8
digikam.dimg.heif: HEIF data container: 0x55acd15cdb00
digikam.dimg.heif: HEIC bytes per line: 9728
digikam.dimg.heif: Color bytes depth: 8

So problem must be located in how we manage libheif in the HEIF loader, as Image Magick which uses libheif too, is able to convert to PNG with preserving the color depth :

gilles@U22:/mnt/data/Images/HEIF$ convert test.heif test.png
gilles@U22:/mnt/data/Images/HEIF$ identify test.png 
test.png PNG 3237x2007 3237x2007+0+0 16-bit sRGB 17.1832MiB 0.000u 0:00.000

Probably this code must be used :

https://github.com/ImageMagick/ImageMagick/blob/main/coders/heic.c#L354

In digiKam, we uses : 

https://invent.kde.org/graphics/digikam/-/blob/master/core/dplugins/dimg/heif/dimgheifloader_load.cpp#L389

Gilles Caulier

My canon HEIF images appear washed out and I thought this might be the solution but am now convinced otherwise. I'm now slowly going down the education path on colour profiles. I think this patch fixes the bit depth problem as a start. It works for my canon images but I haven't tested for the full combination of alpha and bit depth. 

diff --git a/core/dplugins/dimg/heif/dimgheifloader_load.cpp b/core/dplugins/dimg/heif/dimgheifloader_load.cpp
index eb8862c91f..f3d0bdc071 100644
--- a/core/dplugins/dimg/heif/dimgheifloader_load.cpp
+++ b/core/dplugins/dimg/heif/dimgheifloader_load.cpp
@@ -335,7 +335,7 @@ bool DImgHEIFLoader::readHEICImageByHandle(struct heif_image_handle* image_handl
 {
     int lumaBits   = heif_image_handle_get_luma_bits_per_pixel(image_handle);
     int chromaBits = heif_image_handle_get_chroma_bits_per_pixel(image_handle);
-
+    int colorDepth = lumaBits;
     if ((lumaBits == -1) || (chromaBits == -1))
     {
         qCWarning(DIGIKAM_DIMG_LOG_HEIF) << "HEIC luma or chroma bits information not valid!";
@@ -352,8 +352,8 @@ bool DImgHEIFLoader::readHEICImageByHandle(struct heif_image_handle* image_handl
     struct heif_decoding_options* const decode_options = heif_decoding_options_alloc();
     decode_options->ignore_transformations             = 1;
     m_hasAlpha                                         = heif_image_handle_has_alpha_channel(image_handle);
-    heif_chroma chroma                                 = m_hasAlpha ? heif_chroma_interleaved_RGBA
-                                                                    : heif_chroma_interleaved_RGB;
+    heif_chroma chroma                                 = m_hasAlpha ? ((colorDepth==8) ? heif_chroma_interleaved_RGBA : heif_chroma_interleaved_RRGGBBAA_LE)
+                                                                    : ((colorDepth==8) ? heif_chroma_interleaved_RGB : heif_chroma_interleaved_RRGGBB_LE );
 
     // Trace to check image size properties before decoding, as these values can be different.
 
@@ -385,8 +385,6 @@ bool DImgHEIFLoader::readHEICImageByHandle(struct heif_image_handle* image_handl
     }
 
     heif_decoding_options_free(decode_options);
-
-    int colorDepth = heif_image_get_bits_per_pixel_range(heif_image, heif_channel_interleaved);
     imageWidth()   = heif_image_get_width(heif_image, heif_channel_interleaved);
     imageHeight()  = heif_image_get_height(heif_image, heif_channel_interleaved);

Can you provide a sample Canon HEIF image to test the change?

My HEIF test samples still work with this patch.

Maik

One of the images I've used for testing is:  https://drive.google.com/file/d/1R8nlefUAu5fgwKc57Sd0AzU4R_nE-ZoA/view?usp=drive_link

With the patch it does 10 bit to 16bit scaling shift fine rather than the direct to 8 bit conversion before. The colours are a bit washed out as with 8 bit. My reading regarding the colour profile: ITU-R BT.2100 PQ is that this is a non linear conversion. I think canon are using nclx so dropping through to the "Unknown HEIF color profile type discarded" warning. There is more reading/hacking before I get my head around that part.

Dan

Hmm, when reading the metadata again, the color depth increases to 16bit. But I don't see any difference in the colors, I guess I'll have to take a screenshot. But in comparison, the colors in Gwenview look "better". We'll probably have to take a look at the KimageFormat plugins.

Maik

Git commit def55a17ff967ca9c64c2f34bca3815f849d39b8 by Maik Qualmann.
Committed on 03/09/2023 at 20:10.
Pushed by mqualmann into branch 'master'.

better 10/12/16 bit detection of HEIF images

M  +36   -31   core/dplugins/dimg/heif/dimgheifloader_load.cpp

https://invent.kde.org/graphics/digikam/-/commit/def55a17ff967ca9c64c2f34bca3815f849d39b8

@info@j-pfennig.de,

Maik has patched a lots the code for a better HEIF color depth support.

What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier

Hello

Yes - build 22.10.2023 loads my Heif file, but I cannot create >8 Heif by exporting/saving from Digikam (same for TIFF). Typical problems are:

- There sould be an optional automatic conversion of input to 16-bit Workspace data
- There is no support for exporting in various depths
- For Digikam Tiff has only 8/16 bit color (I know others are non-standard, but are working in IM)
- Where is JPEG XL (as a scientist I like some of its features)

I did not yet check if color profiles are handled correctly in Heif, I will testing to use 10-bit Heif as my archive format and report problems if any.

Anyhow, you all do a good job, DigiKam is fine software. Thanks to everyone

Jürgen

Hi Jurgen,

to create a > 8 bits HEIF file, switch the bit depth of the current image loaded in editor to 16 bits color depth.

If your HEIF codec is compiled with more color depth support than 8 bits,  then target saved file will be encoded accordingly.

PS : It's the same for TIFF.

Best

Gilles Caulier

Hi Jurgen,

To know if your HEIF codec support 8 bits and more, go to digiKam Setup / Plugins / Loader and double click on HEIF entry.  This will open an About dialog for the plugin. Look on the description section. Mine from the 8.2.0 AppImage give this :

https://i.imgur.com/KOu2s0p.png

Gilles Caulier

Jurgen,

To know if JPEGXL is supported, the QImageLoader plugin must have an entry JCX in the mime-type section of digiKam Setup / Plugins / Loaders page.

JXL is optional and provided by the KDE Framework KImageformats. If it do not exists, it's a packaging problem in your Linux distro.

Best regards

Gilles Caulier

Thank you for your detailed reply. Here are my conclusions:

1. My systems are Debian Bookworm, libde265-1011-1

2. Your plugin tool says libde256 does only 8-bit but on GIT they say
   that libde256 does support HDR (which makes little sense with 8-bit).
   Where does the 8-bit limit come from?

3. There should be a warning when saving from a 16 bit workspace to 8-bit Heif

4. IM does HEIF 16 bit, why not using IM to load HEIF?

5. Saving from a 16-bit workspace should offer a way to select the depth.
   This is a feature request.
   I found that 10-bit depth is a good compromise between space and quality.

6. If DigiKam does not like to support 10-Bit Tiff (which is not standard
   but understood by IM) then try to reduce colors by masking away lower bits.

7. Currently Digikam offers limited 16-bit support, best for TIFF. Hopefully
   the future development will allow a wider support for HiColor and or HDR.
   
8. Your Image Loader Plugin architecture is quite nice, but for several
   reasons I would like to use IM codecs, but the IM Loader cannot be selected
   for HEIF, JPegXl ... ?

It seems that there is a long way to go for DigiKam to reach full HiColor/HDR
support. Until then I will continue to use intermediate 16-bit Tiffs and convert
to/from archive format (JPeg2000) via IM. 

Jürgen

24. Oktober 2023 04:35, bugzilla_noreply@kde.org schrieb:

> https://bugs.kde.org/show_bug.cgi?id=468609
> 
> --- Comment #10 from caulier.gilles@gmail.com ---
> Hi Jurgen,
> 
> To know if your HEIF codec support 8 bits and more, go to digiKam Setup /
> Plugins / Loader and double click on HEIF entry. This will open an About
> dialog for the plugin. Look on the description section. Mine from the 8.2.0
> AppImage give this :
> 
> https://i.imgur.com/KOu2s0p.png
> 
> Gilles Caulier
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

2. Your plugin tool says libde256 does only 8-bit but on GIT they say
   that libde256 does support HDR (which makes little sense with 8-bit).
   Where does the 8-bit limit come from?

libde265 must be compiled with more color depth support, else it's 8 bits per default.

3. There should be a warning when saving from a 16 bit workspace to 8-bit Heif

Create a new entry in bugzilla, not only for HEIF but other format supporting more color depth as TIFF or PNG.

4. IM does HEIF 16 bit, why not using IM to load HEIF?

Because IM is slower and we already use libheif directly. We also seen instability from IM with certain image formats. The avaialblility of IM under certain OS is not guaranty (ex, MacOS Macports only support 6.x version not the 7.x)

5. Saving from a 16-bit workspace should offer a way to select the depth.
   This is a feature request.
   I found that 10-bit depth is a good compromise between space and quality.

Create a new entry in bugzilla in this case.

6. If DigiKam does not like to support 10-Bit Tiff (which is not standard
   but understood by IM) then try to reduce colors by masking away lower bits.

Create a new entry in bugzilla in this case.

7. Currently Digikam offers limited 16-bit support, best for TIFF. Hopefully
   the future development will allow a wider support for HiColor and or HDR.

There is already a file in bugzilla about this topic, if i remember
   
8. Your Image Loader Plugin architecture is quite nice, but for several
   reasons I would like to use IM codecs, but the IM Loader cannot be selected
   for HEIF, JPegXl ... ?

It's due to performance and stability. HEIF use a dedicated loader, JPEGXL a KDE ImageFormat plugin. 

Gilles Caulier

Git commit 259f865fee3451c159d5234b9a33c5cc9af8c109 by Gilles Caulier.
Committed on 27/10/2023 at 10:29.
Pushed by cgilles into branch 'master'.

Bump libheif v1.15.2 for fix compatibility with libaom v3.6.0
Build heif in stage 1, not as rolling-release

M  +4    -4    project/bundles/3rdparty/ext_heif/CMakeLists.txt
M  +1    -0    project/bundles/appimage/01-build-host.sh
M  +0    -2    project/bundles/appimage/03-build-digikam.sh
M  +1    -0    project/bundles/mxe/01-build-mxe.sh
M  +0    -2    project/bundles/mxe/03-build-digikam.sh

https://invent.kde.org/graphics/digikam/-/commit/259f865fee3451c159d5234b9a33c5cc9af8c109