https://bugs.kde.org/show_bug.cgi?id=426086
--- Comment #2 from k...@binkmail.com --- Bit hard for me to tell what is going on especially when it is easy to have these files in the system disk cache which hides the problem and difficult to know it is in the cache. Seems to be related to additional layers saved in photoshop and possibly in particular smart object layers. I took a 20 M pixel 16 bit tiff file which was about 100MB. Loaded in photoshop, duplicated the background layer, turned that layer into a smart object and applied a simple filter then saved the file as tiff. The file size increased by about 600MB and it chokes digiKam but nothing else. I guess digiKam is slowly reading the large extra elements it doesn't need to. The problem files are huge. This is a tiffdump of one: Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 8 (0x8) next 0 (0) SubFileType (254) LONG (4) 1<0> ImageWidth (256) SHORT (3) 1<3109> ImageLength (257) SHORT (3) 1<4663> BitsPerSample (258) SHORT (3) 3<16 16 16> Compression (259) SHORT (3) 1<8> Photometric (262) SHORT (3) 1<2> Make (271) ASCII (2) 10<Panasonic\0> Model (272) ASCII (2) 6<DC-G9\0> StripOffsets (273) LONG (4) 84<26978 985968 1957330 2933846 3906524 4887716 5874280 6864180 7862052 8865962 9875066 10882740 11884212 12894074 13906004 14919378 15934402 16947186 17960762 18976602 19997708 21021120 22044318 23069588 ...> Orientation (274) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<3> RowsPerStrip (278) SHORT (3) 1<56> StripByteCounts (279) LONG (4) 84<958990 971362 976516 972677 981192 986563 989900 997871 1003909 1009104 1007673 1001471 1009861 1011929 1013374 1015023 1012783 1013576 1015839 1021106 1023411 1023197 1025270 1028923 ...> XResolution (282) RATIONAL (5) 1<72> YResolution (283) RATIONAL (5) 1<72> PlanarConfig (284) SHORT (3) 1<1> ResolutionUnit (296) SHORT (3) 1<2> Software (305) ASCII (2) 31<Adobe Photoshop 21.2 (Wi ...> DateTime (306) ASCII (2) 20<2020:07:11 04:08:26\0> 700 (0x2bc) BYTE (1) 17251<0x3c 0x3f 0x78 0x70 0x61 0x63 0x6b 0x65 0x74 0x20 0x62 0x65 0x67 0x69 0x6e 0x3d 0x22 0xef 0xbb 0xbf 0x22 0x20 0x69 0x64 ...> 33723 (0x83bb) UNDEFINED (7) 31<0x1c 0x2 00 00 0x2 00 00 0x1c 0x2 0x37 00 0x8 0x32 0x30 0x32 0x30 0x30 0x32 0x30 0x39 0x1c 0x2 0x3c 00 ...> 34377 (0x8649) BYTE (1) 8058<0x38 0x42 0x49 0x4d 0x4 0x25 00 00 00 00 00 0x10 0xcc 0xf3 0xa8 0x58 0xb9 0xcd 0x3f 0xd2 0x8e 0xcd 0xc9 0x50 ...> 34665 (0x8769) LONG (4) 1<84116084> ICC Profile (34675) UNDEFINED (7) 560<00 00 0x2 0x30 0x41 0x44 0x42 0x45 0x2 0x10 00 00 0x6d 0x6e 0x74 0x72 0x52 0x47 0x42 0x20 0x58 0x59 0x5a 0x20 ...> 37724 (0x935c) UNDEFINED (7) 502520192<0x41 0x64 0x6f 0x62 0x65 0x20 0x50 0x68 0x6f 0x74 0x6f 0x73 0x68 0x6f 0x70 0x20 0x44 0x6f 0x63 0x75 0x6d 0x65 0x6e 0x74 ...> is the 37724 at the end a 500MB tag that tiffdump doesn't know? If so I guess that is what digikam has to be reading at 4MB/s to take so long. -- You are receiving this mail because: You are watching all bug changes.
