https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
Version Fixed In||7.5.0
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #42 from Maik Qualmann ---
Yes, I had a test last night with the AppImage and my native version, which is
compiled with release. I was amazed that the times were the same. Other
functions are much faster with my release version...
Maik
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #41 from caulier.gil...@gmail.com ---
Tim,
In fact, I found the problem. libx265 must be compiled with "-pmode" option to
enable parallelism computation. And with MXE x265 package, this option is not
present :
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #40 from caulier.gil...@gmail.com ---
In fact libx265 use WPP not OpenMP to parallelize :
https://x265.readthedocs.io/en/default/threading.html
I never hear about WPP before. Another brick on the wall...
Gilles
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #39 from caulier.gil...@gmail.com ---
Maik,
Just a note: I build a 64 bits version without debug symbols of Windows
Installer. Of course, this reduce the file size a lots, but this have not
effect of execution speed. why ? this is simple :
https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #37 from tlteebken-...@outlook.com ---
Ok that makes sense. It's fine with me then if you want to close this bug, I'm
not sure what else you can do in Digikam. Like I said, only suggestion I
have--as a general alert to users--is just let
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #36 from caulier.gil...@gmail.com ---
In fact the libheif API do not provide any progress info while encoding. Only
the loop for pixels formatting to be encoded as x265 is handle in DK code and
has progress info of course. This is what you
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #35 from tlteebken-...@outlook.com ---
Well some more good news: I did a fresh uninstall/reinstall of the Gimp
2.10.14 bits and the Microsoft codecs. Now Gimp is working perfectly, I can
save images in heic format with no error.
So the
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #34 from caulier.gil...@gmail.com ---
Git commit 36746afbad134a47524ff9ad70c611c1b2c488fa by Gilles Caulier.
Committed on 04/01/2020 at 05:55.
Pushed by cgilles into branch 'master'.
add debug trace to print elapsed time to encode as HEIF
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #33 from tlteebken-...@outlook.com ---
My input files that repro this behavior are 16-bit, whether in CR3 or DNG
format.
Canon Camera: EOS M6 Mark II (support just added in libraw, including CR3)
Here's the cross-reference bug I
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #32 from caulier.gil...@gmail.com ---
Q: the CR3 file imported to image editor is decoded in 8 bits or 16 bits color
depth ?
Also, which kind of Canon camera do you use exactly ?
Gilles Caulier
--
You are receiving this mail because:
You
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #31 from caulier.gil...@gmail.com ---
Ah it's insterresting.
Same here, HEIC encoding is slow.
I never tested with CR3. I will do it tomorrow.
About to drop debug symbols, i can do it easily as it just an option to turn
off in bundle
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #30 from tlteebken-...@outlook.com ---
To follow up on an earlier comment in this thread from Gilles:
* Would one of you guys please report this bug to the developers of the library
that is involved with saving Heic? I would do it, but I'm
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #29 from Maik Qualmann ---
I also noticed that the Windows packages load and save images very slowly.
This could be due to the option set to teach MinGW C++11. At the company
today, I was also amazed at how long it took to save a small
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #28 from tlteebken-...@outlook.com ---
I can't (it was a CR3 file that I had just 'imported' using the RAW editor, the
source file is over 35MB).
Possibly helpful additional details to know:
* Tested with several other CR3 RAW files, same
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #27 from caulier.gil...@gmail.com ---
Can you share the original image that you try to export to HEIC. I would to try
to reproduce the dysfunction here.
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #26 from tlteebken-...@outlook.com ---
I waited 5 minutes.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #25 from Maik Qualmann ---
How long did you wait to save? It is significantly slower under Windows until
the encoder is finished, but it will be finished. Another thing, Gimp works
here on a Windows 7 machine even when saving a HEIC file.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #24 from tlteebken-...@outlook.com ---
On today's build, I get the same behavior as yesterday. No error message, and
file does save as .heic format. But Digikam editor is frozen in mode saying
"Saving74%". And I am unable to close
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #23 from caulier.gil...@gmail.com ---
Tim,
Windows bundles will be updated this morning at usual place :
https://files.kde.org/digikam/
Please let's me hear if the problem remain. Thanks in advance...
Gilles Caulier
--
You are
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #22 from caulier.gil...@gmail.com ---
Tim,
My failback to 8 bits color depth under Windows 10 work as expected here. I
just tested with the Windows installer generated today. I just created an HEIC
from a JPEG file :
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #21 from tlteebken-...@outlook.com ---
Thank you for the discussion and work on this bug!
Just ran the latest bits, same steps as before.
Result:
* The heic image does save to the file system without an error, in spite of the
next item.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #20 from caulier.gil...@gmail.com ---
Windows bundles will be updated in one hour at usual place :
https://files.kde.org/digikam/
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #19 from caulier.gil...@gmail.com ---
Git commit 9c13bc8a534a99772d63122115c75e76302c3645 by Gilles Caulier.
Committed on 01/01/2020 at 15:56.
Pushed by cgilles into branch 'master'.
fail back to default 8 bits encoding if max byte depth is
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #18 from Maik Qualmann ---
[5332] Check HEVC encoder for -2071058945 bits encoding...
[5332] Cannot get max supported HEVC encoder bits depth!
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #17 from Maik Qualmann ---
It was a very large negative number, I will start the VM again right away. It
also looks to me as if the variable is not being initialized. If I understand
the doc correctly it happens at compile time.
Maik
--
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #16 from caulier.gil...@gmail.com ---
MAik,
Look like how MXE build libx265:
https://github.com/mxe/mxe/blob/master/src/x265.mk#L19
There is plenty of versions, with different bit depth and also HDR support.
Incredible...
So,
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #15 from caulier.gil...@gmail.com ---
Maik,
Which negative value do you see exactly on debugview about max bit depth ? -1,
-2, -3 ?
Gilles
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #14 from caulier.gil...@gmail.com ---
Maik,
This is the cmake rule for bit depth :
https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/CMakeLists.txt#lines-369
As you can see the top level cmake
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #13 from caulier.gil...@gmail.com ---
Maik,
The code to tune max bit depth at configuration time is this one :
https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/common/version.cpp#lines-98
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #12 from caulier.gil...@gmail.com ---
Maik,
How this is possible :
https://bitbucket.org/multicoreware/x265/src/52135ffd9bcdd32b944311e9e66c473894c0a2bd/source/x265.h?at=default#lines-1965
8 (default), or 10...
Gilles
--
You are
https://bugs.kde.org/show_bug.cgi?id=415719
Maik Qualmann changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Latest
https://bugs.kde.org/show_bug.cgi?id=415719
Maik Qualmann changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #10 from Maik Qualmann ---
The build for Win64 cannot contain the change yet, wait for tomorrow.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
tlteebken-...@outlook.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #8 from caulier.gil...@gmail.com ---
Daily bundle are published in this repository:
https://files.kde.org/digikam/
digiKam and Gimp must certainly use the same HEIF codec : libx265.
In digiKam the error come from this libray that we use
https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
Latest Commit||https://invent.kde.org/kde/
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #6 from Maik Qualmann ---
This value (x265_max_bit_depth) returns 8 bits for me, instead of the loop -
then saving heic works.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #5 from caulier.gil...@gmail.com ---
The error come from this loop :
https://invent.kde.org/kde/digikam/blob/master/core/dplugins/dimg/heif/dimgheifloader_save.cpp#L69
... where the max bit depth available to encode to x265 try to be
https://bugs.kde.org/show_bug.cgi?id=415719
--- Comment #4 from Maik Qualmann ---
The AppImage works. In my native digiKam version is libx265-3.2.1 installed
from a non-free repository.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=415719
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #3 from Maik
https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
Summary|Digikam cannot save images |digiKam cannot save images
https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=415719
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
--- Comment
45 matches
Mail list logo
