PM changing the byte order ?

[vinya]

I have PM 4. Can the latest version of PM revert my files back to original state?  Or are they permanently altered?

[Kirk Baker]

I have PM 4. Can the latest version of PM revert my files back to original state?  Or are they permanently altered?

There are dozens of versions of Photo Mechanic that start with 4.  What is your specific version number? 4.5.4?  4.6.2.1?

-Kirk

[vinya]

I just updated to latest version and tried deleting the PM data. This time it worked! Thanks Kirk!! I hope PM and DXO will work more smoothly in future. Many thanks!!

[Kirk Baker]

I just updated to latest version and tried deleting the PM data. This time it worked! Thanks Kirk!! I hope PM and DXO will work more smoothly in future. Many thanks!!

As long as you instruct PM not to modify your RAW files and you don't use things that must modify the RAW file in order to perform their function (GPS import/add, Adjust Capture Times and Dates) then you shouldn't have any problems with DXO.

-Kirk

[Phil Harvey]

Wow.  From what I have read, DXO is definitely NOT parsing the TIFF structure properly.  Software like this is very fragile an will break easily with camera firmware updates, etc.

I would suggest dropping DXO and switching to something where the programmers have a clue.

FWIW, I have done extensive testing with edited ARW images and the Sony IDC utility, and it couldn't care less if the data moves around in the file because it follows the proper TIFF pointers (as it should) to find the data.

- Phil

[AlexKarasev]

Wow.  From what I have read, DXO is definitely NOT parsing the TIFF structure properly.  Software like this is very fragile an will break easily with camera firmware updates, etc.

I would suggest dropping DXO and switching to something where the programmers have a clue.

FWIW, I have done extensive testing with edited ARW images and the Sony IDC utility, and it couldn't care less if the data moves around in the file because it follows the proper TIFF pointers (as it should) to find the data.

In terms of the sophistication of lens aberration correction and raw development options (once it manages to read the RAW file :-) ), DxO is class-leading - meaning many of us can't casually dismiss it and find the same capability elsewhere. (My livelihood ultimately relies on delivering work my clients love, not on ease of handling the metadata in those files).

That said, Phil's point about the Sony IDC utility not having trouble correctly interpreting the DSLR-A900 ARW files which PhotoMechanic has enriched with embedded metadata, kills DxO's argument that they follow any legitimate manufacturer's standard.

I think we should petition DxO to use the TIFF offset in ARW files so the embedded metadata fields can be used. Kirk, can you weigh in on how we can precisely frame the technical point here? (I think I get the issue but would not want a not-quite-right word to undermine the power of the argument there). Then we can write the rest and push it through.

[Kirk Baker]

Alex,

Wow.  From what I have read, DXO is definitely NOT parsing the TIFF structure properly.  Software like this is very fragile an will break easily with camera firmware updates, etc.

I would suggest dropping DXO and switching to something where the programmers have a clue.

FWIW, I have done extensive testing with edited ARW images and the Sony IDC utility, and it couldn't care less if the data moves around in the file because it follows the proper TIFF pointers (as it should) to find the data.

In terms of the sophistication of lens aberration correction and raw development options (once it manages to read the RAW file :-) ), DxO is class-leading - meaning many of us can't casually dismiss it and find the same capability elsewhere. (My livelihood ultimately relies on delivering work my clients love, not on ease of handling the metadata in those files).

That said, Phil's point about the Sony IDC utility not having trouble correctly interpreting the DSLR-A900 ARW files which PhotoMechanic has enriched with embedded metadata, kills DxO's argument that they follow any legitimate manufacturer's standard.

I think we should petition DxO to use the TIFF offset in ARW files so the embedded metadata fields can be used. Kirk, can you weigh in on how we can precisely frame the technical point here? (I think I get the issue but would not want a not-quite-right word to undermine the power of the argument there). Then we can write the rest and push it through.

I'm not sure there is an argument that will influence them.  They claim that they have specifications from the camera manufacturers themselves, which I find hard to believe since we have contacted several of the manufacturers and none were willing to divulge the proprietary information about their file formats.  Basically, most RAW formats are based off of the TIFF file format which itself is well-documented.  TIFF files are arranged in such a way that various offsets tell a parser where to find items in the file, and whether the data is in Motorola (big-endian) or Intel (little-endian) format.  RAW files (speaking generally here) usually have the table containing the offsets starting at 8 bytes into the file.  Four bytes into the file contains the offset to this table and its value is usually 8.  A naive parser wouldn't bother reading that offset since it would assume that it would be eight anyway and then expect the table to exist at offset 8.  But this won't work at all if the TIFF table has been relocated to a different part of the file and the table offset changed to point to that location.  This is a perfectly valid thing to do (and it's what Photo Mechanic does) but it would trip up a parser that expects the TIFF table to be located at offset 8.  I don't know how hard-coded their parser is since I don't have access to their code, but I would expect that each RAW file format parser expects various data to always exist at precise offsets inside the file and that if any of the data resides at a different offset then errors will occur.

Since PM can be told to work entirely with XMP sidecar files (not embedding anything at all) this would likely be the best way for DXO/PM users to work.  Don't allow PM to modify your RAW files and you should be fine.  If there ever comes a day when the DXO folks decide to make their parsers more flexible then you can change your settings in PM to embed metadata or not.

HTH,

-Kirk

[AlexKarasev]

Thanks Kirk

A colleague has suggested that I look into PhotoMechanic precisely because it embeds the metadata - i.e. that was a selling point for me.

I presently use lightroom v3 beta for workflow, selection and tagging, on a fairly fast machine, DxO to develop my top 20% raw images (LR3b is perfectly usable in many cases).

Other than performance, what would you say are key advantages of Photo Mechanic over Lightroom 3 ?

[Kirk Baker]

Thanks Kirk

A colleague has suggested that I look into PhotoMechanic precisely because it embeds the metadata - i.e. that was a selling point for me.

I presently use lightroom v3 beta for workflow, selection and tagging, on a fairly fast machine, DxO to develop my top 20% raw images (LR3b is perfectly usable in many cases).

Other than performance, what would you say are key advantages of Photo Mechanic over Lightroom 3 ?

They have different uses.  Photo Mechanic does not do RAW adjustments at all.  Lightroom does do RAW adjustments.  Photo Mechanic excels at downloading your files, previewing them at a high rate of speed, allowing you to separate the wheat from the chaff.  Photo Mechanic has some of the most powerful keywording and captioning capabilities around. Lightroom does these things, but much more slowly.  If time is important to you then Photo Mechanic may be for you.

Though I will say that if you want to use PM with Adobe products, you should adopt an XMP-sidecar only workflow and should not embed XMP into your RAW files.  Embedding XMP into RAW files causes problems for Adobe's applications.

-Kirk

[Hayo Baan]

Though I will say that if you want to use PM with Adobe products, you should adopt an XMP-sidecar only workflow and should not embed XMP into your RAW files.  Embedding XMP into RAW files causes problems for Adobe's applications.

While adopting an XMP-only workflow when using Adobe products on RAW files sure is the easiest approach, you definitely can embed IPTC/XMP and have everything work fine together (and is what I do).
You just have to be a bit more careful in this case and only update the IPTC/XMP info within PM. Well, even this is not completely true; you can even alter/add IPTC/XMP info with Adobe products just fine.  You then just have to have your PM XMP/IPTC preferences right (use the sidecar first), and always have PM "update" the IPTC/XMP afterwards to make sure the embedded data is synchronised with the sidecar info. If this sounds too complicated, stick to the sidecar only approach 

Cheers,
    Hayo