Correction preview rendering every time I look at an image

I searched the forum but I did not see a solution or a clear answer to this.

I have the basic DxO preset enabled upon opening a new image. I select the image and the program calculates a preview. Takes about 3 seconds on my computer. I select another image the program calculates the Correction Preview for that image. I now select the previous image and I have to wait all over again even though there were zero edits.

I got sick of this so I tried applying the preset to an entire folder of images so I would not have to wait the 3 seconds every single time. No difference. It is as if the program has no preview of that calculation at all. no memory of the image. It makes culling in DxO so slow that Windows Explorer is actually considerably faster; Even when PL has no edits applied.

I also notice that when I set the default preset to No Corrections and then process the images I have to go over them at least once till the uncorrected images are what come up right away. And then moving forward scrolling through the images the little “processing animation” spins for around three seconds even though it is apparently doing nothing other than opening a RAW file.

My video card is a Radeon RX 580 with 8 gigs of ram. Not the fastest but still hitting the minimum requirements. As far as I can tell there is zero demand being put on the card in any way. No use of the ram, or the processing power. I am confused why I have 8 gigs of RAM on that going to waste. I have 16 gigs of DDR 1333 half of which is getting used. I can’t get my CPU to go over 60% usage.

My images are on an SSD, my cache is on a different SSD to ensure there is no bottleneck at the drive level. My database is on the same SSD as the cache. But I can’t see how wringing a few lines of text to a file would slow anything down.

Can someone advise as to what is going on here? Is there a fix for this?

Whether you have applied a preset or separate edits, every time you switch selection, PL has to recalculate the preview because it is not something that is easily cached.

Using PL for culling has never been and is not recommended since it always calculates the full corrected preview.

Rendering a preview is much more than reading any adjustments from the DOP file or database. All those adjustments then have to be applied to the displayed image.

Not forgetting that, for RAW files, the RAW data also has to be translated into the bitmap you get to see.

1 Like

Sometimes, the previews do eventually get cached - if you go back and forth between images enough times. But the behavior is so inconsistent. Some previews cache right away while others seem to never get cached. Same file types, no edits except for default presets. I agree, this is a bug. It has been reported previously, and changing cache size didn’t help.

1 Like

It’s not truly a bug because it’s not intended behaviour that isn’t working as designed, it’s just behaviour that is not optimal.

@UnclePapiPicante

Afaik, caching works in Compare mode only.


comparing VC1 with Master (M) // more options with No corrections or Output → JPEG in this case

And yes, it could be improved, e.g. for the last used nn pics of the opened folder.

1 Like

How sure are you, Joanna? I’d like to hear confirmation from DxO staff, as they’ve indicated to me before that the previews should get cached.

That may well be the case, but even caching takes time to write and read back, and frequency and speed will depend on factors like file size, available memory and computer performance. Then the question of how many thumbnails should be cached, which is going to depend on what size the thumbnails are being shown at and how many are visible, plus how many do you read ahead for when the user scrolls new thumbnails into view.

Ah. I was referring to the full-size preview in the image viewer, but see now that this topic has more to do with the thumbnail previews in the image browser. If that’s the case, then my earlier comments don’t really apply as I’ve not interacted much with DxO about the thumbnails.

Hi Joanna
Thank you for your thorough response. I appreciate you taking the time. I also want to take a moment to let you know how much I appreciate the no B.S. response. It is very refreshing to get direct answers about things. Even if the answer is telling me that the program is simply not good at something I am wanting it to do.

Using PL for culling has never been and is not recommended since it always calculates the full corrected preview.

Perfect answer. Now I can try and find a program that is good at that task if I so choose. It’s great that DxO has chosen to be transparent about what the program is and what it is not. The norm seems to be to tell the end-user how great the product is regardless and then say it will be improved in an update that will never happen.

What you said got me thinking.

Rendering a preview is much more than reading any adjustments from the DOP file or database. All those adjustments then have to be applied to the displayed image.

Not forgetting that, for RAW files, the RAW data also has to be translated into the bitmap you get to see.

Now I am going to contradict myself and try to change the program to be what I want it to be! :joy: If DxO has to produce a bitmap/thumbnail when it shows me the result of the edited image why is that not just cached? Update that file when an edit is made and keep that in the cache. In this day in age buying a second SSD or having a massive amount of RAM feels very inexpensive when you are as old as I am. Let’s say I have a dedicated SSD for DxO cache. Let DxO create a cache that is large enough that there can be an associated bitmap/thumbnail for every single image that I have opened even once in DxO over the last 6 months let’s say. Why would this not be possible? I read your reply to Egregius about the process of creating the cache and how it is complicated for the cache to make satisfying decisions around what is cached and what is not cached. What if all it had to do is to run a command at startup to delete any bitmap/thumbnail older than a certain number of weeks/months?

1 Like

This is very helpful in some situations! Thank you for mentioning this :+1:t3:

1 Like

Hey
I understand that PL is not intended for fast culling. Is there a program that DxO is suggesting to use with PL for best compatibility? Or do you personally have any recommendations?

Quite a few PL users are using Fast Raw Viewer for culling images - mainly because it renders the actual RAW file (rather than just the JPG file embedded within).

John M

1 Like

Thank you very much for the tip! Have been checking it out and it’s great. And the price makes it an easy choice.

1 Like

Thanks again John-M. I bought it.

After using it to go through my 2020 and 2021 catalogues I would consider it a must-have if you’re ever tasked with going through a considerable number of photos.

After a great recommendation came my way I was inspired to try and give back to the forum a little with this post. I hope people find it useful. If anyone thinks this should be in a different post please let me know and I will move it. All the best everyone.

I would like to briefly share what I just learned this past week going through three DAM programs. I tried digiKam, ACDSee’s Photo Studio Home, and IMatch. Essentially my main criteria were, something that I could get going with very quickly, ideally have facial recognition that was at least “acceptable”, tools for renaming, tools for batch file conversion, and powerful tools for finding duplicates.

The short reviews go something like this…

To get to the ending upfront digiKam won for me. It is very boring to look at, with a familiar standard toolbar up top and two side panels with tabs that are clearly labelled. It is responsive and generally feels light to use. It presents images VERY fast. Almost as fast as FastRAW in some situations. But not enough so that I would not buy FastRAW again. The facial recognition element of the program is straightforward to use in my opinion but there is no way to just have it automatically run on import, or have it just on all the time working when the program is not in heavy use for example. It has powerful batch processing tools that include adjustments from the rather extensive (but not so usable for professional work) photo editor that is built into it. The tools for finding images are impressive from my limited experience with photo DAM programs. For example, draw a sketch to find a photo? Find similar images based on appearance? Find duplicates regardless of the naming? Perhaps that last one is in all of these programs but I was able to find these features quickly. The help file that comes with it is obviously written by programmers and users seeing as it is an open-source program, but I was able to find all the information I needed very quickly.
An added bonus to this program is that it is free to use! And the community is active. They suggest a donation of thirty dollars if I remember correctly. I small price for this program and completely of your choice. Pretty amazing.

IMatch is obviously a serious program. Serious programs can take some serious time to learn well. It felt like a slog in my situation even with the built-in help window that was very thoughtfully right upfront. I found the layout and interface in general very confusing upon first trying to get going with it. I am not new to software, I have used a lot of GUI’s in the 27 years I have been working intensely with software; I was simply not willing to invest the time in getting comfortable with it for the fairly simple tasks I need to do. And it is the most expensive option. So a presumably great program, way too much program for me.

ACDSee felt clunky and underfeatured compared to both the other options as a DAM. So in fairness, I only gave it a few hours.

I know this is not about DxO software but to the admission made in this post DxO is not designed for culling images, and although I understand it has made some substantial improvements to its library in version 5 it, in the same way, is not a program dedicated to being a library. It has a fantastic library but it is not the program’s primary focus.