The last thing I want is software that modifies raw files.
For one, these aren’t documented formats, and even if most of them are more-or-less TIFF, there’s no knowing what damage buggy software can do. Sidecars exist for a reason.
For two, modifying the raw would mean having to backup these largish files instead of small sidecars. That has a big impact on incremental backups, which is the reason I detest Lightroom’s refusal to write sidecars for DNG and TIFF files.
Otherwise, I think the DAM features in PL are a bad fit given DxO’s approach to backwards compatibility. Every PL upgrade has introduced changes in the way existing edits have been rendered after the upgrade; that is, do work in your existing version of PL to arrive at a rendering you’re happy with, upgrade, and then see that the rendering in the new version of PL isn’t identical. The changes have been small (eg. I had blue skies that were a little more saturated in PL3 compared to what I edited in PL2), not all images are affected, and I’m sure that DxO tries to minimise the changes, but it’s seemingly best effort rather something like a process version you find in C1 and LR (for two). If I have to export my images to retain my current rendering then PL is a tool for producing raster files, not for maintaining edits across a number of software upgrades.
If PL is going to become a more full-featured DAM, then respecting the rendering of edits performed in previous versions of the software is a prerequisite IMO.
Unfortunately, I don’t think the folks behind PL see their product as a full featured DAM. It would be nice and something that I would like if no no other reason than to have 1 product that does a great job in editing and managing of photo assets.
That being said your comment about upgrades to PL not respecting prior version edits (rendering) is definitely something to be concerned about, and that is where PL will most likely focus their limited resources if this is the case.
I still believe though that improvement in handling keywords along the lines I suggested .should be easily doable considering the basis is already in PL, and retaining the keywords within any file type and being able to see them regardless of what editor a picture is passed /exported to, would put PL in a good position to expand on DAM capabilities in the future.
I’m not holding my breath based on previous threads where this has been discussed: DxO either doesn’t want to acknowledge the problem or thinks that trying to patch issues as they arise is good enough. It is if you just use PL to export raster files and don’t necessarily expect the rendering to be unchanged when you revisit the image in a future version of the software, but I’m not so sure that this is what many expect when they start seeing features that remind them of Lightroom.
Like Keith I use Photo Mechanic for keyword management, and activating XML sidecars in PM integrates with PL for raw files.
However I’d like to see PL reciprocate. So adding a keyword in PL, in addition to updating the database, updates/creates an XML sidecar for raw files or updates JPEGs etc.
Whilst PL is light on DAM features this might bridge a gap and retain integrity with external DAM software.
Interesting statement you make about patching when problems arise. In a former life (before retirement) I was a developer in a business environment. Many times I came to “blows” with manager who had the same attitude - dont worry about bugs until they are reported, then address them. We need to get the product out to the users as soon as possible.
I could not develop in that fashion when I encountered the bugs as I was testing the programming. To me it was ludicrous to ignore a known problem then have to worry about fixing it months or years down the road when it showed up - especially since in all probability, me, as the original developer had my name attached to it, would be tasked to fix it. In the meantime other changes to the program by others after put in production, could very well make the obvious fix at the time I encountered it, be a far more complex fix than in the beginning.
It made no sense to me to ignore the obvious and build a buggy system than to try to get it as close to bug free as possible. Needless to say, I ignored my manager and did my best to ensure my software was as bug free as possible before putting it into production
Agree too. We should add multiple keywords. As Franky I have also keep a hold version of Aperture to assign keywords. It will also nice to edit major IPTC infos to be complete.
A question to those people who are in the “PhotoLab should stick to being a RAW converter” camp — what other commercial software can you name that follows this model?
I have to believe that the existing DAM capabilities in PhotoLab were added because DxO felt the market wanted it. All of the other software I have used — Lightroom, Aperture, Luminar, ON1 — have a DAM and with the possible exception of Luminar, all of those products have a more capable DAM.
The idea of “don’t make it another Lightroom” seems strange to me. I could agree that maps and slideshows and even printing do not belong in PhotoLab (though all of these features have been asked for in this very forum) because I, myself, wouldn’t have a use for them. But I think we can agree that if Adobe changed their pricing model, a lot of people would just use Lightroom because it has everything under one roof, as it were. Like it or not, Lightroom is the competition.
An alternative with an equally short answer might be to name an integrated product that has a good DAM. Compatible with Photo Supreme / iMatch / Daminion.
Personally I’d rather choose a ‘best of breed’ approach, using DxO’s high quality processing software + separate highly functional DAM (Photo Supreme in my case).
My own concern was (and is) that DxO’s time and cash will be spent in adding mediocre DAM features, with constant requests for further enhancements, rather than concentrating on adding enhanced image processing functions. Which, in some cases, we’ve been waiting for for years.
It might be interesting to read some of the other arguments from when the topic was first raised - for example here.
I hope that was the right call, and that the expanded user base at least covers the costs.
Hence the need for DxO to maintain a distinct USP. Unless there’s enough cash to be able to out-compete Lightroom across the board, feature-for-feature.
Fair points, but I still believe that a little extra work on the DAM — writing them to sidecars, a keyword manager pane — would make it a solid offering.
I see that Photo Supreme goes beyond its remit, too, including image processing options the are covered by any product like PhotoLab. I guess they do this because some people want some basic but solid functionality in their DAM. Sounds familiar.
Of course I would love a fully featured DAM in PL, but that’s not what I’m asking for. I just want what we already have to be rounded out to a robust “basic DAM”. It sounds to me like the DAMs you mention are trying to do everything they can think of and they’re paying for that with complexity.
As a further note here, ACDSee is a decent image processor with a robust DAM. It’s does not require keeping copies of pics like lightroom it indexes whatever file structure your pictures are organized in. It has facial recognition, hierarchical keyword, and mapping capabilities. Dropping a photo on a map updates the exif data on the image but Coords are only as accurate as where you drop them on the map. Conversely programs like photo mechanic that you can add GPS data to an image also works for ACDSee’s DAM to reflect. The keywording and facial rec though, is only applicable to ACDSee to see. I agree that writing information to sidecar files would be a way to interchange information among any processor. Since this does not currently exist, my workflow is post processing in DXO / Viewpoint as starting point, then whatever other processors one may require, (e.g. Luminar) and then final destination is ACDSee for DAM. However, it would be preferable to have decent asset management within DXO so all in one place. Just my final 2 cents worth.
You should be able to add keywords in Library view. Forcing user to move to Customize view is unnecessary hurdle even when active photos stay active in view mode change. Managing metadata is Library level task.
Or is there a way to add Metadata palette to Library view?
Otherwise, I think importing/exporting keywords in very important feature and should be handled robustly by the software.
I don’t know what Lightroom did to gain this reputation. Lightroom can manage by reference, too. It’s one click on the Import screen (in fact on my installation it is the default). I wonder if the word Import is what throws people. It could perhaps be better labelled as “Index” when one selects not to move the files.
It does build a thumbnail cache, and can create proxy preview files, but so do tons of other apps, and these things are done for performance (thumbnails) and convenience (previews).
The big difference is LR can only manage/develop files that have been imported! PL can browse straight to the file and then you can develop without having to import or index. PL will index automatically when you visit a folder.
PL does index, it’s just that it will do it on the fly. Otherwise it’s no different.
And the downside of the PL approach is you cannot afford to have lots of images in a folder because PL will throw away those thumbnails and have to regenerate them again later. Which is why, like Lightroom, you can ask PL to index a folder ahead of needing it.
It’s two sides of a coin. But my original point was Lightroom does not “require keeping copies of pics”, which seems to be what most people recoil at.
@zkarj What I was trying to point out is that LR can only “see” files that have been imported, whether by reference or by copying. Until you have imported images you cannot process them, whereas with PL you can simply browse to a folder and process files without the import step.
