[Digikam-devel] [Bug 307602] Large TIFF files crash digiKam (>1Gb)
Marcel Wiesweg
marcel.wiesweg at gmx.de
Fri Oct 19 08:34:33 BST 2012
https://bugs.kde.org/show_bug.cgi?id=307602
--- Comment #34 from Marcel Wiesweg <marcel.wiesweg at gmx.de> ---
If we change the data layout of DImg, we need to adapt everything access the
image data, most notably the image filters. It's a bit of work, but possible.
I believe the path to choose would be to encapsulate the added complexity in an
iterator class:
The underlying data storage in memory is intransparent through the DImg class.
The method returning an uchar* are removed, instead they return an Iterator
class. This iterator offers a few accessors:
uchar* row(int r), uchar* operator[](uint byte). This must be very carefully
designed as it has enormous performance impact. I believe Krita has adopted a
similar scheme, dont know how complex it is implemented.
Regarding in-memory compression, which also requires an extra access layer like
described above, there are well-suited algorithms available, most notably LZO:
http://www.oberhumer.com/opensource/lzo/
We would need to verify that this algorithm is also well-suited for our special
case of uncompressed, natural image data.
For both tiling and in-memory compression, we'd need to support inside the
implementation to use it or not use it for a DImg, depending on the use case
(small image vs. very large image, larger image but loaded to image editor,
smaller image but stored in cache etc.)
Interesting project, and needs benchmarking all along the way.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Digikam-devel
mailing list