Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
21
I´m a long time user of DxO and started with Optics Pro 7 around 10 years ago. I left Lightroom for Capture One because of the poor quality of the LR previews and for the superior tethering in and the local editing tools with layers in C1. But soon DxO got my work horse because of the picture quality and the faster work flow. I have never been a friend of the so called DAM in Lightroom, which is really not a Digital Asset Management system at all but more of a Photo-centric Asset Management. A real Enterprise DAM can handle all types of files and they are muck more open and flexible and demanding than an entry level product as Lightroom. Another sign of that has been the fact that the “layers” in Lightroom has been carefully hidden until now not to irritate beginners as has the the XML-schemas and forms design tools. Instead Lightroom is full of annoying “one size fits all” predesigned forms designed for beginners with very low skills when it comes to DAM. Nothing wrong with that if your target is mainly an entry level group of users.
I got Lightroom 1.0 many years ago for free when Adobe made an hostile take over of the Danish software company Pixmantec who made a RAW-converter called RAWShooter. At that time Lightroom was just terrible (especially the quality of previews and they still hasn’t cought up and the RS-users were furious. It took until version 3.0 before LR got usable. Lightroom is still a tremendous offer - nothing gives you more for your money but that is also the problem. LR was maybee the first RAW-converter using a built in metadata database. It gave some advantages and some problems.
The first was to intruduce a single point of failure with a database that crasched from time to time and got corrupted. It has happened myself several times. Since XML-sidecars not was default it was a few things to think of if you wanted to migrate when XML-based alternatives got available. Most other systems use XMP-sidecars by default or write XMP into compatible image files like TIFF, DNG or JPEG. If the database gets corrupted in Photo Mechanic or any real DAM it´s just to reindex the filestructure again, since it´s the metadata in the files that is the master and not the database.
The second problem was that you now had a system with a RAW-converter and a PAM. That demanded really problematic compromises when it came to the previews. To make the RAW-conveter possible to use you needed heavy previews in 1:1 and to use it for culling and tagging you wanted th system to be fast. Those heavy previews created performance problems. Well from the beginning there was not really any alternatives to Lightroom if you wanted a catalog and PAM-functionallity but now there is.
I have a history with Enterprise DAM when I worked for the City Museum of Stockholm between 2009 and 2016. So I knowed that technology pretty well. The complexity of these systems make them pretty demanding and expensive to implement and manage. So when Camerabits finally were ready with Photo Mechanic Plus it was the answer I had waited for. It had most but not all I have waited for since leaving the cumbersome and ineffective PAM in Lightroom and I got it on a campaign for peanuts.
From the beginning it had some flaws though and the most irritating was that I just could open one single picture in Photolab 4 with the Edit-function in Photo Mechanic but after discussions with Camera Bits their really responsive staff fixed that for both Photolab and Pure Raw. With this said I fully agree with almost everything Alec Kinnear has written both in this tread and a previous here in DxO Forums. I have a few wishes left. I hope they fix so Photo Mechanic polls the filesystem for updates, appends and deletes (wether they are made with Photolab, PMPlus or the Explorer or Finder, so we don’t have to remember to sync our catalogs by ourselves (as it works in Enterprise DAM). I also hope that the schemas in PMPlus even can handle not just IPTC-elements in schemas and forms. We need an even more transparent system than todays PMPlus and we need support for all the XMP-elements and a possybility to design our own like in real DAM. As photographers handles any types of files we need support even for these file types, like office-files and PDF-files. Camera Bits just need to open up and make it possible to handle all file types that are not XMP-compatible (like TIFF, DNG and JPEG). Just handle them lik RAW-files and add an XMP-sidecar like with the RAW-files.
And to Peter Gallagher:
I would be a suicide for DxO to just cater as a plug in provider to Adobe. I understand that they made PureRAW since they saw the mediocre image quality that came out of Lightroom with low light pictures on high ISO but that window will just be open as long as Adobe are fat and lazy enough because of the self playing piano they have created with their subscription model. They make all time high without despite a slow R&D.
The combination and integration of Photolab 4 with PM Plus 6 gives us the best of these two worlds. Photolab 4 is probably the converter that gives the best image quality today and PM Plus 6 is much faster, more flexible and far more efficient than Lightroom. The reason for that is that neither of these softwares are harnessed by the compromises Lightroom suffers from. So I hope DxO tries to work closer to Camera Bits with an even better integration than try to invert the DAM-weel again. Camera Bits have already done that. The only draw back I see today is that it’s a more expensive solution than Lightroom to buy in the short run if you just look at the price and not value your time or consider the accumulated cost the subscription will add up in the long run. I also think it will be an advantage in the long run for us users with a company like DxO trying to convince their users to upgrade every year with their last innovations than a company like Adobe that doesn´t really need to rely on their R&D like DxO to survive.
What is the basis for this statement? How many copies were sold and how many of these copies are actually used? I’d be interested to know, not to prove this statement wrong, but to learn that this product actually took off.
I think the point is that a lot of people sees Adobe’s LR and PS as ultimate software which every proffesional is using it along side illustrator.
So every time they have a new tool it must be good. But it doesn’t mean that other manufactorers of applications have it wrong. Just because it’s different.
Sometimes it’s just different not better or worse.
Most people crushed Sil(k)ypix developer pro as not workable very ugly userinterface bad processing and such.
Wile it is just have a different view on things.
It has when you got used to it very nice output and it can be quite flexable.
DxOPL is the same, it’s born out optical plugin for image processors and by adding tools to finetune the output it became a standalone and it stil has the old backbones which makes it a great plugin, pure raw, but around that it builded a good toolset which would give you enough to finish a rawfile in to a photo.
Ok the creative tools to turn a photo into a image (fictional reality) are less then others but the core the backbone is very good.
And carying a multitoolbox with all the bits and pieces around the hole day wile you only want to fix a stuckwall which needs screws, a screwgun, some battery’s and a knive and measuretape, will slow you down.
Same with software to much options will slow you down.
It’s better to update and improve excisting tools so they work better and are more divers usability.
I really hope that DxO keeps a nondestructive DAM system which is lean and mean, only the most needed tools, and play’s nicely with the monsters as photomechanich for the one’s who need that. Which means that all info as exif and iptc are stored in external files not in internal database for starters.
Hi Mark. What is not entirely accurate about what I said? Exactly how I phrased the sentence it is entirely accurate on MY computer, maybe not on yours.
Just for grins it would be interesting to compare the latest versions of FRV and FS on several different formats of raw files (.nef, .cr2, .cr3, etc.) on the same computer for initial rendering times of the embedded jpg files and the overall performance for file rotations, cropping, etc. of the raws.
True, years ago FS’s performance used to be kind of laggy about displaying the large raw files from the newer crop of cameras, but in 2018 with the mid 6.x versions the author began making major updates to FS to add multithreading, better use of cache, more efficient programming, and other things that he didn’t separately list. The more recent 7.x versions in 2020 and 2021 have since made even more improvements. If you are basing your opinion on an older version of FS you should definitely give the newest version of FastStone Viewer a try because FS has undergone a very steady development that has made it a real powerhouse in its arena.
Perhaps FRV is faster than FS on displaying raws in general, I don’t know because I’ve never used FRV, but I doubt the difference is very significant since FastStone displays the initial embedded jpg files “quickly” and if one is selected it displays the .cr3 file under a second. And that’s a first look at the file, not a cached version. It seems to me that in this case the argument about speed is just an academic argument, not a practical one, since apparently both are high performers.
Plus, FS has the nice comparison functions described earlier and can resize, resample, crop, has many more print options than DxO, can save in dozens of different formats, and can do rudimentary color/exposure/contrast editing. And it is color space aware. It can’t compare with DxO and other full blown raw processors for final development quality but it’s a stellar viewer/culler and can produce nice quick edited results if the original raw files are already very good and you’re in a hurry.
I have paid licenses for both FastStone and Fast Raw Viewer (FRV) and use the most current versions extensively on three different computers with very different specs. Despite your doubts, when changing raw images (not embedded jpegs), in Faststone it takes very significantly (and annoyingly) longer to change images then in FRV where changing raw files is immediate. For those who are content with viewing embedded jpegs the rendering speed is not an issue. However, for those who want to view the raw files instead, the rendering performance difference can be a big issue. While I prefer the interface of FastStone including its image compare feature, FRV has many more features that are helpful in the raw culling process, especially when you are trying to cull multiple similar images. However, I don’t like FRV’s UI, and FastStone is definitely easier to use. Whether I use FastStone or FRV depends on what I want to accomplish.
Main difference of FRV and FSV is image quality information.
In FRV, you can set the viewers command buttons to a certain camera specifications.
DR stops, overhead stops, things like that.
So you can click in one go to highlight check or shadows lift, auto corrected WB, detail and edge detectiin for finding the best focus. Real raw histogram instead of the sRGB version.
For just which “composition i like more” more js FSV enough.
But for more detailed culling based on Image Quality more then “is it in focus and do i like the composition?” The latest FRV is better. And you can now side by side viewing.
I still use FSV for jpegs and tiffs which are exported out dxo.
Checking and comparing is gold in this application.
Interesting, and very contrary to my most recent experience. So I did a little more digging into FS and found a surprise.
Just for a quick test I put a fresh set of 30 full size 45 meg .cr3 files from my Canon R5 into a new directory; as you know, FS then displays the extracted jpg files for viewing. Then as usual I had the directory display the files in a tile configuration in 260x95 size to get a decent look at them all. Then I selected one for full screen viewing of the raw file. From there, I selected the next one, then the next, and so on, and it took FS about a quarter second to display each new one. And that is with CMS (color management) turned on!
Next, I copied 30 older, full size 40 meg .nef files from my old Nikon D810 photo repository into a different directory and repeated the same steps as above. The result? It took FS almost two seconds to display each new raw file. I never really noticed that before… looks like FS has a much more efficient way of rendering big .cr3 files than at least for big .nef files, and maybe other formats also.
In my usual session of culling 40 - 100 photos at a time I don’t see a two second delay in changing from one picture to another as a big deal tho I can certainly see how people with lots and lots of big .nef files might (.cr3 files should be NO problem at all).
The ability to compare 2, 3, or 4 files on the same screen at the same time, to do group or individual independent zoom and pan in the comparison display, and do some limited work on any individual photo in the comparison screen are all very big plusses for me that I haven’t seen in any of the other programs I’ve ever had (haven’t seen FRV, tho).
I might try FRV just to see what it can do but from what I read it doesn’t really do much else that I need for what I do. And, FS is totally free, FRV is not. But since during the last 5 years I have already twice sent the $35 commercial licensing fee to FS just to support the author’s great work I’ll probably not pay the $24 fee for the basic version of FRV. But we’ll see how the trial goes.
The latest version of FRV has finally added the ability to compare and zoom two images at the same time. However, I often still prefer to use use FastStone for comparisons of two or more images despite the lag time when initially rendering the raw files.
Thanks for this comprehensive answer Sten-Åke. Obviously, there is room for debate about the best way forward for a comparatively small player like DXO. Although I think PL is far better as a raw-processing suite than LR/ACR, I think Adobe still have a more compelling product overall.
I hope DXO can continue to expand their returns from their strengths but – to judge by what other companies (C1, On1, Skylum, Exposure, ACD Systems) are doing – they may have to offer and continue to develop a more-or-less-complete desktop image processing suite to stay in that competitive arena.
That’s a big treadmill to turn even leaving full asset management to one side. The alternative is to be more like e.g TopazLabs – a direction that I think is also open to DXO and possibly even more suited to the nature of their assets. This is a ‘slimmer’ and more specialized offer, but it might enable a relatively small company (50 or so employees?) to do very well.
The biggest drawback in the present dxo viewer is the “blob” or “plop”, the delay which is due optical module kicking in. just after that the lack of selecting 2 or more image’s to compare. If there wasn’t a blob/plop you could flip back and forward of two images next to eaxch other but the blob is causing a too long delay to use the “monitor viewing memory”.
I know DxO is acknowledging this problem and is working on a solution.
(i don’t know the implications of it all but i assume 4k support and maybe speeding up and extending the viewing capability is a thing which need carefull walking forward.)
Same as side by side and processed (Deepprime) preview without exporting. resources of dxopeople and hardware (our) are limited.
Work in progres is always too slow for the one’s who are waiting.
i am with two feed in the DxO boat ,i soly choose DxOPL as my main developer because of the m43 rendering quality which is more usefull for me then extensive edit functions or Dam or culling functions.
So i surrounded DxOPL with aid programs to support the voids.
FVR for quick culling and pre checking quality.
Bridge for tagging (PSE13 is too ocward /old and seems to create no xmp.)
FSV for examination of exported files and comparison of more then 1.
(in full size otherwise you get bad examples of the files also rawfile is view in fullsize)
It’s enough for me and it gives DxO the time to catch up.
But if your not in the boat or just one leg i can imaging you pull back because of some drawbacks.
The weight of those drawbacks are personal judgement.
Thank you Ian. That’s very interesting data (not a Linked-in subscriber, so hadn’t seen this). Of course, “employees” is a variable gauge in different countries and under different corporate structures. Still… DXO is larger than I believed it was (and ON1 smaller, on these numbers).
Good find Ian. Based on my experience of these companies, Exposure and On1 and Topaz look very efficiently run as they are turning out good software and getting quite a bit of press from small teams. Skylum and ACD must have huge marketing teams as the results are not apparent in the software.
DxO looks to be in a golden middle. Lots of those 88 will be support. Keeping up with those individual lens and camera profiles must require a fair amount of man power, automation or not.
I only hope that with all those employees and developers Photolab 5 will support Apple Mojave OS so that I can keep using Photolab and advocating for Photolab.
Lightroom’s biggest weakness remains its subscription model. This isn’t going to go away as it’s a significant factor in how the company is valued. As for specific masks, I’ve used them about 3 times in the last 15 years, they are not necessary unless you like working that way or have a task that requires them.
Same here. Before raw converters had local adjustments you had to accept compromises when you adjusted images. Open the shadows to reveal detail, reduce highlights to recover detail, balance saturation across the image etc.
With local adjustments; sky needs recovering no problem, blocked up shadows in the trees no problem, guys jacket too saturated, no problem etc. Local adjustments are the key feature for minimising the need for round tripping to a pixel edito, and are vital for DXO to remain competitive.
The biggest drawback of Optics Pro was the lack of local adjustments. DXO going for a layer based UI for local adjustments was another big plus. LR has just followed their lead
Until layers in raw editors have blending modes I do not see them as layers at all. They are just a convenient way of tracking selective edits. I certainly do not believe Lr is following DxO, they have just revamped the selective editing engine so it can do even more. The last time I looked DxO had some catching up to do in terms of luminosity and colour range masking.
You seem to have overlooked my smilie It was a light-hearted reference to DXO producing Clearview before LR introduced Dehaze. DXO went with a layer based local adjustment UI before Adobe.
As in my other posts the local adjustments in DXO, C1 and now LR are using a layer UI, not pixel editors adjustment layers. This is far superior to the old pin&brush UI in lR which I used from V1 and an excellent improvement to LR. A layer based UI enables you to name layers, clear masks, invert masks, fill masks, copy masks, vary layer opacity, turn on/off layers, refine and feather masks, step through the layers with the mask visible to see what areas you are impacting etc.
