Writing keywords directly to the raw file was standard for Nikon in CaptureNx(2) and ViewNx(2). They stopped with adding keywords directly to the raw file that a few years ago, probably when the Nik software was sold to Google, but I’m not sure.
I just downloaded a Z6 raw file and opened it in ViewNx. I was not able to edit it but I was able to add keywords to the file. The Z6 file has a different structure as what was used at the time the Z6 was brought on the market.
I keep my raw file since 2008. All have keywords.
No. No backups of the files before adding keywords.
IPTC/XMP are made to be added to the file or as sidecar.
Just look at the huge number of tags and notes about them that exiftool documents, and every new camera that comes out requires investigation. It takes DxO and others a long time to support various new cameras just for read. Asking them to write to the formats as well isn’t going to speed things up exactly. Even if they were to just wrap exiftool they then create a dependency that needs to be kept in sync, and hope that exiftool continues to be maintained.
Exiftool exists. If people want to use it to modify their raw files then why should DxO spend time reinventing the wheel? Should they also spend time ensuring that they can read raws that have been modified by various other tools, with possibly varying degrees of competence. You’re adding a lot of complexity to something that’s complex enough given the sheer number of different variations, TIFF-based or not. I think DxO would be better off not sinking time into it. (Although I admittedly think the same of much of the DAM-like functionality.)
But XMP is an ISO standard and is documented. writing keywords to image files is a tried and tested procedure and, as long as software developers stick to the essentials, the risk is absolutely minimal. By default, ExifTool creates a safety backup of the original file until the changes are made, only, optionally, deleting that after the modified file is successfully written.
For PL, this is a very valid point. Whether you use XMP embedded in the image file or a separate XMP file, there will normally only be one place to write the metadata for all versions. Given the current standards for one metadata block per physical file, I’m not sure if per-version keywords would be possible, since versions is a PL concept, recorded in the .dop file.
Hello,
I don’t know all the things you are talking about, but as a user with a little bit of technical skill I ask myself if it would be a good idea to make step by step.
There are standard EXIF Metadata like is described here http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf. This standard data DPL must be able to read/write, and for working with the search function of Photo library DPL must be able to search with search criterias (and/or/not…) my photo collection. If this works well I will be happy.
Database design and function I’m not interested…for me as user it has to work . I must have the possibility to backup and restore (it’s implemented), by closing DPL it would be fine if i got a message to backup ( like LR does it with the catalog)
I would be glad if DPL could separate program data, user data and user config, and if I would be able to choose the location where user data and user config will be saved. At the moment I can only choose this for database and cache. Presets, Plugins … are anywhere in the program folder and/or in the user profile (Windows system…don’t know where in Mac OS). So for me it’s not so easy to backup these files if I made custom presets, palettes, workspaces. Watching forum threads I noticed that also for users working a long time with DPL it’s not easy to remember where all the stuff is stored.
If anybody is here knowing about terminalServer/citrix environments some years ago, she/he knows how difficult it is to bring a software not designed for multiuser environment to run (this only for a synonym seperating data)
That’s the sight of someone who likes to take photos, want to keep his data safe and easy and not interested to crawl or dig for parts of the data.
So keep on discussing, I will go outside because here the sun is shining and the air is clean.
Please keep all in good mood, stay healthy and enjoy the coming christmas days with your family
Well I agree that DxO shouldn’t have moved into the DAM space. But now they have, they need to meet international standards, basic user expectations and rock-solid reliability to maintain their good name.
As a careful photographer, I would hope not. But if your collection eventually gets passed on to someone else, are you confident that they will know what a sidecar is, that they won’t, say, delete them because they don’t show up as images? I wouldn’t be.
My family collection goes back to at least 1883. Many of the photos lack ‘metadata’ because they’ve become separated from the frames or albums that probably once held such data. Where I do have metadata, it’s mainly where someone has ‘embedded’ it - by writing directly on the back of the photo. What I have found or reconstructed is now securely embedded in the image files in perpetuity.
I admit I do not fully understand exactly what the cache / database holds, or what it’s function is, so my comments below may or may not be relevant (apologies if not).
My personal workflow and preference is that I do not use Projects, Key Words or History, and I have no interest in having a digital catalogue or DAM in my RAW editor or any other photo editing tools. I store my files by year, quarter, date and folder subject name, and would rather DXO concentrated their efforts on improvements and innovations to the RAW development and editing process.
I very much like sidecar DOP files and keep them with my photos (even if I rename or move folders), and I hope DXO maintains compatibility and the ability to read the sidecars over many years (e.g. in 5 or 10 year’s time if I decide to go back to one of my photos for a re-edit, then the original edit with all the settings appears on screen for me to adjust according to taste).
My concern is that any changes do not have a negative or destructive impact on the many thousands of DOP files contained within hundreds of folders, I’m happy with the system taking a bit of time rebuilding the file cache periodically, and possibly deleting cache data if it’s over 12 months old (which would then need to be rebuilt when I next access that folder in the future).
I would not like any RAW developer or editing program to change the original RAW file in any way, indeed, if I knew this was happening, I would probably make the RAWs read only. The RAWs are my original archive files, I do not want them changed in any way.
The first feature missing on the Mac Version, is the ability to move the datebase.
The second feature, very important, is an automatic backup of the database. Advanced users need preferences ti adjust it with precision and other users need a backup completly invisible.
The database being a central element of the software, it must be considered that it is impossible to delete it and its integrity must be ensured in all circumstances. So, we need integrity check and optimizing functions.
Antother thought about images data. The most important thing with images is metadata. If I loose the development work, can can redo it (it’s very easy and fast with a software like PhotoLab). But, if I loose matadata, it is more problemaic. In twenty years, how can I remerber the pitcure taken circumstances ? In this case, saving metadata in sidecar files is not a good idea as it is impossible to keep the image file and its sidecar together FOREVER. Saving metadata directly in the original file would probably be a better idea.
Which writing metadata to undocumented raw file formats most definitely does not.
Then maybe you’ve passed the collection on to the wrong people.
Or until that undocumented format is no longer read by the software of the day.
I understand the problem, but embedding metadata, however standardised, in undocumented file formats is still the wrong solution. If you want to ensure that your metadata survives future technology shifts and software evolution then you’re far better off sticking to standardised formats all the way. Who do you think is going to spend time on our ancient raw file formats with no documentation after we’re gone if the software of the day doesn’t handle it, which it very well may not if there are possibly multiple variants caused by different software writing in different ways over the years and no one know which is “correct”? I wouldn’t bet the farm. Even with TIFF there are occasional problems with files written by one application not being readable by another so why make it even more difficult by starting with raw file formats that have zero public documentation at all?
For longevity, I wouldn’t bank on raw files being usable at all, I’d stick with a format like TIFF. Also more reliable for rendering. Every PL upgrade so far has introduced small changes in the rendering of existing sidecars, so even if there is a PL 104, I wouldn’t bank on it rendering my PL4 sidecar identically to PL4.
Writing on the back of prints is probably better yet though.
I would expect them to read current sidecars, but I wouldn’t assume that those sidecars will be rendered identically in future versions of the PL, unfortunately. As I mentioned in my previous post, every PL upgrade so far has introduced small changes, and even if they’re small from one version to the next (eg. I had skies that were slightly more saturated in PL3 compared to the PL2 I’d edited in) and DxO does try to minimize them, it’s seemingly best effort rather than a more formal guarantee. There’s no process version like you can find in some other applications.
I am very disappointed to learn that there even is a database. One of main things (I thought) I liked about PL4 was that all of the information was in the sidecar(s)–no databases or catalogs like Lightroom & Capture One–that can become bloated and potentially corrupted.
My preference is to kill the database and put whatever is needed in sidecars where they are obvious and manageable by me (the owner).
That’s my approach/perspective too … and it’s excellent that PL allows us to work like this (a database is still maintained, but just for operational efficiency purposes).
So far, PL has always been backwards compatible, in the sense that each new version is able to read/absorb sidecar/.dop files from any previous version - but, there’s no guarantee that the results will be identical ! For example, somewhere along the way, changes were made to Smart Lighting that did not produce exactly the same results as the pre-change version.
No need to be disappointed ! - If you prefer to rely only on sidecar/.dop files (as I do too) then you can simply ignore the presence of the database … in which case, it simply provides some operational efficiency.
To work this way, you just need to ensure you have these Preference settings ON:
… … For the Win version.
In fact, I invoke PL with a self-written “wrapper” that deletes the database (and the cache) each time before it starts-up PhotoLab … where I am able to delete the cache without performance impact 'cos I’m using a work-in-progress-folder approach (I don’t expect PL to wade thru 100s or 1000s of images).
There are some implications of this approach to note: Project details, Keywords and inter-session History (when it becomes available in the Win version) are not held in the sidecar/.dop file.
That is precisely why I am disappointed. I want the full history of all my images and never wanted or expected the PL4 would maintain a database.
I have already done as you suggested, but never realized that moving a file with sidecar(s) was not moving all of the adjustments made to that image.
However I do appreciate your reply, but hope that DXO takes a long hard look at this and changes their strategy. As a long time developer, I know a database is not necessary to accomplish this, so long as users are informed about the value of those sidecar files.
If DXO insists on offering a database to hide some data from users, that should be clearly delineated and explained opt-in option, not the default.
I am not qualified on the subject of the fine points of databases vs. the rest–I just know that I do not want to be forced to use a database akin to Lightroom. I like using the folder structure on my hard drive as I periodically remove images through deletion or backup to an external drive and don’t want any function searching for removed items. Keep it simple and/or give users the option right from the start. I gave up on a software that added a database which activated on start up after install/update.
I imagine there are users who want a Lr style database–but there are others who do not, like me.
Thanks.
It certainly could be. Almost all computer programs store data the user is not intended to access. That is for the the user’s own good and some nefarious plot.
But, IMHO, the db is unnecessary and the data should be out in the light day.
This is the main reason that I’ve never used Lightroom. As soon as I found out that under normal operation, all photos had to be imported into a catalogue that had to be constantly updated in order to use the editing functions, I said no thanks.
. I must have the possibility to backup and restore (it’s implemented), by closing DPL it would be fine if i got a message to backup ( like LR does it with the catalog)
with your family
… For the Win version.