[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #14 from caulier.gil...@gmail.com --- 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-4project/bundles/3rdparty/ext_heif/CMakeLists.txt M +1-0project/bundles/appimage/01-build-host.sh M +0-2project/bundles/appimage/03-build-digikam.sh M +1-0project/bundles/mxe/01-build-mxe.sh M +0-2project/bundles/mxe/03-build-digikam.sh https://invent.kde.org/graphics/digikam/-/commit/259f865fee3451c159d5234b9a33c5cc9af8c109 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 caulier.gil...@gmail.com changed: What|Removed |Added Platform|Other |Debian stable --- Comment #13 from caulier.gil...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #12 from J --- 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_nore...@kde.org schrieb: > https://bugs.kde.org/show_bug.cgi?id=468609 > > --- Comment #10 from caulier.gil...@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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 caulier.gil...@gmail.com changed: What|Removed |Added Version Fixed In||8.2.0 Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #11 from caulier.gil...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #10 from caulier.gil...@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 are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #9 from caulier.gil...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #8 from caulier.gil...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #7 from caulier.gil...@gmail.com --- @i...@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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #6 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #5 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #4 from Dan --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 Maik Qualmann changed: What|Removed |Added CC||metzping...@gmail.com --- Comment #3 from Maik Qualmann --- Can you provide a sample Canon HEIF image to test the change? My HEIF test samples still work with this patch. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609
Dan changed:
What|Removed |Added
CC||dkb...@tofubar.com
--- Comment #2 from Dan ---
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);
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 --- Comment #1 from caulier.gil...@gmail.com --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 468609] Loads heif only with 8 bits color depth
https://bugs.kde.org/show_bug.cgi?id=468609 caulier.gil...@gmail.com changed: What|Removed |Added CC||caulier.gil...@gmail.com Component|ImageEditor-Load|Plugin-DImg-HEIF -- You are receiving this mail because: You are watching all bug changes.
