https://bugs.kde.org/show_bug.cgi?id=390580
caulier.gil...@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |caulier.gil...@gmail.com
--- Comment #4 from caulier.gil...@gmail.com ---
>7 I have been trying hard to make digikam crash in a similar way when
>working on jpg files, so far without success. Is threaded handling of
>tiff writing/reading organised differently than for jpg files?
About this point, the high level multi-threaded code is the same between JPEG,
TIFF, PNG.
Only the low level code delegate to the right system library the way to read
write data to target image, as libtiff, libjpeg, libpng, etc...
Another very important point is the metadata : for all image format, all is
delegate to libexiv2, which include a dedicated code for all image format.
We have no control these low level libraries implementation.
Exiv2 is a problematic part due to complexity of metadata to read write in all
cases from a large amount of very similary image formats (RAW for ex), but
different finaly.
About Exiv2 and multicore support (multithread running on multicore), i
writtten few mounth ago a unit test tool to scan my huge collection of test
images, without to find a crash while reading and writing metadata in parallel.
https://cgit.kde.org/digikam.git/tree/tests/dmetadata/metareaderthread.cpp
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
