Provide the option to use PhotoLab without a database

Would you be on Windows by any chance?

I ask because I just started poking around in the tables myself to look for dop and this isn’t what I see on Mac. The closest to an Items table is one called zdopitem, but I have yet to find anything in dop format. Mostly text seems to be in Apple plists.

Why PL would have different databases on Mac and Windows is a head-scratcher though. :thinking:

Yes.

Yes, indeed. I don’t see why a different database structure would be needed. Under Windows, this is an SQLite database and I access it using SQLite Expert Personal.

1 Like

SQLite on Mac as well.

$ sqlite3 DOPDatabaseV4.dopdata .tables | xargs -n 1 | sort
ZDOPBASESETTINGS
ZDOPCAFAMBIGUITY
ZDOPFOLDER
ZDOPHISTORYPOINT
ZDOPITEM
ZDOPKEYWORD
ZDOPLIST
ZDOPMETADATA
ZDOPSOURCE
Z_6PROJECTS
Z_7KEYWORDS
Z_METADATA
Z_MODELCACHE
Z_PRIMARYKEY

I see various posts about differences in functionality between Mac and Windows, and thought it was odd when I learned that workspace descriptions also differ between Mac and Windows (Apple plist on Mac, some other XML on Windows), but this is even more odd.

It must be a lot of work maintaining two versions of things that should be platform-independent …

Yes, this should be unified unless there’s a technical problem but it’s hard to see which one.

In Windows, I can see the following tables :

CafAmbiguities
Folders
Items
ItemsKeywords
Keywords
Metadatas
Projects
ProjectsItems
Sources
ConsolidatedRatingView

The table names you see on the Mac are like they are because they were generated from an object-oriented API called CoreData, which uses SQLite as a backend

2 Likes

Interesting. I don’t know the Mac environment but I always thought that DxO Optics Pro and DPL were using the same Microsoft . Net Framework platform (not entirely, though, since in its early years, DOP was using COM objects not available in the Mac environment).

Anyway, it’s surprising that the Mac version needs more tables than the Windows version. Or maybe SQLite Expert is hiding some tables.

This is working on Windows only. Not a Mac thing.

I guess it is hard to find a cross platform technology and at the same time wanting to optimise the software on each platform. To get the best you need to write software matching the hardware.
To be honest I got rid of Microsoft and Adobe on my Mac and can not be more happy to not have those ressources eating monsters away.

Sorry, this is wrong. The .Net Framework has been implemented for Windows, MacOS, Linux and Unix since a long time. I know, I have been teaching it for years. The specifications are public and it could be implemented on other platforms.

Oh okay then. Good to know.
(but happy it is not implemented on macOS)

You mean, “not used by the macOS version of DPL” ?

I am sorry Patrick, I do not have enough knowledge to go into details.

What I mean is that for me .net is a Microsoft thing that works best on Windows. Today we even talk about .net Core.
In my opinion this .net will (probably work on a Mac but) never replace an optimised version of PL written from the ground up with the best of macOS technical solutions. And to be honest, I do not want a Microsoft framework on my Mac :upside_down_face: ( I am serious, I am not being disrespectful… and I do not like to go off-topic here).

Affinity manage to get 100% feature parity between Mac and Windows with very performant software that is quite complex. It’s doable.

1 Like

I would agree with allowing PL to run without a database. I use it for batch processing from RAW which it does very well indeed. I have an older MacBook and internal storage is limited. My photos are on external drives. The database can grow and consume a significant amount of space and so needs to be regularly deleted. The sidecar files are sufficient for keeping the editing adjustments sorted.

I do not need nor use keywords in PL :slight_smile:

4 Likes

Good point Mark. Keywords should be stored in the XMP sidecar and not the DOP sidecar or the database. Keywording in Photolab should travel with the files to other applications (it does travel with JPEG exports, not sure about TIFF) but it would be better if they travelled with the RAW files as well.

History: the history database can be kept as history is non-essential information. The only issue is cleaning history when the files move around. The only way history would really work is if every file were given a checksum. When a file is reopened the checksum would be calculated and checked against all the entries in the database.

Keeping unlimited database entries for every time a folder is moved will create huge, slow databases. Deleting the database sounds like the best solution to scalability.

The database should be optional. I use FastRawViewer and these days PhotoMechanic in my workflow. Photolab is just one tool in the pipeline and Photolab shouldn’t interfere with an independent image pipeline but support it. If I wanted a fairly crappy jack of all trades app, master of none, with lots of compromises in cataloguing and processing, Adobe sells one. I need a first rate RAW development tool. Enjoying some of the retouching improvements though.

2 Likes

Instead of going either-or, we could simply

  • add a setting that allows the user to choose to purge the database when DPL quits -
    this setting would probably need to flush the cache too.
8 Likes

I agree with all this, except I don’t see a problem with an option to (also) keep keywords in the PL database, for those so inclined. But it’s essential that keywords be stored in the XMP sidecar and not the DOP sidecar, for compatibility with other applications.

3 Likes

Or in other words… just like Lightroom.

You can add me to the list of people who consider the database to be actively harmful. In my case, all it does is significantly slow down the opening of PhotoLab, unless I purge it periodically.

I rarely go back and re-process the same folder of images more than once, so there’s no benefit in keeping any sort of cache. If I do, I still lose more time due to the application taking longer to load than I ever would to re-scanning of any given folder of images.

Tagging and file management is not PhotoLab’s strong point, and unless the developers are intending to go all-in and write the DAM to end all DAMs, that needs to be the responsibility of an external application that’s actually up to the task (which in my case is IMatch). In fact, I actually find switching between the PhotoLibrary and Customize tabs in DXO to be annoying; Honestly, I’d much rather have a default view with the folder picker and editing tools on the same screen, so that I can just select the folder I’m working with, CTRL-A my images, and start editing without having to jump back and forth between tabs, but that’s because I treat DXO as a RAW developer. It’s great at that job, but I do the rest of my work elsewhere, and so want to be able to quickly get in, post-process some images, render them out as JPEGs, and get out again.

Keeping an edit history for image files might be of use to me occasionally, but that’d be better off in a sidecar file where it’s referenced only as needed, as opposed to in a database that slows down my workflow, and has no idea whether the files have been relocated to somewhere else on disk. My DAM can make sure that sidecar files follow my images from place to place. DXO is where I post process my images; It gets no information on what happens to my files after that.

I’m fine with leaving the database functionality in the application for users who need it, and I don’t mind it being on by default, but I think it’s time to get that out of the way for those of us that it hinders more than it helps.

4 Likes

Take a look at DxO PureRaw, it might just do what you need…

PhotoLab is very fast on my aging i7 Windows 10 machine. The database is not holding me back in any way. It would be nice however, if metadata, keywords, and history info could be saved to .xmp files as well as the database. All other edits are already saved to both the database and .dop files. .

It seems that you are only using PhotoLab as a raw converter. As @platypus pointed out, maybe the new DXO PureRAW software would meet you requirements better.

PureRAW modifies settings for chromatic aberration, lens distortion, vignetting, lens sharpness, and noise reduction. For noise reduction you can choose between HQ, PRIME, and DeepPRIME. If you have a supported graphics card, DeepPRIME will execute much faster using the card’s GPU.

PureRAw processes raw files automatically and settings in this version can’t be modified by the user. The output of PureRAw is in DNG and JPEG formats only. It doesn’t support TIFF exports in this version. Hopefully future versions will add the ability for users to modify settings similarly to PhotoLab and provide an export to TIFF.

Mark

1 Like