Phase One P45+

[thinbegin]

Hi, I'm starting this thread on the long-cold heels of one I found from years ago here:
https://exiftool.org/forum/index.php?topic=3071.0

I recently bought a used Phase One P45+ digital back and, as with all my image files, I like to add/change some of the exif data before importing into LightRoom. This is proving to be a problem for the TIF files that are generated by the P45+

To break the issue down, as I experience it, I've done a few steps.

First thing I did was copy some of the image files (.TIF extension) onto my hard drive and then just did a simple "exiftool ./myimage.TIF" command to read the data (before attempting to write anything)

I saw some interesting data in there, a couple of which I'll list here:

Code Select Expand

Make                   : Phase One A/S
Camera Model Name      : P45+
System                 : Phase One Camera back
Firmware Versions      : P45+-V, Firmware: Main=2.9.8, Boot=1.3, FPGA=1.3.4, CPLD=1.2.4, PAVR=1.0.5, UIFC=1.0.1, TGEN=1.0.1

Upon seeing that, I was encouraged because it seemed to me that I should be able to write over the "Make" and "Camera Model Name" values with actual camera info, and still retain the pertinent Phase One identification info in the other two (custom?) key/value pairs. Unfortunately, that doesn't seem to be the case.

Running the 'exiftool -overwrite_original_in_place -make="Hasselblad" ./myimage.TIF' command, I was greeted with the following error/warning:

Code Select Expand

Warning: Maker notes could not be parsed

Ok, so I found reference to this error on the excellent exiftool FAQ page, and then tried the same command, with the suggested "-m" flag:
exiftool -m -overwrite_original_in_place -make="Hasselblad" ./myimage.TIF

Adding the new "-m" flag did force the write operation (by ignoring the warning), BUT.... doing so also destroyed some of that "maker notes" stuff, and the "System" and "Firmware Versions" values were not preserved.

So, in a nutshell, the issue is... When writing to these Phase One (model P45+) files, a fair amount of the exif data that Phase One placed gets clobbered. Is there anything that can be done about this? I know these digital backs are quite old at this point, but they are still very usable (and hell, I never could have afforded one when they were new!)
Being able to write camera model (and other) info to them would be a HUGE benefit.

Oh, and in the name of being thorough, I also tried a couple other variants of the exiftool write command, but they all had the same effect of wiping out a fair amount of the exif data that would probably be classified as "maker notes". Here are a couple of the command variants I tried:

1) I tried writing both with and without the "-overwrite_original_in_place" flag
exiftool -overwrite_original_in_place -make="Hasselblad" ./myimage.TIF
exiftool -make="Hasselblad" ./myimage.TIF

2) I tried writing both with and without the "-m" flag
exiftool -m -make="Hasselblad" ./myimage.TIF
exiftool -make="Hasselblad" ./myimage.TIF

3) I also tried re-writing a couple of the clobbered fields
exiftool -overwrite_original_in_place -make="Hasselblad" -system="Phase One Camera back" ./myimage.TIF
exiftool -overwrite_original_in_place -make="Hasselblad" -firmware_versions="P45+-V, Firmware: Main=2.9.8, Boot=1.3, FPGA=1.3.4, CPLD=1.2.4, PAVR=1.0.5, UIFC=1.0.1, TGEN=1.0.1" ./myimage.TIF

(and I tried all possible combination permutations of the above variances)

Finally, I should mention my environment details.
Operating System: MacOS 10.15.7 (Catalina)
exiftool version: 12.10

Is there any hope for the exiftool being able to write to these files without losing any of the data?  Thanks so much for all of the (massive and insane) time you've put into the amazing exiftool!!!! It is an absolute dream utility of mine!

[StarGeek]

One thing to do is make sure you're using the command in FAQ #3 so you can see duplicate tags and the groups they belong to.

The Make and Model should be editable as long as they are in the EXIF block and not one of theMakerNotes groups.  But I never advise using the -m (-ignoreMinorErrors) option especially with regards to MakerNotes.

But otherwise, this will require Phil's attention since I'm unfamiliar with internals of the files created by that camera.  He's currently away for a couple of weeks.  You can hit the Notify button in the upper right corner of this thread to get a notification when there is a response.

[thinbegin]

@StarGeek, thanks for the response.

I did try to edit "Make" (a standard exif value) and, as outlined in my original post, doing only that (and nothing else) both required the "-m" flag, AND clobbered the other data that was present before the edit/write operation.  Trying without the "-m" flag only threw the warning mentioned without making the requested edit, so not using that flag doesn't seem to be an option.

[StarGeek]

If you can make a sample available for Phil when he gets back, that would be helpful.  He might want to take a look at what is happening.

[thinbegin]

I'd be happy to.... but a sample of what exactly? LOL.  Just a few sample image files? Yeah, zero problem there, I've a handful at least. I can zip them up and give a download link, unless there's some other way that is preferred. Oh, and if I'm wrong about what you are asking for, then just let me know what is needed. 

Thanks again!

[StarGeek]

Yes, a sample image file.  If they images need to be private and you don't want to link here, you can send Phil a forum PM with the link, just refer to this thread so he knows why.

The link needs to be stable for a few weeks, though.  As I said, he's away from the net for a while.

[thinbegin]

Ok great, thanks!

I don't know what this server's file size limits are, but I tried to zip up a few image files and attach to this message, but the file size was too large, so I've made it available via my DropBox account. Here's the download link for the sample image files:
https://www.dropbox.com/s/fwwa2pfd65z643g/P45%2B_sample_images.zip
(I'll leave it available until I hear news that it's been retrieved)

[Hubert]

Just an observation:

If you attempt to set the Make to quite a few other cameras (I tried Olympus, Panasonic, Kodak, Mamiya...), the MakerNotes in your files remain readable without using the -m option.

If you try the same thing with Nikon, Canon, Minolta (and obviously Hasselblad), you can change the Make using the -m option, but this renders the MakerNotes unreadable.

Now, if you take one of your "clobbered" pseudo-Hasselblad images and run

Code Select Expand

exiftool -make "Phase One A/S" ./myimage.TIF

followed by

Code Select Expand

exiftool -g ./myimage.TIF

You can once again read the MakerNotes, without any errors:

Firmware Versions               : P45+-V, Firmware: Main=2.9.8, Boot=1.3, FPGA=1.3.4, CPLD=1.2.4, PAVR=1.0.5, UIFC=1.0.1, TGEN=1.0.1
Software                        : Camera back, Main firmware: 2.9.8
System                          : Phase One Camera back

So the MakerNotes haven't been deleted or corrupted, just made temporarily unreadable. This leads me to wonder if ExifTool expects Hasselblad MakerNotes to be coded in a non-standard format, and uses the Make tag "Hasselblad" as a trigger to parse the MakerNotes in a different way.

You can change the Make on these images to "Hazzelblad" or "Hassie" or any mis-spelled variation thereof and the MakerNotes remain readable. Just not "Hasselblad".

Edit: But as Phil said in another thread https://exiftool.org/forum/index.php?topic=3808.0:

I wouldn't suggest changing the Make or Model because this is important information that may easily break things for readers if this is changed.

[thinbegin]

Ok, so your sleuthing is really interesting (and kinda weird).  It's looking more and more like that a "make" value of "Hasselblad" triggers a process fork for some reason. Seems a strange decision, since "Hasselblad" would be a very valid value for that data point.

If I try
exiftool -make="Hasselblad" ./myfile.TIF
It doesn't update. Instead I get the warning

Code Select Expand

Error: [minor] Maker notes could not be parsed

But if I use any of the following
exiftool -make="Hässelblad" ./myfile.TIF
exiftool -make="Hassey" ./myfile.TIF
exiftool -make="Cow" ./myfile.TIF
exiftool -make="MyMadeUpCompany" ./myfile.TIF
Then it updates fine AND it retains all the extra "maker notes"

If I try
exiftool -m -make="Hasselblad" ./myfile.TIF
It DOES update, but at the cost of no longer having access to those other "maker notes" fields

What's odd is that the word "Hasselblad" must be a process control in both read and write exiftool operations, because if the "make" value is set to "Hasselblad" (by use of the -m flag) then the extra "maker notes" fields are absent from the readable output of the exiftool ./myfile.TIF command, but if I then go in and change the "make" value to something else (on that same file), then the "maker notes" data becomes available again. Fascinating!

Do you think there is any hope that maybe the process(es) that is/are triggered by the value "Hasselblad" might be changeable to something else? Something that wouldn't be an actual valid value? Maybe something like "Hasselblad-Control" or something? that way the process fork could be retained whiles still allowing for full use of the valid value of "Hasselblad".  According to what was written above, such a change might also be necessary for a couple over valid values as well, namely, Nikon, Canon, and Minolta.

[Hubert]

Do you think there is any hope that maybe the process(es) that is/are triggered by the value "Hasselblad" might be changeable to something else? Something that wouldn't be an actual valid value? Maybe something like "Hasselblad-Control" or something? that way the process fork could be retained whiles still allowing for full use of the valid value of "Hasselblad".

Only Phil could say for sure, but I doubt it. Ultimately "Hasselblad", "Hässelblad", "Hazelblad" etc aren't valid -make tags for your images: the metadata was written by the Phase One back, and "Phase One A/S" is the only valid -make.

[thinbegin]

the metadata was written by the Phase One back, and "Phase One A/S" is the only valid -make.

I respectfully disagree with this completely.  That ignores the rest of the system necessary to make the image, which is kind of counter to the concept of a system camera.

Take, for example, when I scan film that I shot on a Canon camera (any camera really).... The (scanned) film image's exif data states that the "make" of the device is Epson (If I used an Epson scanner to scan the film), which is blatantly untrue. The Epson was the digital capture device, but it wasn't the camera (not, more importantly, the LENS) that captured the image.

This is very likely a philosophical different in perspective between you and I, and nothing more. I can see why you would say what you did, but I have a very different opinion on it.  I guess we'll perhaps see what Phil thinks. (Of course, I hope he agrees with me hahaha, seeing as I'm clearly showing a real-world example of how my suggested usage has a real-world/usability benefit).

[Phil Harvey]

When possible I try to recognize maker notes without relying on Make/Model tags.  I haven't looked at this specific example, but the Make/Model tags are usually not necessary if the MakerNotes contain a unique header.  I'm guessing these files don't.

But even if ExifTool recognized maker notes after changing Make/Model, what about other software?  I suspect you may have troubles with some image development softwares.

- Phil

[thinbegin]

@Phil,
I don't know if you've had a chance to review this entire thread or not, but it's basically been discovered that certain "Make" values seem to trigger different exiftool code execution paths/methods. I don't know what the need there is, but I respect/understand there is likely a good one. My request is that you maybe consider changing those keyword/values (EG; "Hasselblad") to be changed to something else, so that it still can be used a a control methid, but also doesn't used an actual valid value. Given that "Hasselblad" is a valid "Make" value, I see room for conflict there... but if you were to used something *like* it (I proposed, "Hasselblad-Control" as a viable option), then the functionality could remain and the name conflict could be removed, theu making it possible to use those valid values when/where pertinent.

[Phil Harvey]

FYI: MakerNotes.pm contains the code to decide how to parse the maker notes.

Also, did you see FAQ 8?

- Phil

[thinbegin]

Yes, I have read FAX #8 many times now LOL... What that tells me is that it's a bad idea to alter the make/model info, which I can fully respect (even though it was once considered a bad idea to alter ANY exif data.... and then exiftool came along to show that was silly), but what FAQ #8 doesn't do -- unless I've missed it over the course of my re-reading of it, which is entirely possible -- is offer an alternative solution to the task. Clearly people have a need and (many?) use cases for wanting to change that info, so if it is strongly advised to not change it, it would be awesome to also provide some potential alternative solutions to the users' needs.  I've no problem solving this issue another way, I'm just not sure what said "other way" might be, seeing as the excellent exiftool has been my go-to solution for so long.