I have a folder structure where top of the tree is a folder named 2021. Inside that folder are other folders, each pertaining to a different project. If I click on the 2021 folder I get a message telling me the folder contains no images. Yet if I search for folder 2019 all images in the sub folders are shown. That is fair enough but if a search will reveal all images contained in the folder tree why can I not get the same when I click on the folder. It would be a useful thing to have.
I have written my own browser for Mac that flattens folder hierarchies like you are describing. It has a search by either keyword or Finder Tag and allows me to save searches as āsmart foldersā (a bit like projects). When Iāve found the images I am after, I just double-click to open them in DxO.
Unlike DxO, I write the keywords directly into the images, saving having to maintain yet another sidecar file. The keywords and tags are visible from Finder, DxO and various other software.
Iām hoping to get it in the App Store in a month or two.
2 Likes
Joanna, Iām a little confused by this. Are you writing keywords directly to raw files?
Mark
Lightroom does show all images nested in the structure within the folder that I select. PhotoLab canāt do it as of today and Iām happy that it is so: Once PhotoLab sees images in a folder, it starts to calculate thumbnails and previews, sucking up resources like a thirsty camel oblivious of the rest of the world.
If PhotoLab had a more reasonable way to handle the creation of thumbnails and previews, showing subfolder content would be nice indeed. Until then, I withhold my vote.
Lr does indeed. In fact Lr gives one the option to show photos in sub folders or not. Maybe PL could have a similar option.
1 Like
Yes I am. I donāt see a problem with that. After all, itās witten to a separate part of the file ābundleā and doesnāt touch the actual image. I use ExifTool for writing because it creates a copy of the original before writing to it and, only after the copy has been verified, the original is replaced. Apple also provide their own APIs, which are quite safe.
1 Like
interestingā¦
@mwsilvers
and Joanna is not the only one to do that.
I do it for more than 10 years without any issue.
I kind of get where software vendors are coming from in āhonouring the sanctity of the original fileā but given a file could be corrupted by so many other means, I donāt really understand why itās never an option. Off by default, sure, but allow writing to those who trust. In fact, Lightroom will write to DNG files happily.
My camera, Nikon D750, is still supported by ViewNx2. I use that to write keywords to the NEF file directly. I was building something as what Joanna did with using Exiftools myself but stopped when I found that I could till use ViewNx2. Every program reads those keywords.
George
From what I can see, Nikon ViewNX-i, which seems to be their latest version, doesnāt write directly directly to the files. In fact, I guess they are doing what DxO are doing and keeping them in their own database.
ViewNx2.
They stopped writing to the NEF-files.
I donāt know about ViewNx-i. I never used it.
But I can understand why they stopped writing to the NEF files. They also wrote the edit list and a jpg to that file. Browsing does mean that the edited and embedded jpg will be shown. Just a pitty they stopped with the keywords too.
George
HoudahGeo (HoudahGeo ā Geotag and Add GPS Locations to Apple Photos) also writes the raw file both for GPS coordinates and city/country location information and also for keywords and titles. Iāve used it often. It also displays field sensor data such as temperature. My raw files are ORF. After processing with HoudahGeo I proceed to PL4.
Lovely.
If you need beta testers I am in.
Look forward to it 
Further to the discussion of whether or not to write keywords directly to RAW files or not, here is a quote from an Adobe document on the XMP specification
External storage of metadata
It is recommended that XMP metadata be embedded in the file that the metadata describes
ā¦
If metadata is stored separately from content, there is a risk that the metadata can be lost
If that is what Adobe says, I donāt see where the reticence to write to RAW files comes from
2 Likes
Hello Joanna,
I am no expert in this at all but the document you mention also says: āā¦There are cases where this is not appropriate or possible, such as database storage modelsā¦ā
So could that be a reason why i.e DAM software like Photo Supreme use xmp sidecars and do not write into Raw files (except a few heritage formats where they do it). DAM software is usually database storage isnāt it?
Sigi
Adobe can easily say that XMP metadata should be written in the fileā¦
Nevertheless, Adobe stores XMP metadata in .xmp sidecars in both Lr and Ps. This saves them (and all others) from having to figure out, where things should go in any version of raw file that any camera maker has produced so far and will produce in the future.
Iād agree to write XMP metadata into DNG files thoughā¦
From what I can see, DAM software is almost essential when using XMP files, in order to get to see the image and its keywords together.
If you write to the image file directly, you get to be able to search by keyword from all sorts of software, including macOS Finder.
You are right in saying that most DAM software uses a database and this can make the situation even worse. Now you have three sources of ātruthā to reconcile - the image file, the sidecar and the database. I have studiously avoided using the PL database due its tendency to not update when keywords are changed from outside PL.
My app doesnāt use a database - macOS Spotlight maintains its own index of metadata and is plenty fast enough and accessible to any app developer
And this is exactly what Lightroom Classic does.
In my mind, the database should exist for one fundamental reason ā as a cache for what the application āknowsā about the images. Weāve all seen apps that are āunencumberedā by a database and take forever to render a folder of thumbnails and cannot perform searching and filtering quickly.
A database is a learned view of the files āmanagedā by the application. It may also include information specific to the app itself that make no sense to write into the file, such as a photoās presence in a project, or the current selection state of images.
An example of this approach can be seen in Lightroom Classic. There are little icons that appear on the thumbnails if either the metadata in the file is different than Lightroom has recorded, or if Lightroom has been asked to update the metadata but not written it to the file. This is the best of all worlds because the two can be made in sync at the userās control, and the user is given all the information needed to take the necessary actions if desired. Metadata status is even a filter option. This enables me, for example, to edit my keyword hierarchy in the keyword list editor and then set a filter to find all the photos that were affected so I can rewrite the keywords into the files. I just made use of this in a big way by standardising all my bird names, which affected 214 photos from my 2019 holiday.
Iāve seen people, here and elsewhere, ask that PL not be āsimply turned into Lightroomā but I think it has to be said that many features of Lightroom are simply common sense, such as its handling of keywords and other metadata. Sure, PhotoLab shouldnāt mimic Lightroomās processing engine, but basic operation could benefit a LOT from following Adobeās lead.