Browse by high level folder

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 :grinning:

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.