Wow, this is still news to me that Adobe was going to provide masking in Lightroom… Interesting.
I’m sure there are a lot of nice features in LR, but I’m going to stick with PL4. I like how flexible things are here, and easier to understand.
Heck, I’m not sure if I’m ready for PL5 !!
1 Like
In fact there has been layers also in Lightroom for a long time. Every time one opens a new session in Adjustment Brush there is a layer created. There has just not been a useful interface to handle all the layers like the ones in Capture One or Photolab. There are just a lot of small grey dots created for each layer without any labels or so.
First time I understood that was when I bought a Lightroom plug-in called SLR Lounge. That is a preset plugin and it also give you some really useful retouch Adjutment Brush -presets. Each creating their own hidden mask-layer.
A lot has happened during the years Optics Pro became Photolab. The most important has been the implementation of Local Adjustments and the Control Point-tech from NIK Collection, the Layer-system and the brilliant Control wheel-system, the better use of the profiles and the Lens Correction-sharpening has also given us better tools than old Unsharp Mask. It has taken a few years but looking back it’s a lot of improvements I’m very pleased with. I’m also very adicted to Clear View Plus dehaze.
Prime-denoise has been very good a long time but got even more useful in PL 4 when we got the new Deep Prime which doesn’t almost smear at all. After we got that I have stopped thinking more or less of noise problems in poor light on high ISO. It’s just magic. You can always buy a plug-in to Lightroom but a plug-in is always plug-in. Better to have state of the art denoise already built in. PureRaw is kind of a fling because a software like that will die instantly the day Adobe finally pulls themselves together and address their picture quality problems. As long as they haven’t they have to live with being humiliated by DxO. We might think DxO should respond on LR releases but Adobe hasn’t given a shit about their poor, relatively speaking, image quality.
Local Adjustments, and the Control Point-tech is brilliant and far more efficient than the layer handling in for example Capture One but it needs a few upgrades to improve precision when it’s needed. More smart AI would be one way and I wouldn’t say no to the same solution we have in CO where it’s very nice to be able to create a layer from an area of a certain color. I would love to get Color Wheel to work even on local layers. Today it doesn’t.
When it comes to PL:s metadata support it’s really limited and inefficient to handle. Today just a few XMP/IPTC-elements are displayed and possible to handle through the PL interface but I could see a development to use templates more in PL in order to give people a possibility to tag their images in a more simple way. This could be a basic offer to the ones that are satisfied by that but to develop a full fledged flexible ITPC-support like the one in Photo Mechanic might be a black hole to enter. I think it would be much smarter to live that to the real pros at Camera Bits instead.
The good news though is that it works very well alreay today to let PM Plus 6 handle all metadata maintenance as long as you use the right workflow together with Photolab. The keywords applied in PM Plus will be displayed automatically in Photolab without any import even. If you open a RAW-image in Photolab with metadata previously applied in PM Plus, develop it and export a JPEG, TIFF or DNG, Photolab will write all the metadata in the RAW-files XMP-sidecar into these three types of XMP-compatible image files. I have used this work flow for quite some time now without any problems and it works because I strictly use a one way flow.
In Capture One they have opened for two way flow and I think thats a mistake. Of different user demand reasons the City Museum of Stockholm first used a quite extensive two way flow between old SQL-applikations and their new DAM and that caused a lot of unpredictable results some times and a lot of increased developing costs before it worked. I think it would have been a far better and cheaper solution to handle all data through de DAM-application interfaces strictly one way flow.
In the image below you can see the metadata info form in Photo Mechanic Plus displaying all the metadata that got exported to the JPEG-derivate from the RAW-original, when exported from Photolab 4. Another thing to consider is that Photo Mechanic is smart enough to handle all three files, the RAW-file, the DxO .DOP-file and the XMP-sidecar, so you don’t risk incomplete copies when files are copied or moved with PM Plus, which is very important.
1 Like
- To toggle all the FastRawViewer palettes just touch tab like in Photoshop or Photolab.
- Full screen is then simply “F” without a modifier to get rid of the top bar.
To really enjoy full screen mode, you’ll have to customise the bottom bar. Customisation can be accessed via the gear on the far right of the bottom bar.
To swap between contact sheets view (thumbnails) and single image, it’s simply “G”.
I’ve also remapped the rating buttons to numeric keys on my keyboard (set in File → “Customize Keyboard” or command-K), and set autoadvance on rating (click the gear wheel on the XMP Metadata panel to access the auto-advance settings).
I use a similar workflow Stenis and recommend it for those who really want to use metadata in tagging their images. The only way to keep the metadata with the master files and not just a set of jpegs is to do the tagging in Photo Mechanic.
My findings about Photolab support are not quite as positive as yours.
For jpegs, there is no XMP sidecar (probably not for TIFFs either) but the metadata is embedded in the file. In fact, Photolab preferences offer a checkbox “Preserve metadata in XMP sidecars for RAW images”.
The next issue is that Photolab does not necessarily pass through all of the data in the right format. I post my final jpegs to WordPress. WordPress uses both IPTC title/headline and caption/description. Photolab 4.3.1 build 60 does not pass through caption/description in the right format. Fortunately re-exporting the jpegs with PhotoMill X.
This is a very unwelcome additional step. Troubleshooting this issue cost me a half a day and required the participation of the head of technical support from Camera Bits. I’m not pleased to have my time wasted like this.
DxO has considerable work in front of them just keeping up in terms of passing through metadata reliably. Adding their own metadata tools is fraught with many opportunities for failure. As you point out, the simplest of editors for title/headline, caption/description, keywords and copyright information might be manageable. Few photographers who use metadata will be happy with that though – everyone will want their special field and the project risks collapsing in unusable interface.
Yes, that’s the big change in LR. The pin&Brush adjustments were using a layer UI under the hood but its taken till now for LR to use the UI needed.
brilliant, thank you! I’d got the bottom bar customisation sorted but never realised I could toggle to full screen!
1 Like
I never thought about the adjustments in LR as layers, but now that you mention it, it does make a lot of sense. I always thought Adobe would keep layers out of LR because it already offered layers in Photoshop. I guess I was wrong.
Adobe did used to restrict LR to try and prevent LR eating into PS sales. Now that Adobe has admitted defeat and gives away PS with LR that kind of thinking is not so important. This situation just reflects the current “value” of a pixel editor now that we have very competent raw converters with local adjustment capability.
1 Like
Alec, you are absolutely right when you lifted that PM Plus 6 doesn’t always manage to export data in a way that it match all other softwares IPTC or XMP-implementations but that doesn’t mean that the workflow between PM Plus and Photolab shouldn’t work because it does, if you strictly let PM Plus own the metadata and Photolab to just consume and export it to the JPEG-derivates. So absolutely no XMP-editing of keywords or any other fields in Photolab if you use them together. When I say WORK I mean that the metadata applied to a RAW-file in PM Plus will be perfectly saved when the same RAW is opened in Photolab and exported to say JPEG-format. I just saved a copy of two metadata forms side by side to verify that - one RAW and the corresponding JPEG.
However, if I open the exported JPEG in Windows Explorer I will find some data missing in some of the fields/dataelements. When I searched on Google for “Title and Caption IPTC not supported by Windows 10” I got some interesting hits. Look for yourselves:
Quote from: Captions, Descriptions, Titles, in Picasa and Windows - ExifTool
Re: Captions, Descriptions, Titles, Picasa and Windows
« Reply #2 on: July 06, 2015, 07:56:03 PM »
Windows file properties don’t play well with anything.
I decide to take a few minutes and figure this out, since this info doesn’t seem to be documented anywhere from what I can tell.
When you set the Title from Windows Properties, the following tags are set:
- EXIF:ImageDescription
- EXIF:XPTitle
- IPTC:Caption-Abstract
- XMP:Description
- XMP:Title
Windows Properties will populate the Title with the same tags, in this order of priority:
- XMP:Title
- EXIF:ImageDescription
- IPTC:Caption-Abstract
- XMP:Description
- EXIF:XPTitle
End of Quote
I lifted this question earlier with the Camera Bits support and I got a similar answer. PM and Photolab doesn’t make anything wrong in my workflow really but it’s strictly IPTC and if Windows is using another element for say “Description” than the IPTC-field (for example an element in EXIF instead the PM Plus/Photolab exported data will not show in Windows.
I think Camera Bits might be able to fix this though by opening the now hidden XMP-schemas in PM Plus. Today there are variables that seems belong to EXIF you can use in the forms but there are no possibilities today to add the corresponding elements from for example the EXIF namespace in XMP when building the forms in PM Plus. (These forms can only use IPTC-elements today.) If it had been possible one could just duplicate what’s in the corresponding IPTC field with help of a variable for Title, Caption or what ever and write it to these fiels too in order to get compatibility with Windows.
1 Like
Photo Mechanic to Photolab workflow does work but I should not have to re-export my jpegs from Photo Mill X to make the description/caption tag appear when I upload the jpegs to WordPress. DxO has considerable work to do just to keep up with making sure external metadata moves properly through Photolab and is fully readable on the other end by the applications which might be looking for it. Such as WordPress with the description/caption tag.
As you point out, as soon as Photolab allows editing of metadata new challenges come into view. What’s essential is that if Photolab allows editing of EXIF or IPTC data is that changed metadata should stay in the XMP file where other applications can see it and not be stored in custom fields in the DOP file.
As a new user to PL4, I am ONLY using it for its superior (to Adobe’s) RAW processing / denoising (i.e. DeepPreime). Its integration with LR / PS is far better than Pure RAW’s and it allows full control of DeepPrime and Lens Sharpening, which I found in many images to be too strong with Pure RAW.
With the new LR features (i.e. more sophisticated masks) and PS with TK8 for many much more powerful masks I believe I have a well balanced editing suites (for my needs). I don’t need DXO to develop DAM capabilities, just to keep their RAW processing algorithms as best in class.
I feel much the same way, although being a Fuji X Trans shooter it will be interesting to see how version 5 pans out. I no longer use 4. I find Lr raw processing quite good enough but DxO does have nice noise reduction and I hope Pure Raw will improve and become a) Fuji friendly and b) a nice plugin to Lr. There is competition out there now and I reckon Adobe will come up with an equivalent idc. Do love the TK Panel, especially version 8.
Stenis, I thought there was a problem with Photolab 4 not carrying across Photomechanic 6 headline and description metadata on export? I was losing that data on export from PL4 just a month or so ago. Has PL4 changed tack on that recently?
1 Like
I have seen you have participated in som other treads discussing the metedata problems here at DXO. Alec, it´s far from just DXO who has a few problems to solve. Look at Carl Seiberts intresting article. How different software handle the most commonly used metadata elements differs a lot. Some read for example the corresponding EXIF-elements but will not export to the EXIF elements. So this clearly stresses two way data flows is not a good idea and also that’s why I think it´s a good practise in my case to let Photo Mechanic own the metadata in a workflow with Photolab 4. It won´t solve your problems downstream right away but it won´t create more problems at least. I think we have to get the manufacturers of the software to fix these problems that they don´t seem aware of yet.
Photolab´s own metadata elements/fields are not in synk with XMP (and thats why the IPTC-data don´t show in Photolab) but it´s according to Carl Seibert´s investigation (link below) nothing unusual at all. Most software are just able to handle IPTC. Many can´t handle XMP at all. Some write both to the IPTC namespace in XMP and to the older IPTC/IIM but doesn´t update the corresponding elements in the EXIF namespace of XMP. To increase the magnitude of the problem elements like Title and Caption/Description is not updated in EXIF by Photo Mechanic and just these element are read by the “Info tab” fields in for example Windows. I think it´s a must that all metadata editors sends metadata even to the EXIF elements in the fields. So despite I have updated these fields in PM Plus these elements are empty i Explorer. Even Adobe has the same problems and even seem to be out of synk between their own programs Photoshop and Lightroom!
XMP, IPTC/IIM, or Exif; which is preferred? - CARL SEIBERT SOLUTIONS
Since the problems are like they are we might have to ask Camera Bits and other manufacturers of metadata editors to expose even EXIF and all the XMP-namespaces in their forms so we have a chans to “fork or fan” these data by ourselves to these elements to meet our own needs. I don´t think it´s a good solution to use another software to convert the data you get from PM Plus just to meet the needs you might have downstream.
I saw Joanna was working on a metadata tool of some sort and some other in that discussion hoped DXO should license that for their archive solution but would´t that be to do just what Joanna herself didn´t think was a good idea - I mean “to invent the wheel again”. Camera Bits has spent 20 years to get where they are today and Photolab 4 manages to read XMP from the RAW-sidecars and propagate that data correctly to for example JPEG derivates. What I fear is that DXO will corrupt the XMP-data if people starts to update the metadata in Photolab too. Doing so is definitely to establish a two way flow and that is to ask for problems. Despite there are metadata standards I think Seibert and many others including myself has discovered there are many different ways to implement them.
“The best” with metadata standards seems to be there is so many that everybody can have his or her own :-).
1 Like
…possibly, but I’ve not seen any issues in between DPL, LrC and C1 so far.
indeed, but as I’ve seen so far, the different implementations cooperate with each other.
Please note that the Seibert page is fairly old, and while principles might still apply, the results shown might be outdated.
Nevertheless: Good practice for metadata handling is to do it in exactly one application.
3 Likes
Antoine, I have not seen anything like that. I repeat again:
I perform all metadata maintenance in Photo Mechanic Plus 6. I never use Ingest and always create a subfolder in Explorer and copy my files to that. Then I index the folder so PM Plus can see it with all the images. I add all the metadata through the forms in PM Plus. Among the fields/elements in these forms are Headline and Caption/Description.
When I open this folder in with the images in Photolab 4 the only metadata I can see is the keywords I have applied in PM Plus. The lousy metadata interface in PL4 just allow us to edit Author, Copyright and Keywords,. There are no visible fields for either Headline or Caption/Description in PL4. The label Author is a little odd in a tool for imaging editing and leads my thoughs more to the metadata standard of Dublin Core originally used by the libraries. Dublin Core is a namespace in XMP but that data is ghosted even in PM Plus.
Lyckily though Photolab 4 reads the IPTC data PM Plus puts out in the XMP-sidecars PM Plus attach to my Sony ARW-files and even more so it seem to correctly transfers all the IPTC-elements/fields I use in my forms in PM Plus to the JPEG-files PL 4 exports. I export with those ARW as originals and these metadata masters. To verify that it works I will attach an image you might have seen already in a previous post above where you can se the RAW-metadata form as it looked in PM Plus to the left after I applied it. To the right you can se how the same metadata looked when I opened the exported JPEG after it was exported from PL4 (after I reindexed the same folder in order to make the JPEG-files visible). So my answer to your question is that the metadata integration works perfectly fine between PM Plus and PL4 as long as you don´t mess with the data in PL4 and if you do that you open for a two way metadata flow and that is to ask for problems. Don´t do that.
BUT the fact that the metadata workflow seems to works fine between PM Plus and PL4 doesn´t mean I don´t have any problems downstream in other metadata consuming applications like even Alec have described. To my great dissapointment Windows Explorer can´t see some of my metadata because it displays elements from the EXIF instead and they happen to be empty because PM Plus has not forked this data to the EXIF elements. EXIF has elements of it´s own and EXIF is also an embedded namespace within XMP and IPTC has elements of it´s own and are also an embedded namespace within XMP.
Of historical reason though not all metadata consuming applications use the XMP-data or even the IPTC elements. Instead it seems to reads the EXIF and IPTC outside XMP instead and sometimes it neclects even the IPTC. That´s why it should be nice if Camera Bits could open even for the use of EXIF and Dublin Core at least. The 15 Dublin Core elements are very important in the library world but also in many websites used to host cultural heritage data. It´s a core part of the so called Web 3.0 or the “semantic web” where it is for exemple is used to link auto searches in related websites for associated types of data.
1 Like
Well as a photographer my primary concern is RAW processing. DxO’s considerable advantage here makes PhotoLab a pretty compelling product.
When one adds specialised tools for the other tasks, Adobe doesn’t offer anything special for image processing and those specialised tools are very affordable.
- Triage: FastRawViewer or PhotoMechanic. I still find FastRawViewer once properly set up (and it’s a pain to set up right in the first place), the best triage tool for RAW and the current version is lightning fast on a computer with a modern (even modest) graphic card.
- BitMap editing (Photoshop): Affinity Photo.
- Soft Proofing/Advanced Printing: Affinity Photo.
- Panorama and HDR: Affinity Photo
- Metadata editing is optional: in that case, PhotoMechanic is what you want to own, Lightroom or PhotoLab user
Minimum budget here is very modest at €25/$25 + €50/$50 for FRV and Affinity Photo. Neither of those publishers require annual updates (so far a minimum of five years between paid updates) so we can consider those licenses true perpetual licenses.
If one wants to do more than tinker with metadata, one is stuck with the relatively steep PhotoMechanic license fee. If one decides to leap in with PhotoMechanic, then it’s worth the jump jump straight into PhotoMechanic Plus where finally a photographer can enjoy a powerful multi-catalogue lightning fast DAM (Lightroom’s DAM features, while beating the low bar among RAW editors are pathetic and unreliable in comparison with dedicated DAM software, as Stenis explained in detail above). Carl Seibert who has worked with DAM for decades feels PhotoMechanic Plus is the first real affordable DAM for photographers.
DAM and metadata in some ways is over-rated. If one is not shooting for stock or running a photo studio, arranging one’s images by data in a consistent folder structure with RAW images and finished images takes one a long way towards DAM. Just naming the folders well solves most issues with finding events. Dropping a text file in the folder with more detailed notes makes those images even more findable. And all of this comes for free with your OS, whether Windows, Mac or Linux.
Named structured folders is a whole lot better than trusting an unreliable third party database (i.e. Lightroom) with the information. Lightroom can be made to at least maintain XMP files and leave files in place which would make it possible to rebuild the database in the case of the inevitable catastrophe. By default Lightroom is set up to destroy a photographer’s archive in the long term (as was Apple’s Aperture).
So no, I don’t find Adobe’s subscription offer with lock-out the month one decides to stop paying at all compelling. Moreover, by supporting such bad behaviour (forced subscription), the slaves are forging their own chains and encouraging every other software developer to treat them like plantation slaves. Sometimes the stupidity, weakness and fatuity of human beings is almost too much to bear. Watching photographers finance Adobe’s attempt to destroy independent freestanding desktop applications which grant us our privacy and don’t require monthly payments in perpetuity is such a case. Small wonder Adobe treats customers with such contempt – what businessman or megalomaniac could fail to despise such craven short-sighted chattel.
FastStone creates great software at amazing prices but it’s Windows only so I can’t test Image Viewer’s speed with RAW images (thank you @sloweddie for the detailed report with the differences between Canon and Nikon RAW files, it may be that FastStone Image Viewer is showing embedded jpgs for the Canon files but has to render the Nikon files as there is no full sized embedded jpeg – I’ve noticed that Nikon RAW files do behave a bit differently than my Canon ones for quick preview). Based on reports, FastStone cannot compete with FastRawViewer for RAW triage. Not much can and I’ve used (not tested, used) ApolloOne, Capture One (slightly older version but triage hasn’t changed), Lightroom 4, Aperture and PhotoMechanic.
1 Like
You make some good points here, Alec. I’m not going to defend the ‘compellingness’ of LR for someone who has the expertise that you have. I, too, strongly prefer the quality/character of DXO raw-processing and can substitute for everything I need without using LR. But it does mean creating a bitmapped image in circumstances where LR/PS can keep the file in a ‘raw’ state, or at least preserve the raw state within the file (“smart-objects”). The Adobe suite has an advantage here, in my view but I would not subscribe for that reason alone.