PL5 keywords, one step closer, many steps still to go

No the correct numbers are 25 000 that are ready and 45 000 that are not prepared at all. 27 000 is the number of historical images the City Museum of Stockholm has.

Only the RAW-files are the masters if there are RAW-files, så derivates gets metadata correctly automatically when the derivates are exported after the RAW has been postprocessed by Photolab.

The keywords gives me a possibility to search theme oriented and that is a dimension you never can achive without proper keywording. The contact info is vital when my images starts to floats around on the net and so is copyright info and license conditions. Of that reason I also add Creative Commons Code “BY”. If you don´t add relevant metadata some consumers will not be able to use the images because they like to know the conditions tied to the images before they do.

My contact info gave an author writing a book about the Saur-revolution in Afghanistan a possibility to get into contact with me after seeing the images on the net and I could connect him with a swedish author that had written a book about the same topic. Just to give you one good example. He was very interested in some of the images I took during that day and the days after. Images without a context are of significant less interest for many image consumers.

Thats why also Headline, Caption/Desciption or maybe Comment is very important metadata elements. Metadata that isn´t compatible with XMP- and IPTC-standard today or written in your local language is in reality useless for anyone exept the one writing it. … and if it´s landlocked in a proprietary system not supporting XMP as a mean of migration you are bound to get into migration problems sooner or later.

… but if you don´t have needs I have, it might work perfectly fine for you to use your proprietary old applications like Apperture and even Excire as long as you can and I´m sure you will save a lot of money too but it´s ashame that you can´t see the keywords in Photolab … but if you are OK seeing them only in Excire I guess that´s fine too. Who needs interoperability - really??

1 Like

Until DXO can sort out their import/export interface issues there is what would seem to be a very simple solution and one that has been requested. That is provide a setting that if enabled would prevent PL5 from touching any keywords. For the user all keywording would be done in their DAM either before or after being in PL5. This would then follow the logical rule of only one software deals with keywording.

I understand that for you the structured keywording was not workable because of your required vocabulary. It seems though that many people do successfully use it and it is their preferred method. PL should not prevent them from that choice.

Not only the cameras :grin: I have a card reader here, on purpose not from Sony but a company called ProGrade. It’s meant for CFExpress cards and the producer promised compatibility with XQD, after downloading and installing a? Right, Sony-driver :laughing: Which of course doesn’t work anymore after updating to Mac OS 11.5 (12. something is the newest) Fantastic thing of ProGrade and Sony, thunderbolt III device is sold, customer won’t come back but money is in the bank :money_mouth_face: so what?

And you’re sure you mentioned every hiccup Windows ever had? :smirk: driver issues, incompatibility and suddenly no longer working printers are no exclusivity of a company with bitten apple as logo :grin:

Let’s skip the Aperture discussion, that battle-ship has sailed when you were still young and in spy-ware business :relaxed: and I even younger. Just show me the “other RAW-converter” able to read only your .dpo-files So, if DxO goes out of business tomorrow you just need to keep a machine running with the last app, else you loose all edits. Same what I do with my 10 year old iMac. Migration of a library, which by the way are ALL proprietary, be it LR, C1, DxO or what else, is never a mind-melting amusement. Just forget the “amusement” part… DxO PL5 could not even take over the “projects” of PL4, I first had to make a backup of the PL4 database and import it into PL5, as these two apps apparently don’t know much about each other (same with the tool panels :rofl: )

What’s the point in migration to a much weaker product, except seeing what other apps are missing? And I’m not talking about simple hierarchical keywording according to whatever standard.

I understood your points for keywords very well. I just don’t see my use-case for them if the image catalog gives me better options to find and access my images, for my use (and not for public display). I’m not working for consumers, my images are my hobby mostly and the ones I use for professional purpose in my job are well organized with a couple of more metadata than only keywords. Also, we can agree on that your contact found the image because of it’s title and keywords - but that would not mean a lot if the image itself would not haven been of good quality. That was a compliment for you, just in case…

This hierarchical keywording mess is of Adobe’s creation. Embrace, Extend, Extinguish style participation. DxO doesn’t owe anyone anything in regards to keywords. That said, there should be a way for PhotoLab to not touch metadata at all. I believe just disabling the metadata palette is enough.

Granular controls about which metadata is touchable and which is not will certainly complicate the preferences. As a software developer, I’ve said yes too many times and our software now has too many preferences. Each argument seemed okay at the time but I’ve got some regrets now. It’s not the end of the world as we service a professional market and have a loyal following as our player does allow more complex configurations.

The winning hand here would be for DxO to accept and work in multiple hierarchical keyword formats: Adobe and PhotoMechanic for example. There should probably be a preference to choose which structure, though the really cool touch would be for PhotoLab to recognise the keyword structure and slip into that dialect for working on that image.

It’s not that easy though as those hierarchical keyword lists have to be imported to be used properly. Next issue is what happens if the photographer has already screwed up the metadata badly enough to have both flat keywords and Adobe hierarchical keywords or even worse Adobe hierarchical keywords AND PhotoMechanic structured keywords. Which takes precedence?

Which goes back to a preference to choose one or the other keyword structure and stick to it for all the photos processed in PhotoLab.

The smart photographer sees these hierarchical keyword conflicts and nightmares and runs in the other direction, using just flat keywords. Hierarchical keywords are really an agency thing where there are full time minions whose only job is to fiddle around with keywords.

1 Like

Thanks for sharing your simple template. My point about just adding the metadata in PhotoLab 5 still applies though. Since 17 of the fields are semi-standard it wouldn’t be that much more trouble to add that metadata to a set in PhotoLab 5 and then go and add the Headline/Title, Caption/Description and keywords image by image.

Now that you do have a workflow which has helped you through tens of thousands of photos, I can definitely understand why you wouldn’t want to change it.

Aperture was a great start on photo library software. Like so many Apple projects, Apple took our money and just abandoned the software. Final Cut Studio (v7 of FCP) was a great piece of software which spent seven years in barely working condition after Apple pulled the plug for FCPX when all editors wanted was a better render engine under the same interface. If Apple had wanted to add their magic magnetic timeline as an additional view, no problem. But no Apple blew up the workflow of thousands of pro studios around the world (mine included), sending editors through years of struggling with Premiere, unrealised hope for DaVinci Resolve (a badly coded hardware hog until recently). Finally FCPX is looking better and Blackmagic Resolve performs reasonably on off-the-shelf hardware. Ironically, in the end Apple did bring back the non-magnetic timeline for the many editors who prefer to work with a building block style timeline (it took Apple ten miserable years to admit their mistake).

My point is that anyone hoping or counting on anything except a kick in the stomach from Apple is either naive or a fool. Apple’s blessing is that all their lives they’ve been competing with Microsoft, a talentless lot who destroy good software and destroy any interface with which they come in touch.

Even in its best days (and Aperture was my favourite editor/DAM for many years, with a full price purchase and two full price upgrades under my belt – I wasn’t one of the latecomers who got Aperture 3 almost for free), Aperture behaved absolutely horribly with XMP and other programs. Everything was written just a little bit different to almost guarantee incompatibility. Making Aperture reliably write out to .xmp files was a constant headache.

This nostalgia for Aperture is misplaced. We should judge Aperture for what it was not what it could have become.

What’s great about your systems Stenis is that you don’t allow the files to go into a database and retain all the metadata in .xmp sidecars. In thirty years or fifty years, there will be software out there which will read those .xmp sidecars. What’s important to us is that PhotoLab follows the PhotoMechanic model of compatible and relatively standards compliant .xmp metadata and not slip into the Aperture/Lightroom game of trying to break metadata for their own advantage.

With honest and experienced referees like you on the pitch, it makes a lot harder for DxO to pull a fast one here (or more charitably, accidentally code something non-compliant).


Note: I’ve corrected my original note about WordPress compatibility with PhotoLab 5 headline/title and caption/description. So far perfect compatibility. At the moment, PhotoLab 5 metadata editor is looking like a drop-in replacement for PhotoMechanic metadata editing for my purposes (captioning and keywording sport photos for publishing online with the same captions and titles).

See my feature request to do exactly that:
Feature Request PL5: Pass through keywords without change
and
Feature Request PL5: Pass through keywords without change

It’s your request that I was referring to. And thanks for doing that. :slight_smile:

If you are going to whine, please at least get your numbers right. PhotoMechanic Plus is $229 not $299. What it will be priced later is an open question.

Note: the upgrade to PhotoMechanic Plus to existing customers is also very fair. A customer’s existing investment is respected. As someone who debated long and hard about making the investment in PhotoMechanic Plus (I did not own PhotoMechanic 5 or 6) would I agree that the catalogue portion (not the metadata editor) is worth $400?

Astonishingly enough, yes. There’s nothing else which will index whole hard drives worth of historic images and render them instantly searchable without delay and with unlimited filtering.

And let’s not forget side by side viewing in PhotoMechanic Plus.

Now that FastRawViewer has four-up viewing as well as two-up, I’m inclined to continue to do triage in FastRawViewer. The preview reveals more about the quality of the image than PhotoMechanic. Both are very fast, very good triage tools. It’s partly habit – I’ve been using FRV for seven years and PhotoMechanic less than a year.

Sure, but the work I put in now in this is also very much motivated by refreshing my own memories and preparing them as a support for my own memory when getting older and for my younger relatives if they will be intrested in a future. When adding descriptions to these images today I have a fantastic support from the Internet and Google where I can refresh both my own memories and even deepen my own knowledge a lot when I write my reports and stories. When I now are tagging my old images from Petra Jordan - the lost city - that i took 1973, two months before the Jom Kippur War, I now mostly can find the right namnes of all the tombs and all other remnants that was created more than 2000 years ago down there in Wadi Musa (or the Valley of Moses as it is called in english). As an old history teacher too I think it´s great fun and very intresting.

[quote=“nwboater, post:77, topic:21713”]

Until DXO can sort out their import/export interface issues there is what would seem to be a very simple solution and one that has been requested. That is provide a setting that if enabled would prevent PL5 from touching any keywords. For the user all keywording would be done in their DAM either before or after being in PL5. This would then follow the logical rule of only one software deals with keywording. [/quote]

Yes, I have come to the same conclusion. If I use PM Plus it works perfectly fine to add metadata in PM - open the RAW in Photolab - Edit the image - and just export for eample a JPEG. In that case Photolab will just pay all the metadata PM has added forward without any changes at all and that goes even for elements not visible in Photolab! But, the other way around we first risk to strip the data that is ghosted by Photolab but that is not all (se the next case below)

One thing was the vocabulary and the other was that the structures present in the structured keyword list in Photolab was scrambled when indexing the images. The export to PM doesn´t work either as it shall. Even that creates a mess of the structured keywords used for the images in Photolab.

In many cases the vocabularies are as important as the very structure of the keywords and a lot of organisations and different bransches uses their own. I have personally been present in a few meatings about vocabularies and that isn´t anything I wish even for my enemies. I don´t know now but I don´t know how many years the museums in my country spent on quarreling about museum vocabularies.

There was also a very big EU-project around cultural heritage called Europeana and a lot of museums sent their images into that system but I really wonder if they have solved the vocabulary issus even to date. Trying to solve issues like that often seems to make even good friends enemies.

Alec, very good summary all together!
In fact Photolab buildt a keyword table with “hit rate” even when I indexed all my ready made images from the folder trees top folder. That surprised me! It´s all I need really but it had been good to use a keyword list for the searching like in PM Plus.

As I wrote earlier even I appreciate the PhotoLibrary when working in Photolab but only as a metadata consumer. I have great use of seeing the PM metadata even in Photolab. I think it´s great!

Thanks very much Stenis for all your further explanations. Glad to hear you agree that a simple setting to enable/disable PL from touching keywords would solve the immediate problem some people have with PL altering their structured keywords.

Before I started to develope systems I worked at an IT-distributor in the nineties and then I saw a lot of different software. One I remembered was a database program from Xerox called Formbase. I thought it was brilliant in it´s simplicity. Instead of defining tables, views and indexes in an SQL-databas of some sort you just drew the interfare with some object templates available and it was ready to use.

… but, it was really a toy and not a serious database a database-guy would even look at even then and there were none interoperability what so ever and none pathway for scaling present. It´s not so different from these monolithic metadata databases we find in Lightroom and for example Aperture. When I think of Apple I´m sorry to say that the first that comes into my mind is “proprietary solutions” (often good ones at a glance) but they always gives me the bad feeling of a hidden agenda which main purpose is locking people in. I wish people would think twice standing in front of solutions like that. Often the tresholds are invitingly low but when people want to get out they find temselves behind a one way check valve.

That would indeed be a winning hand! I think I wrote somewhere that there should be other metadata clues in the files to determine how to behave in any given case, or at least most cases.

Maybe another task for Machine Learning. :joy: But in all seriousness, it should theoretically be possible to come up with a “most cases” set of behaviours for reading keywords and a user-set choice of how to behave when writing them to a — both where the file already has keywords (respect existing form, or overwrite with preferred) and where it does not (use preferred form, or perhaps choose when performing the write operation, if it is a user-invoked action.)

And speaking of importing a hierarchy, I did take a look at the file Lightroom exports and it’s an interesting read. @Joanna mentioned that every level of the hierarchy should (according to the working group) be recorded in the files where Lightroom does not, but in a twist of irony the hierarchy export file does!

It occurred to me when thinking about all these issues that the very nature of keyword storage so far is part of the problem. If hierarchies were stored in a JSON dictionary, the structure is self evident in the format and no (sane) developer would find a “different” way of doing it. It seems the industry needs a bit of a nudge to solve this once and for all. Though getting standards widely adopted is often a hard road.

I’ve decided to give FastRawViewer a look after reading a little about it. I don’t have my “photo drive” with me currently, but based on its performance with some giant 48-bit TIFF files I’m impressed. Can’t argue with the price, either.

Good for you that you still have access to I-Tunes and your music in Aperture but for me that is just a sign of that your beloved old Aperture is more of a boy toy and an entertainment studio consumer app than a professional standard compliant metadata tool and archives with focus on imaging.

Joakim, now I think you must have been severely blinded by your Aperture on F 1,4 and I think it´s about time you try to get your facts right. You dont´s seem to know all that much about Photolab and PM Plus in co-work either.

There is a detachable light-table in Photolab and even PM has contact sheets with variable configurable metadata texts below. Very useful. PM comes with a slide show too with both transitions and a possibility to use houndreds of built in variables too. Pretty flexible - but sorry, I´m afraid you will miss the music.

PM Plus has both storable filters and Collections and Photolab has Projects and as I wrote today I found a nice integration feature i Photolab called External Selections. When I select files in PM Plus to open them with Photolab, Photolab stores these selections automatically in a reusable form under External Selections. So I don´t think there is all that much missing really.

When people are talking about softwares prices a lot of especially young people think that the norm should be that everything on the net should be free and if it isn´t it should at least be awailable as a pirate crack. The back side of that is people doing work they can´t live of.

I look at it completely differently. I have no problem at all to pay for either Photolab and plug-ins or PM Plus. In the case of PM Plus it has saved me a lot of hours compared to what I would have spent with the inefficient Lightroom, if I had continued with that. I value my time a lot since I´m getting old and I don´t have to save many hours to justify an investment in PM Plus. 229 $ is really pea nuts when it comes to productivity software like that. You stress interface polish in your Aperture and I stress high workflow productivity to get the job done, regardless of database size.

I have said it earlier too but I think it´s kind of important. There is a draw back in productivity with RAW-converters integrated with image archives. That comes from the compromise where the preview quality demands differs between the archive where fast scrolling and culling among sometimes houndreds of thousands if images is important and the converter where the demand is high resolution. That compromise can to a much grater extent be avoided working with dedicated specialized stand alone applications optimized for just the work they are intended for.

Photolab is demanding when opening images in forced “full resolution”. If I have integrated Photolab with PM Plus I can myself select an optimal number of images at the time and open them in Photolab instead of having to wait for all to be updated when opening the folders, (if I have folders with very many images). That is one thing that can improve productivity as a result of scaling up with PM Plus or maybe some other external software. With that concept you can get the best of two worlds instead of a sub par and unnessessary slow integrated application. I have no problems upgrading even it I don´t really need it because I want to support DXO a little extra in order to make sure they will survive and develop, so they can continue to surprice me every year with even more new and fantastic features to come.

Interestingly enough, the MWG guidelines do define a JSON-like structure

-xmp-mwg-kw:hierarchicalkeywords = 
{
  keyword=Entreprise,
  children=
  {
    keyword=Télécommunication,
    children=
    {
      keyword=Orange
    }
  }
}

But, of course, Adobe ignore this and impose their ‘lr:hierarchicalSubject’ tag, even though they contributed to the drafting of the MWG guidelines.

As somebody else said - “Standards? I love them, there are so many to choose from” :roll_eyes: :crazy_face:

1 Like

I am very perplexed by your last sentence! I thought that it’s a basic function of any decent dedicated DAM to be able to do those things. Are you saying that Imatch and Photo Supreme do not?

One of those is Windows only. I trialed the other one. Didn’t like it at all. But I’m a Mac user, we have different standards for interface and program structure. Interface was why I didn’t buy PhotoMechanic until v6 (I had trialed v4 and v5).

What I like best about PhotoLab (apart from the superb high ISO noise reduction) is the elegant and polished interface.

2 Likes