I fear the DAM will be given priority over U-point tools however much they would be a major leap forward. Given the refusal to listen to concerns raised on the adverse effects of the DxO One I don’t hold up much hope on this.
Implementation of DAM is far more easy then improvement of U-point tools.
less complicated to add and its a “new” asset/feature so it can be used for promotion of new version.
Second the frase improved this or that is less easy to show i think. Because you bring down your own former product when you show and compair old and new and it is a clear and very visible improvement.
So new features are commercial wise far more preferable.
But rebuilding existing parts is more a maintaining/maintenance kind of work. keeping up with the concurentie is a balance act.
Sorry for the lack of availability after the release. I can understand the frustration and aplogyze for this.
It’s not in our mind to avoid questions, nore do we want to ignore your feedback.
First of foremost, I want to tell and assure you, on behalf of all the team, that we only thrive to bring you the best solution and features one can dream of regarding photo editing. We’re dedicated to this and will continue to be dedicated to it.
Now, to answer to some questions that have been around on the company, the choices we’ve made, and the fear of some regarding the DAM arrival as a threat to the rest of the software features, I can clarify the things a bit.
Yes, we clearly have been ongoing a wrecking year, with 3 main topics to deal with:
The DxO One “adventure” hasn’t found its market, and made us restructure the company, hence having an adptation phase.
The Nik Arrival, with all the work of refactoring - still ongoing (just as a reminder, the code hasn’t been updated since 6 years… Google teams haven’t done anything more than what Nik software did back in 2012)- has monopolized more than half a year of our dev team.
And it has been pretty much the order things went.
Regading the DxO One and Nik, well, the main things have been said above.
Regarding PhotoLab 2:
- the DAM feature : Though some of you don’t see the need and the reason why this feature is coming to Photolab, it’s still one of the key feature part of our users ask for. Same goes for people that use other solution at the moment, and would love to switch to PhotoLab, but wait for this specific feature to make it happen. As for local adjustments, It was one of the “last” big pillars that was missing to our fundation as a complete photo editing solution. That’s the reason.
- Will the DAM get all attention, leaving the rest of the features on the road ? Surely Not! You’ll understand, by reading between the lines, that we’ve been through lots of sollicitations, leading us to choose to have hte DAM released by “steps”. We know, and have in our bag, the sets of functions that will make it a perfect assistant to your photo organizing, and we’ll keep on releasing this functions in the upcoming months.
The first real milestones being in december with the Keywords importing and Search feature.
But That’s only a part of what we’re working on! The tip of the iceberg…
We have UI/UX improvements coming, with lots of little features directly coming from the “Do Not Forget” list, in addition to other ideas we’ve had for times now, to improve the overall experience inside of Photolab
We also have image processing features, Tools, Local adjustments and masks enhancements incoming because it’s the Core of what we’ve always done and because we want to stay on top of this regarding our competitors.
All this will come during the year to come. And we’ll stay more than ever careful to your feedback.
We ask you to not jump to quick conclusions regarding the attention and importance we dedicate to our users or product, nore should you jump to quick conclusions regarding the simplicity of things to implement.
Of course, it’s always easy to advice others and say : this shouldn’t take time to implement, what are you doing guys ? And everyone has their own priorities… but I assure you that we’re not on the beach drinking Margharitas and developping or thinking of what we intend to do just half hour a day and that’s it.
I, for myself, have never been in a company that puts so much heart in what it does.
Unfortunately, sometimes things don’t go as you’d expect.
And we also share the same amount of frustrations (if not more) regarding what we’d like to have the time or capabilites to release.
Anyway, we’ve lot of ideas, lot of concepts, a great community of dedicated users that help us move on, step by step, and we’ll keep on moving on, knowing it may take a bit more time than we all would wish for, but at the end, hopefully, we’ll get that PhotoLab as perfectly shaped as it can be.
Thanks for your time and patience.
DxO PhotoLab 2
Digital Asset Management in PhotoLab
For me this is a statement that will make me do the upgrade to PL2 and hope DXO will keep what has just been promised. I trust you in this and thank you for this clear statement.
Thanks for the elaborated respons.
It’s clear, i hope, we don’t think you and all the other employes are checking out the weather on the other side of the window. But working very hard to overcome that financial blow this year.
Also i understand that broadcasting a detailed roadmap isn’t a wise thing to do, sleeping dogs thing, but until your post just now it was rather difficult for the not EAmembers atleast, to predict the next outrol of improvements.
And as i always say: lack of signal lets the noise come through louder not that there is more noise.
So thanks for the signal.
Fabrizio, thanks for your detailed post. I’m a new user considering buying the full package. I’m impressed with DxO Photo Lab and the Fine Contrast and Clearview and Prime Noise reduction features. I really like the interface.
But when I hear you’ve lost your way with this DAM, I am very worried about that huge investment (almost €300). People ask for DAM but won’t use it until you’ve ruined a first rate RAW developer with second rate DAM features.
I understand that users want a full solution wrapped up for them. Partner with the major DAM providers on a special offer. Heck FastRawViewer - what I’ve been happily using with Iridient Developer and ACR in Photoshop CS6 and Affinity Photo before DxO Photo Lab - only costs $15. You could do a deal with the developers and include FRV with every full copy of DxO Photo Lab.
DxO Photo Lab’s is known for the quality of its lens profiles and its RAW development (including perspective fixes). Stick to your USP (unique selling proposition) and don’t get stuck chasing jack of all trades master of none Lightroom. Lightroom became popular due to the marketing muscle of Adobe. I only used it because of the quality of its noise reduction in comparison to Apple Aperture whose RAW development had been slowly iced by Apple two years before they completely killed the application.
The only combined DAM and RAW developer which got the combination right was Aperture in its v2.x iteration. And even then the database features were a nightmare to manage. Images which went in to Aperture were going into a black hole. Moving externally stored images was a complete disaster (the database would lose them). Adding too many images could cripple the database and your computer.
Just stay away from this failed model (huge database of images, including all photos shot) and build good interaction with DAM software which really works. There’s only a few programs which do DAM well - the reason is that DAM is a very, very difficult design and programming challenge. And hardly related to high quality RAW development and local adjustment at all.
I so wish I’d heard you speak about fluidity improvements to speed of preview when prepping images (more speed would be a huge workflow improvement) and improvements to masking, gradients and local adjustments (making them easier and more powerful) instead of this Quest for the Holy DAM Grail.
In hindsight, the overreach with DxO One did an enormous amount of damage to both your operations and your brand. Adding DAM features is a similar distraction in my opinion. Please do not listen to the loud voices. They shout the most and buy the least. One more feature to be persuaded to buy, just one more feature, just another half a feature, just a new interface…that noise will never stop.
If you still insist on building a DAM, please keep it a separate project (integrating well with DxO Photo Lab of course) so it has carries its own costs and revenues and cannot somehow cripple the essential self-standing RAW development workflow and cooperation with other applications built into Photo Lab.
How the absence of intrusive DAM functionality persuades photographers to choose DxO Photo Lab over Capture One, Lightroom and other RAW tools with integrated DAM
Capture One’s intrusive DAM functionality is why I stopped using it except for Sony A6300 files (Capture One does have good Sony colour profiles). The RAW development was actually okay for me (I hadn’t had a taste of what DxO could do at that point and planned to have Fuji X as a big part of my photography).
The inability to just do simple RAW development cost Capture One a €200 upgrade to the full version from Sony Pro 10 (€59). Now that I’ve worked with DxO Photo Lab, I far prefer the tools and workflow and results with my Canon files and my jpegs over Capture One. I wouldn’t have been open to trying another RAW developer though as my financial and psychological investment would already have been made in an expensive and comprehensive RAW developer.
I do like Iridient Developer and continue to happily use it for Fuji files but as a tool to process Canon full frame files with complete lens profiles and automated corrections, Iridient Developer cannot compete with Photo Lab on a huge set of colour photos. I’m very happy that the current Photo Lab does not try to get between me and my DAM tool of preference (FastRawViewer) and continuing to occasionally use ID or another RAW developer.
All in one tools which don’t play well with others (Capture One, ACDSee Photo Studio for Mac) don’t get a look in. People like me spend a lot of money on software (more than we should) to have the best possible dedicated tools, with focused development teams. We don’t want Adobe or Phase One bloatware full of compromises and sloppy interface loose ends.
I think we’re the audience you can reach with Photo Lab by being absolutely the most powerful and efficient RAW development tools with some integrated masking and local adjustment capability. We can go elsewhere for HDR and panorama functionality (Affinity Photo, EasyHDR, Photoshop CS6 to name just a few) and DAM functionality.
Beat the drum you have (best RAW development, lens profiles), not the one you don’t have (image management solution).
Totally agree with the DAM comments above. I never used the DAM in PSE or Lightroom and resented the space they took up on my HD. It is very much the rerun of the One project again and I fear might end the same way bur worse.
As in my personal point of view, i like to have i build search creteria , but not a kind which has the need for cataloging.
example: when i change things in watched folders by PSE, remove copy cut paste out this folder to n other outside this DAM , the library gets corrupted, i get orphins as tumbnails and not showed images in the other folder because he see’s it as double.
That is one of the bad sides of a DAM. So just a exif reader and a extended exif editor would be great. a bit like the windows search function, it gives a path where to find the file , not the file it self.
use the exif reader to search plane files not by library function. Just show what’s in active the folder not around it.
This way i stil can move files around outside PL’s “DAM” function without the orphin issue .
as I understand - first you failed with a business project which had nothing to do with the Photolab, then you waisted time with the DAM feature intended to attract potential users, and now the actual users have to pay for it…
I use Photo Supreme, simple why I am badly dyslexic and adding and searching by words is more than an interesting thing for me. With PS I can get the spelling for categories and other entries and when indexing images the entered categories get displayed as you start to type. If the worst comes to bare just bring up the full list. Searching is just gragging terms needed into the search box, for me simple. Any hope of DxO managing this, about as mush likelihood as the DxO One being susseffull. DAM’s produced by others have been under development for years and there strengths are based on it. OP is a RAW editor and to me its mad to spread thin resources over a new area when there are masses of camera/lens outstanding let alone years of under development with the core program thanks to the One. To me there is more basis for developing Fujifilm compatibility, given the long standing demand there has been for this.
Please, please stick to the XMP standards when implementing DAM features. I am afraid you will create a lot of problems to people that use a professional DAM as PSU when you are handling Exif only. This said I also prefer a refinement of PL as RAW developer over extended DAM features.
Doesn’t matter which file just please no library by indexing in a working application.
exif is present from the start profided by rawfile and xmp needs to be baked.
But then again i am not used to thousands and thousands of image every month. so…
I totally agree with Alec above.
DxO being “just” a raw converter was a very heavy argument for me to NOT get Lightroom. I don’t want to be forced to use huge libraries or the like - I am able to organize my data by myself.
I strongly like the UI and workflow with DxO, and I prefer it to every other RAW developer I tested so far.
People who (think they) need DAM should do this by using specialized DAM tools. Instead of adding unwanted and incomplete features into DxO, it would be much better to get the already existing core functions fully performant (example: auto masks in local adjustments is crap right from the start; I’ve been waiting a full year to see this corrected, but apparently that’s not addressed in PL 2 by any means).
Ok, did some reading about what Exif, IPTC XMP is and how we can use it.
(I don’t have a large amount of images every month so i never bothered to label and tag my raw files other then folders with date and place. I do tag and label more detailed the processed files as a Jpeg. (i use the PSE Organisor for this.) Which has its quirks.
- changing quarded/watched folders outside the application does corrupt the library and repairing is time consuming. (so i always keep every thing out its grip until i am satisfied and only then i place the folder with new images in a special “import folder for DAM”
Why i am telling you this? Well before i place it in this folder, the EXIF data is the only image data in the jpeg or rawfile. The sidecar which DxO provides is a development status file name accordingly to the rawfile.
For me if i can write in the EXIF of the Jpeg/tiff or rawfile in that list of details some things like place and subject(s)
(date and such are already in there) that will be enough.
So why XMP then? eh i think the same reason as why using a DNG (not lineair).
In time it could be happening that the coding of a old specific rawfile can’t be read anymore and your image is lost in time. By decoding it in a general international container like Digital Negative Graphics its suppose to be accessible for ever.
So XMP is the DNG for the metadata of the image. (as far as i understand.)
Knowing this, yes if you build a DAM make it working with XMP-sidecars. Because it’s your archive for “livelong” managing images you can’t make again.
But as i understand building and maintaining this library cost computingpower which slows down the actual developement of groups of files. (Like to read every time again and again the hole index of a large booklibrary to got the indexnumbers of the shelf of the new books before you can walk to shelf with the latest books to see which one you like to read. That’s rather stupid if you know where that shelf is and you can walk directly to it because you bin there every month.)
It just slows you down unnecessary. But if you like to find that book you read years a go and you only know its a detective called Luke something and it was happening in Tokio around 1969, Yes then that slow index comes in handy.
So as i see a good working DAM.
- Automated indexing ónly when i want it to happen. (when i archive my rawfiles whom are worthy to keep. (that’s why i hated LR’s active folder “Stop doing things i didn’t ask you to!!!” )
- A DAM tab and a folderbased tab choise. (So i can choose if i want to search with TAGS and keywords or just jump to a folder i want to see.) And DAM-application is only running if the DAM tab is active.
- XMP seems to be read by all other applications the same so crossover to other applications and edit it elsewhere will update also in the original DAM. (This is crucial because you don’t want to do it twice or have different data in different tools/applications.)
- It has to be smart enough to overcome changes made outside the application without burning to much processingpower every time you start it up. And i think that’s a challenge to build.
So maybe DxO can build a DAM READER (XMP reader) inside DxO PL (so if you open a folder it reads only those XMP-sidecars and shows the information only when select a image) and make or use from a other DAM designer a DAMtool (editing XMP data) standalone.
Just keep images and sidecars connected wile moving around in the folders in DxO PL Organisor, so next time you start up the DAM it updates its indexlog.
Use the DAMtool to find and open folder or group with DxO PL organiser. or just don’t bother and open directly organisor and click on desired folder.
Digital Asset Management in PhotoLab
Now that is communication
This is all what was needed to sort things out. Thank you.
About the DAM: Please keep it optional.
I don’t know what you mean by “actual developement of groups of files” but a DAM doesn’t slow down the work. Indexing files takes time, but searching is “immediate”.
Even Windows Search indexes image metadata and allows you to find a file as fast as you enter the search term.
P.S.: XMP is not “the DNG for the metadata of the image”. It’s just the right place for metadata describing the image.
My experiance with opening PSE Organisor is every time it opens it starts to search for new changes(new images or lost one’s, try to reconnect the lost ones.)., this slowing down my initial reason to open the DAM. This is why i only use this DAM for my endproduct, image archive, so i this behaviour is as little as possible during my workflow.
If this behaviour is also at my start of workflow, by culling and adding and regrouping images and every start i have to wait until The DAM is up to date , that’s what i mean.
And second if this update cycle is running in the background does this slowdown batch developing? depends on the processor and memory i think.
xmp isn’t that de new default / standard for storing exif data and other metadata of certain files? In order to make a standard which any OS version and application can read even when we are in 2050 on win22? I mean dop files are DXO standard but not for Adobe. so its not transferable. and as far as i understand a xmp does.
like DNG format is a Standard.
In that i meant it is comparable.
At least it is XML and lies outside of the native database. Even if you have to adapt the XMPs for the next tool, it is still possible. IMHO it is the best exchange format for metadata.
that’s either bad design or wrong setup. In IMatch you can decide when to scan folder.