And even entire operating systems as Apple (as of 2016) has discontinued Camera Raw updates. You now need to upgrade the OS to get new camera support.
Well, thatâs me schooled! 
Support for GX9. Thatâs one of the reasons why I bought an upgrade to Photolab 2. That was the most important reason. But not only that one. 
1 Like
I think Bridge is excellent, and itâs free with an Adobe registration. I have On1 RAW, ACDSee, and Photos and none of these are as good as Bridge for a DAM. So Iâm not at all convinced that I want DxO to try and match it so that we can live inside one product. However, I get that is what people expect as a matter of course, and that is how the industry pundits tend to mark products in their comparisons. Even so, with limited resources I would concentrate on making the best pure photo editor on the market. Not the best with a compromised DAM. Not the best photo art editor. Just the best, focused, photo editor so that it becomes the default choice for enthusiasts and pros. Right now, with PL, Bridge and Affinity I have almost perfect set of tools. I would like to see DxO and Affinity up their game in their respective fields.
3 Likes
The one central thing, I never liked about bridge, is that it does not allow indexing files. I am happy to spend index time for search time for getting search results immediately afterwards. PL will be a sufficient DAM for me, once they add a hierarchical keyword panel like in bridge and the possibility to store these keywords to XMP, preferable in the same lr:hierarchicalSubject tag, as done by Bridge, Lightroom, IMatch and others.
I am in full agreement, Gary !
John
1 Like
The DAM is a complete waste of time and resources. PhotoLab will never successfully compete with Lightroom or Bridge or PhotoMechanic. Entering a race in which you will fail miserably makes no sense to me. Itâs featuritis.
The way to work quickly with PhotoLab is to move all the keepers you want to process into a single subfolder and point PhotoLab at that folder and just work through them and then do your export. Itâs simple as pie and you can use any software including Lightroom to choose your selects.
What I hate about Capture One and what brought me to DxO is the obstructive and second rate DAM features built into C1. Now that Iâm here I do appreciate the fantastic noise reduction algorithms, the attractive yet powerful interface and the automation features (donât use them for art photos but great for events) like SmartLighting, ClearView and Horizon/Perspective/Crop.
I can get better results out of PhotoLab (as a two month user) than out of Lightroom, Affinity, Photoshop, Iridient Developer or C1. Plus I get those good results much faster.
3 Likes
Since everything and the kitchen sink seems to be in this thread: on Black Friday I did buy Nik as well, though Iâd bought it previously and the free version works fine for me in Photoshop CS6. I donât see a need for most of the Nik features in PhotoLab. Iâd love to see Nik work perfectly with Affinity Photo with no workaround, lost work or crashes. Then over time performance improvements to Nik would be really welcome. Nik doesnât really need a new feature set or interface at this point, it just needs to be very stable and to run faster.
I completely agree. I very quickly am able to achieve better results than I ever could in Lightroom 6.14. I have been saying virtually the same thing as you since I started using Photolab 1 a year ago. I also donât miss, or need, a DAM in Photolab, but it is coming regardless.
As a result, at this point, maybe its time for complaints about the effort being spent developing a DAM to be over. It is a fait accompli. Perhaps itâs now a better use of our time to suggest which basic DAM features we would prefer. I want any added DAM features to be unobtrusive and not require any action on my part before I can start editing my images.
For me the one feature that I will not tolerate will be the requirement to import my images into Photolab before I can edit them. Other than the subscription plan, it is the single biggest reason that I began searching for alternatives to Lightroom.
Markl
6 Likes
I donât think so. All Aperture users I know miss the DAM functionality of it. LR and Bridge are no replacement for Aperture, so I think there is a chance to do it different and better. And why should I pay twice? Then I can go with the worse converter but have a DAM.
1 Like
There is no race. There is no innovation in DAM functionality, nothing happened in Lightroomâs Library module or Bridge since many years, except maybe performance improvements of the import. It is a relatively closed feature set, no moving target. I do not think, that the hardcore DAM users, with their special wishes and no other hobbies, are the target audience. No one builds here a second photo mechanic or IMatch. Too complicated they are, a never ending time sink.
A little bit of hierarchical keywording, a little bit of exif editing plus searching by these attributes and we have reached the core feature set of Bridge or AcdSee, which is sufficient for many.
1 Like
Agree. Hopefully they will not go overboard and try to make this a world class DAM, or require us to do anything, like importing images before being able to edit them. As long as the DAM is transparent and does not impact me Iâm OK with it. Hopefully the effort will not be a long term one requiring significant resources on an ongoing basis.
Mark
2 Likes
This wonât happen, because there is no reason to do so. Importing is an other name for a combined step of ingestion, indexing and preview generation:
Ingestion is a feature on its own. It deals with the question on how to copy the files from a source into a defined/auto generated folder structure on disk. It has no influence on editing a RAW.
Indexing and preview generation we already had in PL 1. They do not influence the editing step in a bad way. The activity in PL 2 brings the user the optional advantage to decide, whether he wants to index on demand, when an image is displayed, or as a batch operation. In the long term the current changes give the user control over what is indexed into the database, which is there anyway, and when the indexing is executed.
It should be clear, that without indexing and a database behind, there is no fast search. But for those, that do not intend to search in PL, nothing has changed so far.
On the other hand, think about the reaction of a potential new user with a large folder structure, trying to search in PL and he canât, because he did not view all his thousands of images one by one in PL, and there is no batch indexing available. Or, you wanât to search in PL, after your database broke without a backup.
I think i just wait a wile and stop thinking about the lack of improvement we hoped we got out of release of v2.0. (itâs as new cameraâs: the Panasonic G7 was nice but a paintjob of the G6 and technical not a improved G6 only more features. But the G80 was a firm step forwards in technical improvements.)
photolab 2.0 and 2.1 are DAM focused to put this on the market.
If i or any of us want or need it as first priority itâs not something DxO concerns about.
I think it is something they got requested for a long time of potential buyers.
As Optic Pro is seen as a great plugin for Adobe, Photolab should be seen as a standalone complete photo developement application.
And a complete app does have:
1 a Photo organiser/DAM/ search mode.
2 a raw developement with all bells and wishels like noise reduction, WB control, local corrections, presets and such. (all you can have to alter a RAW file technical.)
3 some filters for artistic purposes and special color rendering or things as blur, digital bokeh, vignettingcontrol. The filmpack things
4 a multi setting of export possibilityâs to get the desired output file.
5 a decend DataBase system to remember the development settings of the rawfiles
(And at the back also a organisor/DAM for photoarchive for the end product which can be seen as a separated application because it has nothing to do with the sourcefiles other then a link to the original source from which the endproduct is created.
So now they have a DAM (good or not compared to others) which can provide the organisation of the sourche files they can focus again on the âToolsâ of number 2.
So i wait just for the next things they roll out. I think that lots of our requested new things which they backlogged as interesting are spread in the workload of the programmers and maybe even put on the timeline beyond v2.x. So V3.0 can be more interesting then the v2.0 release was in the eyeâs of many.
I understand completely that a update is less providable then a upgrade for DxO soâŚ
if we support them by patients we can have a nice v3.0 coming up 
What you are describing is an endless time sink for software development. Bringing all of oneâs photos into a DAM and then managing them there has been a massive failure. All of these DAM solutions basically fall over and performance croaks at somewhere between 20,000 and 100,000 photos. If an active photographer brings his/her initial shoots back and put them into DAM at that point, his/her DAM is doomed from the start. Single events these days generate between 500 and 5000 photos.
There are two elements to a DAM - the culling process and then the management of sale ready or finished artistic assets.
What DxO is talking about right now presumably is a culling application like PhotoMechanic, Bridge or FastRawViewer. FastRawViewer costs $15. Thereâs no money or sense in replicating that functionality in DxO.
Lightroom and Aperture tried to do both - manage incoming images, ie. ingestion and culling - as well as managing the finished assets on the other end. What happened is that pro or busy amateur photographers catalogues were collapsing. So the whole idea of the master catalogue fell apart.
I think itâs a huge mistake. The master catalogue with 30,000 image is realistic if one only puts oneâs finished images there (and I donât mean the 500 selects for the bride to review but the 90 or 150 finished photos provided - even then a pro photographer might want to only keep the 5 to 20 portfolio photos from a given wedding in his master catalogue).
What I like about DxO PhotoLab is that it keeps all the information about its work in .dop files which reside with the original images. The database can be thrown away at any time with no consequences for oneâs work (and indeed discarding the database often recommended by DxO support as a way to deal with PhotoLab performance issues).
If DxO wanted to create a portfolio management application, Iâd have much more time for that than a comprehensive DAM. PhotoLab preview is so slow, I have trouble imaging doing any culling in PhotoLab and I see no sense at all in trying to
So on both ends, this DAM effort is just DxO chasing other companies down a dead-end highway. The number of photographers (willing to pay DxO premium prices) who are driven by image quality is surely higher than the number looking for another half-cocked DAM solution. Really the resources exerted here should be re-focused on performance improvement in PhotoLab. If thereâs extra resources, adding a first rate HDR merge module like DxO Perspective does for architectural photography is a proven money maker (take a look at all of the second rate Aurora versions (Aurora, Aurora HD, Aurora 2018, Aurora 2019) which have sold well.
Heck, Iâd buy such an HDR module, if DxO made it available.
I wish DxO would take the opportunity to partner with a couple of ingestion applications (FastRawViewer, PhotoMechanic, there are others) and partner with a couple of image catalogue/portfolio management applications. Itâs hard to get out of the âNot Invented Hereâ mentality, imagining that since one made some software better than others, one can make all software better than others. They have my compassion as fellow developers but in this case as a paying user/support of DxO PhotoLab the spend of resources on non-critical functionality makes me really unhappy.
2 Likes
What you describe is PL without a âPhotoLibraryâ, what for sure wonât happen. To have a pseudo photo library, without any functionality makes even less sense. I see two possibilities:
- Remove the photo library completely, so that the tool works with external selections only, from explorer or external DAM.
or
- Make the âPhotoLibraryâ useable comparable to Bridge.
There is nothing in between, that makes sense.
Is the solution to load only the information out the sidecars if the folder is actuated?
(Only filename/date /location of all images no other info in DB, so the stored information in the database isnât that big and detailed search is on active scan in folder?)
And search function by active scanning not out indexed stored information?
(i use a database for my financial administration and its very slow because of the many years of entry.
And i should cut down and devide it in smaller blocks if i want to speed up the program so i imagine the same behaviour in the PL DB and thus DAM .)
1 Like
Iâm surprised that anyone is using PhotoLabâs âlibraryâ feature. Itâs slow and clunky for anything beyond providing a way to see the photos on deck for processing.
Culling with PhotoLabâs photo library is incredibly slow. Switching between photos with FastRawViewer (my culling tool of choice) takes between 1 and 3 seconds depending on computer and hard drive setup and which RAW files (5DS R 50 MP files are slower) and if thereâs an accompanying camera jpeg. With DxO PhotoLab itâs five to eight seconds when moving between pictures.
If by DAM solution, DxO means faster switching between photos in library mode, thatâs fine. I donât really care about the speed of switching between photos in library mode as I follow the time saving formula of culling the photos before putting select photos into a single folder, pointing DxO PhotoLab at that folder and going through the photos in file name order.
If I had photos which I want to process in a group in a set, Iâd make a separate folder for that set.
Unlike these here-today, gone-tomorrow all-in-one DAM solutions (Aperture, subscription-only Lightroom being two examples), OS file management sticks around for decades (both Mac and Windows; Linux changes disk formats and file management systems more often) and is fairly reliable. OS level file management can also handle hundreds of thousands of files at a time without a hiccup.
I moved to DxO PhotoLab to get away from software which wants to kidnap my photos (iPhoto, Apple Photos, C1, Lightroom) and keep them in a database and manage them. Iâve lost enough months of my life fighting back against here-today, gone-tomorrow DAM software that seeing this might be the direction in DxO PhotoLab - creates serious disappointment.
Frankly, Iâm worried. DxO management donât seem to see that their lead is in quality of photo processing. Photographers at DPReview complain about speed of processing in PhotoLab and not about this mythical missing DAM.
PhotoLab has a basic file browser with thumbnail preview which shows star ratings from other applications. Thatâs all it really needs.
As someone who has been developing software and web applications for 17 years and as a power user of software for 30 years, Iâm very concerned that DAM is a time sinkhole which will suck up years of development resources. The very worst programming sinkhole btw is sync. Working two-way sync has consumed 80% of the development time for task management or contact software. The preferred method is single master which SAAS and ubiquitous internet has allowed. DAM has many characteristics of two-way sync - where are the files, what has happened to them. Monolithic DAM means when the DAM breaks (pardon the pun) all of your data is lost or compromised and that your files are locked into the software forever.
It would help if someone at DxO would come out and tell us in some detail what they mean by DAM and what their plans are for this feature. From what I can tell, there is about a two thirds majority of people here who appreciate DxO PhotoLab for its RAW processing capability and donât want PhotoLab intruding on file management. Thereâs about ten or fifteen per cent here who just like features and since Lightroom has a DAM and C1 has something like a DAM (awful and even C1 recommends breaking a library into projects most of the time), DxO PhotoLab should have a DAM too.
More features usually makes worse software. It certainly makes software much harder to maintain. Hard to maintain software is abandoned by its publishers more often than easy to maintain software. âImpossible code-baseâ, âtoo slowâ, âtoo fragileâ, âout of controlâ are the words developers and programmers use to describe software which is too complex and difficult to maintain.
When manhours are limited (Adobe for all its business ethics and quality control issues does not have an issue with limited manhours), complexity and overreach mean stagnation of the core features. This is not usually a winning combination as it allows the competition to catch-up against a publishersâ core advantages. Pushing forward where there is an advantage is a stronger strategy.
These are decisions for DxO of course, Asser, but your blithe excitement about adding a DAM is worse than naive. I hope the above helps you understand the deep concern many of us share about DxO going off-track chasing a DAM, just as they went off-track chasing camera hardware.
4 Likes
How many person years do you think is needed to add a hierarchical keywords UI panel, some database tables for storing keywords and synchronization roundtriping of these tables with XMP using Adobeâs XMP toolkit? I would estimate at most 2 man years, if everything goes wrong. If these tasks are devided on several people, I do not see any problem.
If XMP + DOP is used to store metadata, the usage of the database remains fully optional, and the database is only a search index, which can be erased without loosing anything.
Btw. XMP roundtriping of stars and labels is requested relatively often. Add keywords, and the most demanded use cases are covered.
But 2 years development could cut the lost progress as a processing program that were lost with the DXO One mess.
1 Like