PS6 not saving EXIF! Help!

[Warbler]

At the risk of getting into a long dissertation with someone who has way too much time on his hands, if you believe that FastStone will read the EXIF data "in a PSD file was created in a standardised manner", then why don't you create one and report back?

Why would you assume that I'm assuming dacar's workflow is the same as mine? I make no such assumption.
If dacar is using PS to convert RAW files, or to edit JPG files, which from his first post, I assume he is (you can quote that assumption), then any keywording, tagging, etc he inputs using Bridge will be accessible to all the programmes you mention in any JPG file created, and via Bridge or LR in any PSD file created. Sure, in the case of PSD files, he needs to have the program installed on any computer he wants to use to access that data. He's licensed for two copies if he has standalone CS.
XMP files only come into the discussion if we're talking RAW files. He can choose to have his data inserted into XMP files in which case he'd need to loose all the XMP files to lose all the keywording/tagging. If he chose to put all his data in a central database, then it would be easier to lose all that in one event, but that is not unlike LR is it? In Bridge, he can even export the cache to the folders containing the files. It is important to reiterate here that this relates to RAW files. There are no XMP files for PSD. The information for those is kept with the file, just like with JPG files.

I think you need to do a bit more research Arthur. That's a friendly suggestion, not a criticism by the way. Dacar asked why he couldn't see the EXIF in his PSD files. He's been given an answer that will work for him using what is already installed on his computer. I'll leave it at that.

[ameerat42]

Thanks for all your comments. Been a bit tardy in getting back to this post - life gets in the way of photography sometimes.
So, it seems that the exif is still there, but not accessible by all viewers. Adobe products put the data somewhere only they can get at it - what a nasty trick! Saving everything in jpg is not always a good idea because of loss of flexibility.
It looks like I will have to be careful about which apps I use to view my images - different apps for different purposes: FastStone for quick viewing, Bridge for sorting and cataloguing... What a pain.
Thanks again everyone.

From the response here, Dacar has understood and appreciates the salient points of the discussion preceding Post14.
Am(certain, in fact).

[Fruengalli]

Why not just use & save in tiffs?

[ameerat42]

Why not just use & save in tiffs?

If he's using Pshop, Fruengalli, wouldn't the proprietary format be better? - At least one might tend to think so.
Anyway, what reasons would you suggest for doing so?

Am.

- - - Updated - - -

PS: That is, have you found that it addresses the problem he has reported - the variable display of EXIF?

[Fruengalli]

If he's using Pshop, Fruengalli, wouldn't the proprietary format be better? - At least one might tend to think so.
Anyway, what reasons would you suggest for doing so?

A

PS: That is, have you found that it addresses the problem he has reported - the variable display of EXIF?

Quick search on the interwebs is that there is no great save outcome unless you choose to use other Adobe products..just sayin

[arthurking83]

..... There are no XMP files for PSD. The information for those is kept with the file, just like with JPG files.

I think you need to do a bit more research Arthur. That's a friendly suggestion, not a criticism by the way. Dacar asked why he couldn't see the EXIF in his PSD files. He's been given an answer that will work for him using what is already installed on his computer. I'll leave it at that.

Yep! fair enough.
I am actually doing more research .... than is good for me, as I have no interest in PSD(nor most of Adobe's software).

But the comment that XMP files only come in the equation is something I did research. And the PSD file format uses the XMP model of metadata retention .. not the older systems such as exif or IPTC.

If you have a read of what the XMP format is(or supposed to be) .. it's a 'modern' format that encapsulates the older metadata formats into one, without breaking the backward compatibility of the older types..

In simple terms: in the old pre XMP days, you had exif data(of various version) and you had IPTC metadata. Both of which were separate sets of data/info contained within the construct of the file(no matter if it were raw, tif, jpg, whatever .. even PSD I suppose)

But then came XMP. The new format is like a capsule, that entangles the exif and IPTC(and others that aren't important to us photographers) within it's frame.

If the software isn't able to read the XMP format, then it can't read the exif .. even tho the exif is definitely there.

If you check out the links, or suggestions to some of the tools I'd made in my posts, you will see that the PSD format doesn't strictly contain the exif data in the format that the older non XMP compliant software can understand.
if the PSD format didn't use XMP, then the XMP tag in any XMP capable metadata viewer software(what we used to refer to as exif readers!) woudl either not exist, or be completely empty.
Yet in my PSD files it contains lots of data, mainly referring to lots of Adobe created editing steps and suchlike.

And for clarity. The XMP data I'm referring too is not of the type(I think you're thinking of) which may be the small sized external meta files created for individual image files.

The XMP data format can be contained within the file itself.
I don't know enough about DNG to safely say this, but I think DNG files can natively contain the XMP data embedded into itself(as opposed to having it externally saved).
It can be both external and embedded .. and in the case of PSD, it's embedded.
(there may be some way to save it as an external file to, but I haven't researched this in any way).

And to be sure we're on the same page .. I'm not arguing against what you're proposing as a solution. Just be aware that not everyone uses the same workflow, nor have the same hardware specs. So what may work for you, may not work for me .. but may work for dacar(or may not).
And also keep in mind that while right here and now we may be assisting dacar and the issue described, in time, someone else may search for just such a thread at some point in the future and all

One of the awesome aspects of a program like FSViewer is that you can use it in a portable environment.
That is, you could easily load it off a USB thumbdrive onto a host Windows environment, which itself could even be a temporal OS environment(ie. live) running off another medium. (great for recovery of a bad HDD, and stuff like that)

So while the advice is sound, it's not necessarily the only advice available.
I only have access to PS for only a little while longer myself(Win 10 coming soon and I plan to upgrade, so I reinstalled my OS to have access to many of the programs I once trialled long time ago(PS is one of them ATM)
This is just my personal view .. and so not a technical commentary of the program .. but I don't like Bridge at all.

Also my entry into this thread was to alert dacar that his metadata(and hence exif info) isn't somehow lost or hidden, and that it is in fact still right there in the PSD file.
(my initial thoughts were that Adobe somehow hides it in some obscure location too).
But using the tools I've described in my previous replies, I've explained that the exif data is available to view using those tools(so any effort on my part to the creation of more tools to view this data would be superfluous! ).

I don't think I'd be possible to create an addon for FSViewer, as the proprietors have no system of addons .. as IrfanView does.
Why no one has created one for IrfanView tho .. after all this time, is curious.

Going back to my comment re Picasa and it's ability to render a PSD file and read XMP data.
It seems that considering it can't display any of the XMP data in a PSD file, Adobe must be convoluting this data(in the PSD file) to make it unreadable to other software.

[Warbler]

Okay, I understand you're not now saying the XMP data is in a separate XMP file for PSD. That is correct. There is no separate XMP file created by Bridge for PSD files. However, the fact that Faststone doesn't read this is not really some deliberate ploy by Adobe. Here's a screen grab from ACDSee which shows that it reads PSD data as well as previewing the thunmbnails. It also reads the Bridge-generated keywords, labels, and ratings, as well as all IPTC and EXIF data contained in the files. The data is there within the PSD file. It is more likely that Faststone, being freeware, just didn't have the programming resources to unravel the PSD file setup.

I believe Bridge is a much under-used resource that people who have CS installed don't know about. By the way, it is also 64-bit. And in response to Fruengalli regarding TIFF vs PSD, the answer is "smartobjects". For those who want to save their edits from within PS, layered PSD or PSB (for files above 2GB in size) allow you to simply re-open and re-tweak edits.

Just to show that I'm not the only one to swear by Bridge, here's a very popular FB page with working photographers who edit photos. Ask Damien about Bridge....LOL.

https://www.facebook.com/groups/195567190503489/


ACDSee.jpg

[arthurking83]

....... It is more likely that Faststone, being freeware, just didn't have the programming resources to unravel the PSD file setup.

....

There's lots of freeware that does have the ability to 'unravel' Adobe's PSD format.

Picasa, which has the might of Google behind it, is free. It can see(or render) PSD images and can read XMP metadata .. yet it still can't display the XMP metadata within the PSD file.

exiftool can also read the metadata in the XMP section of a PSD, but it can't render the PSD file as an image .. yet Jeffrey's exif viewer which is based on exiftool can read both the XMP data and render the PSD image.
What would be ideal, would be an offline version of Jeffrey's exif viewer.

So the comment re: free software isn't just focused on FSViewer, even tho they do note on the Fastone website that they don't read XMP metadata.
The problem is also with other free software(even those with might!) that can't seem to unravel the PSD format properly.

I'm thinking that somewhere along the line Adobe is altering some aspect of the format to make it harder for other software to use effectively.
And why wouldn't they .. if you offer a paid for service, and your competitors are slowly upgrading their free services to a point almost equal to the paid service .. you would make compatibility on the free services more difficult. It forces the free services to spend more time updating their products .. which of course means added costs.

[Warbler]

I'm thinking that somewhere along the line Adobe is altering some aspect of the format to make it harder for other software to use effectively.
And why wouldn't they .. if you offer a paid for service, and your competitors are slowly upgrading their free services to a point almost equal to the paid service .. you would make compatibility on the free services more difficult. It forces the free services to spend more time updating their products .. which of course means added costs.

I doubt that Arthur. You can see from the screen shot I uploaded (or maybe not if your screen isn't large enough), that the EXIF data of the PSD file selected was created in Photoshop CS3 back in 2008. ACDSee shows that in the right hand panel there. Other files in there are created using Photoshop CS6 and they display exactly the same. I don't doubt that Adobe probably aren't easy to deal with when revealing their code, but I doubt they deliberately change or conceal it as a business strategy.

[arthurking83]

moving forward with file type compatibility, generally also means that the software manufacturer applies backward compatibility too.
So an older PSD file will almost certainly be supported if the the newer version of a PSD file is supported.

In my research about this issue, I found that there is an options check box that set the PSD file to 'maximise compatibility', so that the (newer)PSD file is set to work(in some limited way) when older software is used to access it.

If you have a look at the XMP wiki page, it lists many software that are capable of using it(read/write/append/etc).
The only company listed as having the ability to break the XMP standard is Adobe(with Photoshop!) ..

- can read/write XMP in supported images. Allows embedding of non standard XMP data through 'custom XMP panels' (Microsoft Windows, Mac OS X)

The question is; why would you allow the addition of non standard data to a data type that has been standardised?
read that as: what is the motivation to create a standard, patent it, then allow your own software to break compatibility with the thing you created as a supposed standard?

Note that on that list is a program called Diffractor. I just downloaded it to see what it's about(I'm in a software trial frenzy again with the imminent re-installation of my OS ).
It looks OK. It's a image searching software. It catalogs and displays metadata in your images.
It's supposed to render PSD files, yet on my PC I can't get it to display them. it's also very XMP aware showing all the data that I've inputted into my image files(of all sorts) except the PSD files I recently created.
That includes the newest NEF(Nikon raw) files I have on my PC(downloaded from the net .. as I don't have any of the latest Nikon cameras)

Once again, it's a case where software makers create their products and claim compatibility with specific file types, but it seems that someone is making it difficult for those makers to maintain compatibility in some way.

PS. this Diffractor software, is both free or can be paid for(for a few more features, which don't relate to this issue).
I'm just using the free version for now. It looks interesting, although I've seen three crashes in the half an hour or so I had it running.
It's probably not quite ready for prime time tho.

- - - Updated - - -

ps: I have been meaning to start a thread concentrating on DAM and DAM software, as this has become a very important aspect for me in the last few years(and especially in the last few months since Nikon have ceased support for their previous software(ViewNX2 and CNX2).

On the discussion of DAM, we can continue the conversation in that thread(if I get the time to start it) or another thread.