<div dir="ltr">>The color management takes time to load, if you temporarily switch it off with F12 (On/Off) (Menu-> View), images will load even faster. You can test it to see if it works for you.<br><div><br></div><div>This really makes the difference! Cached versus non-cached is still noticable but not worth mentioning. Great.</div><div><br></div><div>Thanks a lot</div><div><br></div><div>Tonio (digikam 8.2 now)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 30, 2023 at 9:36 PM Maik Qualmann <<a href="mailto:metzpinguin@gmail.com">metzpinguin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The color management takes time to load, if you temporarily switch it off with <br>
F12 (On/Off) (Menu-> View), images will load even faster. You can test it to <br>
see if it works for you.<br>
<br>
Maik<br>
<br>
Am Freitag, 30. Juni 2023, 16:37:01 CEST schrieben Sie:<br>
> With digiKam-8.1.0-20230628T051819-x86-64.appimage I get Memory available<br>
> 62.4 GiB and Image cache size 1.0 GiB.<br>
> <br>
> Behavior is now exactly how you describe. Next image is shown very fast,<br>
> immediately clicking next again results in longer delay.<br>
> <br>
> For sorting my "family photos" I am absolutely happy with that behavior.<br>
> And actually this is my main task :-)<br>
> <br>
> When I curate my birding pictures more caching maybe would make sense.<br>
> Birding in my case means I have bursts of photos, often several hundret<br>
> very similar pictures. Typically I delete all but 1%. I do this by skipping<br>
> through the pictures in 100%-view.<br>
> <br>
> Best wishes and thanks for this great software!<br>
> <br>
> Tonio<br>
> <br>
> <br>
> <br>
> On Tue, Jun 27, 2023 at 12:41 PM Maik Qualmann <<a href="mailto:metzpinguin@gmail.com" target="_blank">metzpinguin@gmail.com</a>><br>
> <br>
> wrote:<br>
> > Again to make sure our DMemoryInfo class is working correctly. Please see<br>
> > the<br>
> > digiKam component info dialog. How much memory is shown as available on<br>
> > your<br>
> > system?<br>
> > <br>
> > Maik<br>
> > <br>
> > Am Montag, 26. Juni 2023, 22:07:06 CEST schrieb Tonio Kroeger:<br>
> > > WAAAAAHHHHHHHH! :-) Yes 64GB. And now everything makes sense. Moreover I<br>
> > > had a try with: digiKam-8.1.0-20230617T074456-x86-64.appimage<br>
> > > The difference is tremendous. Thanks a lot!<br>
> > > <br>
> > > Tonio<br>
> > > <br>
> > > On Mon, Jun 26, 2023 at 6:42 PM Maik Qualmann <<a href="mailto:metzpinguin@gmail.com" target="_blank">metzpinguin@gmail.com</a>><br>
> > <br>
> > wrote:<br>
> > > > Is the specification of 64GB for the memory correct?<br>
> > > > With this size, we calculate the image cache incorrectly, only a very<br>
> > > > small<br>
> > > > cache is created, so no larger images are preloaded in the preview.<br>
> > > > The<br>
> > > > problem will be fixed in digiKam-8.1.0.<br>
> > > > <br>
> > > > Maik<br>
> > > > <br>
> > > > Am Montag, 26. Juni 2023, 18:12:19 CEST schrieb Tonio Kroeger:<br>
> > > > > Hi all,<br>
> > > > > <br>
> > > > > I am an enthusiastic digikam user for nearly 20 years now!<br>
> > > > > <br>
> > > > > I am running 8.0.0. on an I7 under Linux with plenty of RAM (<br>
> > <br>
> > <a href="https://www.intel.com/content/www/us/en/products/sku/205608/intel-nuc-11-p" rel="noreferrer" target="_blank">https://www.intel.com/content/www/us/en/products/sku/205608/intel-nuc-11-p</a><br>
> > <br>
> > > > ro><br>
> > > > <br>
> > > > > -mini-pc-nuc11tnkv7/specifications.html). My picture collection<br>
> > <br>
> > became<br>
> > <br>
> > > > huge,<br>
> > > > <br>
> > > > > about 8TB (also many RAW files, roughly 300.000 Jpegs), and I still<br>
> > <br>
> > use<br>
> > <br>
> > > > > SQLLite for the database.<br>
> > > > > <br>
> > > > > In general everything works fine but when I switch to another<br>
> > > > > picture<br>
> > > > <br>
> > > > this<br>
> > > > <br>
> > > > > takes up to 3 seconds. This is very anyoing especially when sorting<br>
> > <br>
> > out<br>
> > <br>
> > > > > pictures. For the latter purpose I store incoming pictues on the<br>
> > > > > internal<br>
> > > > > SSD but this leads exactly to the 3 seconds from above, external<br>
> > > > <br>
> > > > USB-drive<br>
> > > > <br>
> > > > > is worse but not as worse as I would expect. I tried to precache all<br>
> > > > > pictures into RAM, that did not significantly help. When I lower the<br>
> > > > > maximal CPU frequency this seems to scale linearly with the time to<br>
> > <br>
> > show<br>
> > <br>
> > > > a<br>
> > > > <br>
> > > > > new picture.<br>
> > > > > <br>
> > > > > Over the years my pictures became larger and larger. Today I have<br>
> > <br>
> > Jpegs<br>
> > <br>
> > > > > around 20MB. (5MB Pics from my IPhone show up very fast.)<br>
> > > > > <br>
> > > > > I wonder whether someone can give a hint where I might have an issue<br>
> > > > > with<br>
> > > > > my system. Is SQLLite a problem in my setting? Or are the 3 seconds<br>
> > <br>
> > just<br>
> > <br>
> > > > my<br>
> > > > <br>
> > > > > fate because of the many megapixel...<br>
> > > > > <br>
> > > > > Best wishes & tnx<br>
> > > > > <br>
> > > > > Tonio<br>
<br>
<br>
<br>
<br>
</blockquote></div>