PS6 not saving EXIF! Help!

[dacar]

Hi everyone.
I did some editing in PS6 the other day and noticed that the EXIF data is not saving. I know how to make sure it is saved in the "Save for web..." dialog, but can't see where to ensure it is saved in .PSD format. The data is saved with .TIF and .JPG formats but not when I save in .PSD or .BMP formats. Very strange.. because it used to be OK. I may have changed something when I did a clean install in January.
Any help gratefully accepted.

[Warbler]

How are you trying to read the EXIF in your PSD files?

[ameerat42]

In Photoshop, have you checked that it is still there in the said formats?

[dacar]

Thanks for the responses.
Here it what I have discovered since this morning:
When I open all versions of a file (including the RAW - NEF- format) in PS6, I can see some EXIF data by going to File-File Info... on the menu. The dialog displays basic info under "Camera" and more stuff under the "Advanced" and "Raw Data" tabs.
When I open the files in a couple of viewing programs (FastStone and ExifPro) and by selecting "Properties" from the right-click menu in Explorer I see extensive EXIF data only for the TIFF and the NEF files and the JPG files i have created since discovering this issue.
So, why is the data visible in PS6 and not elsewhere?
And how can I prevent its loss in future?

[ameerat42]

Loss? If it's still visible in PS then it's not lost. Sounds like the other progs just can't get to it???
I have FastStone and can see that it doesn't show EXIF in a PSD. It does show it for a jpeg AND for
the original RAW file (though a bit less for the raw).

So if you're asking HOW to see it in PSDs, I cannot help:o

[Lance B]

Are you saying that only your jpegs are not showing the EXIF? If so, how are you saving the jpegs? 8bit or 16bit?

[Warbler]

PSD is an Adobe format so that is why you can see it in PS CS6. Other programs may or may not be able to either preview the PSD, or read the EXIF. Why are you using faststone anyway? Try using Bridge which you have already as part of CS6.

[ameerat42]

Dacar. If you save that PSD again as a JPEG, you will see the EXIF data again with FastStone.
(At least I did!:nod:)

[farmmax]

I use faststone as my main photo viewer/renamer/resizer/organiser even though I edit photos in photoshop. Bridge is a drag on resources and is my last go to photo organiser. Faststone is fast and zippy and can run in computers with very limited resources. Yes, don't worry, the PSD exif information isn't lost. It is as Warbler says, the .psd format is an Adobe created format mainly for use in Adobe software. Luckily these days many other photo viewers including Faststone can view .psd. Many years ago, very few programs outside Adobe supported .psd files at all.

[Warbler]

I only ever use FastStone for creating Slideshows or screensavers. Bridge is IMHO superior in almost every way to FastStone for cataloging and managing/renaming/resizing and accessing ACR for individudual and batch editing. Commercial quantities of images are no problem. I'm running Win7 64-bit ultimate with 32gb of RAM though.

[ameerat42]

But I think it's that he can't see exif in other progs.

[Warbler]

Yes, but that's why I asked what programs he was using. If he wants to save files as PSD, then he should use a program that reads PSD and the EXIF if that is what he wants to read. FastStone can view the PSD, but it won't display the full EXIF. ACDSee will both view and read EXIF on PSD files, but Bridge is free because he already has Photoshop.

[ameerat42]

But getting back to the nub: no, he won't see much exif like that:(

[dacar]

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.

[Warbler]

When you're using Bridge, don't put the PSD files in the same directory as the RAW files and JPEG files. There is a bug in the system which makes it not preview the images correctly sometimes. Also, not creating 100% previews in the settings will speed things up. Make sure your cache is nice and large too. Drop me a PM if you have problems and I'll try to help you.

[arthurking83]

Thanks for all your comments. .......


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! .....


I did some snooping:

exif is(and isn't) there in the PSD file.
(FWIW tho, doing some of these tests, this is the first time I've ever used the PSD format, so my knowledge of it is extremely limited. If I acquire any more understanding of it in any way, I'll post back again)

So with that in mind, the metadata stored in the PSD file is actually stored in the PSD file .. not seperated into a sidecar file.

What I did:
I took an image(Nikon NEF originally) which had loads of data already embedded. I always keyword my raw images when necessary, so the keywording was also embedded into the file. ViewNX2 was used to achieve this.
So to be clear, all the metadata available was embedded into the original raw file!

(on a side note: I believe that using programs like Bridge/Lr/and others that create separate sidecar files for the metadata can create issues in the future! .. but this isn't relevant in any way for this thread!)

I loaded the NEF file into PS, and saved it into a PSD file(my very first ever). I kept the same original file name of DSC_<something-or-other> (again there is no relevance to the file name .. except)

I then used Windows explorer to rename the PSD file, and saved it to another hard drive .. just to be sure that when viewed again in PS, the PSD file and any possible sidecar file used for metadata were completely isolated.
There was no way that using PS now to open this newly named file, that PS would somehow associate it with any externally created metadata file created for the original.

If you do this with a file where the metadata was stored externally(eg. as Lr and Bridge do) .. then you lose the association if the two files are 'separated'. This is easy to reproduce for those that want to see the result.

So with my best effort to separate the PSD file and any potential external sidecar file, PS still read the embedded metadata 100%.
What this proves is that the metadata is saved within the PSD. (and to be sure, exif is only one part of a host of metadata types possible .. IPTC is another)

The other thing that is easy to prove for yourselves(if interested), is that you can also view the metadata in the PSD using other software.
The catch is that this software has to be able to read XMP type metadata.

XMP metadata is an Adobe created metadata type encompassing a host of other metadata types within it's fold. Exif is contained within the XMP metadata embedded in the PSD file.

For an easy to use program to view PSD metadata .. try Jeffrey's Exif Viewer (http://regex.info/exif.cgi).
Note for the (rightly!!) cautious. That link is to a web based exif viewer site. I've used this site for years now and can confirm that is' safe to use.
You use the browse function to locate your file(in this case PSD) and it will present the image in all it's glory .. whatever glory you added via your tagging routine!

With my renamed PSD file, loading into this website not only returned an image of the PSD file, but even showed me where the shot was taken on a map, as I had my GPS connected to the camera at the time.

So all the exif IS stored in the PSD file(which is good! :th3:).

The reason not many programs can view the embedded metadata is most certainly due to that point that those external programs can't read the XMP metadata format.

Some searching around confirmed that FSViewer doesn't read XMP metadata .. nor IPTC(which is what I mainly concentrate on with my keywording).

The OP said that they used to be able to see exif in the PSD at some earlier stage, and if this is the situation, then maybe Adobe changed the way that they used to save embedded data in the PSD file format :confused013

Hope that helps.

(ps. I'll look into it a bit more at some point in the immediate future, and will try to get back with any more info if I find it)

[farmmax]

When you're using Bridge, don't put the PSD files in the same directory as the RAW files and JPEG files. There is a bug in the system which makes it not preview the images correctly sometimes. Also, not creating 100% previews in the settings will speed things up.

And you wonder why I prefer Faststone :lol2: I run it with sorting by file type so it puts my psd files last in every folder. It creates thumbnails and full previews a mile faster than Bridge, and I never have to worry about my cache (other than for photoshop)

[Warbler]

And you wonder why I prefer Faststone :lol2: I run it with sorting by file type so it puts my psd files last in every folder. It creates thumbnails and full previews a mile faster than Bridge, and I never have to worry about my cache (other than for photoshop)

No, I don't wonder at all Farmmax. The point is that you still can't view PSD EXIF data in Faststone can you? :rolleyes:

[Warbler]

Here's a screen shot. There are over 9,000 PSD files in this one directory. Some are layered. Some are not. They all contain the original EXIF data. The data can be searched or filtered in the panel on the bottom left. The cache is there and every time I open this folder, Bridge simply reads the cache. It doesn't have to recreate the previews again.

The reason I suggested Bridge to dacar was that he already had PS and Bridge is part of that. He wanted to be able to view the EXIF in his PSD files. Why not use what you already have? Sure, he could buy Lightroom and use that. Faststone though, will not show the EXIF in a PSD file, and Windows will not even preview a PSD file.

118450

[arthurking83]

...... Faststone though, will not show the EXIF in a PSD file, and Windows will not even preview a PSD file.

.....


Actually, if the exif in a PSD file was created in a standardised manner, I believe that Fastone would display the exif in a PSD file.
Not that such speculation helps the OP .. just a point that should be made.


..... The reason I suggested Bridge to dacar was that he already had PS and Bridge is part of that. He wanted to be able to view the EXIF in his PSD files. Why not use what you already have? ...

While this is a fair enough point to make, the issue is that the assumption is that dacar's workflow is the same as yours. It may well not be!

A simple case in point could be something like this:
The person to whom the answer is directed at may have multiple computers to which they would then have to then install Bridge(and hence PS) on all those devices. Of those multiple devices, we can't assume that they all have the latest and greatest specifications.
I myself have a Windows 7 tablet(purchased a few years back now) .. it's specs are pretty terrible, but do the job I required of the tablet.
Running Bridge(let alone PS) on this Atom powered tablet would be impossible(especially now that much or most of Adobe's software is 64bit only)
So as said by farmax, the OP may be running FSViewer simply for the sake of resource management!(I know I do).

While Bridge may be superior to FSViewer for cataloging images, it's not the ideal manner in which to do so.
Such a workflow limits yourself to using Bridge to view this tagged info(in many image format types) .. especially raw images. Heed the warning that you become locked into this software after a while.
(I can tell you from experience, once you reach a certain level of multiple tens of thousands of image files that may need to be re tagged all over again from scratch .. using Bridge to tag important info is being locked into Adobe's software!
Anyhow ..
There are better ways to tag your images(especially raw files) so that all raw file viewers(even Windows!!) can see this tagged info.

The one thing that Adobe are trying to present to the world in general is that they are offering this software product(in this instance the concept of XMP metadata presentation) in the form of full compatibility and backward compatibilty .. yet somehow manage to break compatibility to the previous manner in which the way the metadata was originally presented!
Exif is a standard, and still is a standard. Adobe's method of embedding it into XMP data is the cause of the issue described by the OP.
The issue is the same in Irfanview as well.
While they can read the image format without issue and render it as an image, this metadata method that Adobe chose to use is the root of the display problem.

I just found that Picasa also has the ability to render Adobe's PSD format .. and that Picasa can also read the XMP metadata format. Yet it too doesn't read the XMP data within PSD files!

BTW! it's a dreadful program for image management!

While this may point to the issue lying squarely with FSViewer, Irfanview and or Picasa in not being able to read the Adobe file formats properly .. my thoughts are that it's actually the other way around.
Adobe need to understand that the open and standard format philosophies that preceded theirs worked across all products .. prior to their convoluted interruption!

To the OP again:
If loading your PSD images to the www for quick browsing doesn't appeal(and why would it), and you are firmly against using Bridge to view exif properties in those PSD files too .. then for local hard drive browsing I can recommend exiftool and exiftoolGUI to quickly browse through your PSD files for their exif data.
exiftool is great, but annoyingly commandline only.
If you have a Windows PC, you can use exiftoolGUI(graphical windowed extension for exiftool) to easily view the metadata embedded within the PSD file.
Only issue here tho is that it won't display an image of the file.
It works with raw files too, as long as the respective raw file manufacturer's codecs are installed on the PC.

So at the moment you're stuck with Warbler's recommendation to use Bridge to view both the PSD images and the exif data.

[Warbler]

At the risk of getting into a long dissertation with someone who has way too much time on his hands:D, 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.:cool::nod:
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! :D).

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/


118510 (https://www.facebook.com/groups/195567190503489/)

[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 (http://regex.info/exif.cgi) 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 :D).
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.