@SchorschGaggo
This post covers
A. The PureBasic program that passes ‘External Selection’ to PhotoLab
B. Other DAM or editing or viewing programs that use SQLite databases and the potential implications of such databases with large numbers of images.
C. A summary of a proposal of mine to split the Discovery, Import and Render processes in PhotoLab. Increased control but at the expense of slightly increased complexity.
D. An urgent request to change the current preview options and make them so they can be applied to any image at any time but on demand, not limited to selection by the ‘Preferences’
ItemA:-
Hopefully my program now works as it should, I think, and you or any forum user is welcome to a copy of the code if you think that would help in any way!
It was originally written as the back-end of a program to scan DOPs to locate images in a directory that had no keyword assigned.
Rather than producing a list of those images, which is better than nothing, but only just, I decided that the best route was to “feed” the images back into DxPL as an ‘External selection’ and the receiving program (PhotoLab) would then do “the heavy lifting” automatically. Hence, the program I used here was developed as a prototype to test out that part of that bigger program.
An improved version was also created to allow a user (actually me) to select the directories used rather than “hard wiring” them into the program, that version now needs to be brought inline with the one I used to produce this User log file and was only created as an opportunity to develop my PureBasic coding to handle user interaction
20251018_093808.txt (58.7 KB)
Currently the delays in the program between batches is too long and the batch size of 100 is way below what the OS will allow which is over 400 for the images used in the test. The space is governed by the OS, hence the full length of the directory names and the length of the file name itself will determine the exact number of file entries that can be included in a single pass, i.e. it is a bit of a “guessing game”.
However the program was intended only as a means to an end and not an end in itself!
I “dragged” it into this topic only to see if it would help shed any light on the way that images can be (or are being) passed from one program to another, and I believe that it achieved that purpose.
Item B:-
My choice, as ever, is FastRawViewer for a cheap, easy to use program which is not phased by thousands of images, 7,000 in my test (12,993 in my latest version, and it is on offer offer until the 19th October (today!, this post has remained unpublishedfor too long). I do not get any commission but have found the developer willing to listen to polite suggestions.
That is also true of the IMatch developer but there is a biggish jump in price and for just selecting a handful of images from a large directory, rather than managing all the images in that directory, an image viewer is typically cheaper in cost and time and preferable to a DAM for that simple task.
I have used XnView and XnVieMP for many years, and FastStone Image viewer for even longer. I think that XnViewMP has always imported image thumbnails into a physical SQLite database and in the later releases of FastStone Image Viewer it has started to do the same but it has made FSIV very slow complete its discover and “import” as a result, albeit that is actually a background process.
I tested Photo Mechanic and Photo Mechanic Plus some years ago and no longer have access to those products to make any new tests.
But essentially if PL9 has to import all those images into a database and then render the thumbnails, then at least part of that exercise is going to be repeated by all the products that have SQLite databases e.g. LightRoom, Capture One., Photo Supreme, Photo Mechanic Plus, Zoner, PhotoLab, IMatch, DigiKam, XnViewMP, and ACDSee but that uses its own database product which I believe is a variant of DBase.
Actually, that is not entirely accurate because a number of them use the import process or the edit process to actually cause the image data to be entered into a database.
I am not sure about ON1 and Luminar Neo but Google indicates that they both have databases.
FastRawViewer doesn’t have any physical database, as far as I can tell and neither does Photo Mechanic but I suspect they may use some memory based database, which is possible with SQLite and might account for why PM went from PM to PM plus so easily, but that is just guess work on my part.
It is suggested that Adobe Bridge uses SQLite to manage its cache but not to handle image data in the way that Lightroom does.
So you “pays your money and you takes your choice”, or not as the case may be.
Item C:-
As for any changes in DxPL, I wrote a “proposal” for a system that would split the actual import process from the discovery process and split the render process from the import process back in the days when DxO actually interacted with the forum.
But I never published it as a post.
DxO seem to react negatively to anything they consider encroaches on their design for their product. Plus the proposal added to the decisions and interactions that the user needed to make, although I proposed a couple of preferences that would retain the current scheme. Given that DxO seem to object to suggestions for a change from customers then suggesting that the ‘Preferences’ be changed always seemed to be “sacrilege”.
However, perhaps the coming of AI and the burden that it is placing on the user kit available means that such a scheme may have a place after all.
So “discovery only” would do just that and would allow PhotoLab to be used like a classic viewer, whereas it currently discovers and imports and applies the DOP edits, if a DOP exists, or the default preset, If the one assigned actually does anything, and renders automatically versus the specific, selective import procedure of LightRoom.
Originally I was drawn to the automatic process of PhotoLab and “hated” the import process of LightRoom. For most of my work with directories (folders) of no more than 500 images the automatic process is fine, or rather it was before the addition of AI and the slowdown that rendering images with AI encounters.
But for users with potentially thousands of images the approach I am suggesting above of splitting the steps into separate user controllable processes i.e.
- Discover directories but mark thumbnails for any images that already have DOPs or are in the database with edits. ‘Filter’ by images already with DOPs or in the database. Not adding to the database currently means no searching etc.
- Import individual or selected or all images from a directory, on demand
- Render imported images, i.e. individual or selected or all images from a directory, on demand
This would allow users with more limited machines to continue to use all the facilities of PhotoLab including AI, when DxO have properly sorted out the problems with AI processing (of course), without necessarily needing to start budgeting for new kit or moving to or back to an alternative product.
Item D:-
In the meantime DxO have kindly implemented a way of viewing a better rendition of the final image but “buried” the option in the ‘Preferences’ so it applies to all images or none.
Those options should be available for users to toggle on and off on a per image basis or left active i.e. in exactly the same way that the ‘Loupe’ can be managed.
DxO got it right with the Loupe and then failed with the preview options!?