Hi John!
Thank you for your help. But I think, this isn’t the problem. This time (with only a few edited pictures) the database file was very small. With the old DxO Optics Pro and with DxO PL 1.x I have edited thousands of images and had never a behaviour like this. It’s always the same. I can edit the RAW files with all the tools of PL, but I can only change some filenames, then it stops. I have to leave the program and rename the files in Windows, then go back and do all the image changes again. When I open PL and change from the “PhotoLibrary” to “Customize” and then click into the grey area right next to the arrow under the filmstrip I can do this only one time. A second click doesn’t have any effect. Clicking left beside the arrow always works. And when I delete a group of marked images in the filmstrip the next image jumps to the left border. One “cursor left” brings it back to the middle of the visible row.
I have a quite normal Intel i-5 computer with 32 GB RAM, a Nvidia GeForce GTX 960 graphic card, Windows 10x64 1809, DxO PhotoLab 2 Elite, ViewPoint 3, Filmpack 5 and the presets from the DxO webpage installed - everything with standard settings. My complete system and all drivers are up to date.
I think the biggest change in PL is the new PhotoLibrary with the search tool. So maybe there is the problem.
I agree that this shouldn’t be the problem, per se, Ralf … but it might be useful to try as a workaround.
As long as you’re changing the the image-file AND the sidecar/.dop file in exactly the same way then you should not need to repeat all your changes.
If you’re not currently using sidecar/.dop files(?) - then I recommend that you turn-on this option in your preference settings (so that details of your corrections are being held outside of the database).
This will result in a sidecar/.dop file being created to hold details of the corrections you make to each image - - You will have a set of files looking something like this;
RAWimageFilename.raw - - AND - - RAWimageFilename.raw.dop … the 2nd of these is the sidecar file.
Now, exit PhotoLab and do your renames with whatever tool you prefer to use - - ensuring you keep exactly the same name for the main part of both files {image + sidecar} … That is, something like this;
NewRAWimageFilename.raw - - AND - - NewRAWimageFilename.raw.dop
Next, delete the database … see above for its location.
Finally, restart PhotoLab, and you should see all your renamed images - - along with their corrections (which will be automatically written back to a new version of the database).
Note : This suggestion is proposed only as a workaround … whilst Svetlana deals with the wider issue.
John, very detailed description.
I use *.dop files all the time and I have already tried to delete the database file.
Renaming the files in any tool outside of PL is not as easy as you write, because every *.dop file contains the names of the original RAW and JPG file. That’s the problem and the reason, why I can only do it in PL after editing the image itself. Otherweise PL would not find the correct file in the *.dop file and create a new one.
The files are readable with Notepad, but I’m not going to test this. I think this is too much unnecessary work.
Maybe for the meantime I go back to PL 1.x and wait for DxO’s solution.
I follow the process I described above just about every time I use PL. In fact, I’m right now in the middle of processing around 2,000 RAW files (from a recent trip to Sri Lanka) - with one of my steps involving renaming filenames with a numeric prefix to create a “story” told by the order/sequence of the images - - I have been doing this for (quite literally) years, with absolutely no problem whatsoever.
It does not matter that the the sidecar/.dop file contains the old/original RAW filename - - this will be automatically updated by PL. It matters ONLY that the main part of your RAW and sidecar files have exactly the same name - - AND that you close/stop PhotoLab BEFORE you rename the files.
If you have tried this in the past, and you encountered problems, then you probably had PL open/running at the same time that you renamed the {image + sidecar} files - - and this has high potential to cause problems (especially if you are renaming multiple pairs of files, and you’re using Windows FileManager to do so).
I encourage you to try the process (as described above) with a couple of test files {image + sidecar} … This should get you going again, until Svetlana addresses your wider concern.
If I understand issues (1) and (3) correctly, I have the same problems with PhotoLab 2. (1) or a very similar problem can be reproduced by simply minimizing PhotoLab and restoring it to full-screen mode while the currently-selected image is off-screen in the filmstrip. (Ticket #165353) The issue was confirmed by DxO on both Windows and Mac. (So far, no fix is planned.) (3) is easily reproduced on my computer - and I’ve seen at least one other report of it in the DPReview forums. Working in a folder with many images, go into the Customize workspace and click on the scrollbar under the filmstrip to advance it. I can advance it to the left - toward the first file in the folder. As described by the OP, it can’t be advanced to the right in this manner. Should I submit a support request for this, too? Or has this already been reported sufficiently? @sgospodarenko, would you please advise? Thanks!
I tested this, Greg - I found that, on restoration to full-screen mode, the currently-selected image appeared at far-left of the Image Browser … Which, I reckon, is a “good thing”.
I’ve just tested this one too - - Clicking either side of the scrollbar advances the Image Browser in the appropriate direction (to left or right). If, by “click on the scrollbar”, you mean holding and dragging it - then that works fine for me too (in Windows 10 environment).
HOWEVER, I’ve long given up on this approach (mainly because it interferes with the taskbar, which I have set to auto-hide … just my preference).
INSTEAD, I use the scroll-bar on my mouse - Scroll-up to advance right - and Scroll-down to advance left.
I find this to be much less fiddly and more precise.
No, sorry - when I say “click on the scrollbar … to advance it,” I mean click on the track to the left or right of the “thumb” or “handle” (the bar, I guess - I was thinking of the entire scrolling edge of the window as a bar, but I guess that’s not correct) to move it a whole page forward or backward. I don’t mean holding down the mouse button and dragging the bar/handle/thumb along its track. I hope that’s more clear - thanks.
I was just able to reproduce the problem (or maybe a variant of it) in two folders. I right-clicked on an image to open it in PhotoLab. Then I selected the Customize workspace. There, I could freely move the scrollbar in the filmstrip by clicking on its track. But then, I dragged the scrollbar a bit, either right or left, and could no longer move the scrollbar by clicking on the right side of the track. (Dragging it to the left more reliably causes the problem. Simply clicking once on the scrollbar without dragging it can also cause the problem.) I could move the bar by clicking on the track to the left of it - and that would restore my ability to click on the right-side track also. Dragging the scrollbar or clicking on it repeatedly stops the right-side track from registering mouse clicks.
Please try those steps and see if the problem can be replicated. Thanks.
Also, please note that I’m talking about the track alongside the scrollbar/thumb/handle, not the right and left arrows at the far ends of the scrollbar. Also, I have the problem regardless of whether or not PhotoLab 2 is full-screen.
I’m currently working on a folder with 100+ RAW files. I’ve just spent about a minute doing a random combination of scroll-bar dragging + clicks to left & right of the scroll-bar … and it consistently works fine for me.
By “scroll-bar” I mean the bar that one can slide left or right, at the bottom of the Image Browser.
Note: See my comment above re mouse-wheel scrolling … I find that method much easier (and it might circumvent your problem).
For me, mouse-wheel scrolling of the filmstrip is way too slow. I just drag the bar when I need to move it. Sometimes, I prefer to click on the track to move it a page at a time - but I’m getting away from that because of this glitch.
Well, I was able to reproduce your scenario when I first start PL. But it seems to me @Ralf_Brinkmann has a little bit different and can’t restore the ability to move.
You do not need to create a support ticket, I will create a bug by myself as soon as Ralf confirms his issue is a little bit different.
Thank you everybody for testing the issues and all the workarounds.
Svetlana, I don’t know if my problem is a very little different, because I have not tired all all possibilities.
I hate to use the mouse too much and like more keystrokes. So I try to reduce the use of the mouse to the most necessary. Unfortunately an image editor needs more mouse activities than other programs.
Relating to the issue no. 3 I can only say, that the click into the area right of the bar under the filmstrip works only one time, then no more clicks are accepted. Clicking on the left side works normal. It doesn’t matter how I open PL.
Relating to issue no. 2 (I’m just watching your video again): This happens only, when I mark more than one picture. Not if I delete only one single image (I don’t delete by mouseclick, I delete with shift-del).
And all these issues have never been there in all the versions before (DxO Optics Pro and DxO PhotoLab 1.x). They started with PL 2.x and the PhotoLibrary.
I assure you it will work (as explained here: Image rename explanation) - provided you’re careful to close/stop PhotoLab whilst you rename each pair of files.
We identified and fixed the issue #3 you mentioned (when the scrollbar was not working properly). It will be delivered in the next release
About your issue #1, when you said “jumpes to the left border”, you mean the first image in the filmstrip? The current behavior is we select the first image after the first deleted image and it was the same behavior in PL1. So if you select several images by scrolling, then the filmstrip moves to the first image when you delete the selection, it’s expected. Maybe you could provide us a video or screencast of the behavior you described in PL1.
About your issue #2, the only reason why we disallow the renaming of a file is when PL is exporting an image from this file. We never faced other issue with the renaming feature. When you have this issue, could you try to right click on the image and select “Rename file”. It will help us to determine if it’s an issue with the shortcut or the renaming command.
