Oh boy, this is a big, big topic Badger. I mean it's fundamental operating system and file system usage stuff, you know? Not to say that you should already know it just because you use a computer - far from it, most people don't! I unfortunately don't have time to delve into things too deeply (ok, I lied a little, see below...), but I'll give you a few pieces of info that will hopefully help narrow your search terms and find more relevant info.
First and foremost, unless OS X is doing something magical that I'm not aware of, changing the file extension a file is *absolutely NOT* changing the actual format. The reason it probably still works as you expect is because OS X doesn't actually give a crap about file extensions at all, it uses meta data (or some other mechanism?) to know what the file type is. So changing the extension is really just changing the name as far as OS X is concerned. Further to that even if you put the file (a ".jpg" renamed from ".png") on a Windows machine it would probably still be viewable but this is *only* because any decent image viewer will be able to read both formats and while it may load expecting one, it would likely be able to automatically determine the correct format and read it. However if a viewer were attempting to *only* load data in the file type specified by the extension it would *not* work, and certainly you do not get any of the actual benefits or qualities of a given file type by doing this, e.g. reducing file size with JPEG compression by simply renaming a .PNG. Saving to JPG requires a process, it completely reprocesses and rewrites the image data. Unless, as I said, OS X is doing something crazy, which frankly would in my opinion be ill advised for a number of reasons.
Now, regarding meta data, there are at least 2 major types, and probably more. Determining the difference in a given file is unfortunately more difficult than it should be. In OS X in particular (but also now to a lesser extent on Windows) there is OS/file system meta data that is *unique to the operating/file system*, i.e. it is not embedded in the file and is likely to only be readable by that specific OS/file system. OS X stores lots of data this way, including image thumbnails, notes, etc. In any situation where you have the exact same meta data options available for *any* random file, no matter the file type, this is probably OS-level meta data, not file-level meta data. This data shows up when you transfer a file to a PC and you get those "OS X _" hidden folders and stuff.
The other major type of meta data *is* more portable, it is generally intrinsic to the file (or stored in a "sidecar" file, sort of like the .MTL that goes along with a .OBJ), and for that reason it is also often more specific to the needs of that file type (e.g. image-specific meta data for image formats). Furthermore because it is file-specific and file-*type*-specific, not every file type will have such data. Meta data is defined on a per-file-type (format) basis, generally speaking. So for example with image formats there is Exif:
http://en.wikipedia.org/wiki/Exchangeable_image_file_formatBut there is *also* IPTC, which is actually quite old (from the 1970s), and now generally being replaced by XML lead by Adobe.
http://graphicssoft.about.com/od/glossary/f/metadata.htmThe thing to understand about this kind of meta data is there are two parts to it. There is the data that the file format itself is specified to be able to handle, the "standard", the agreed upon set of information that anyone and any supporting program will be *able* to read/write in a given format. File formats are not always well documented or specified, or even particularly compatible between programs - consider .OBJ for a good example. But in the best cases, for something broadly standardized like JPG for example, there is an organizing body of some kind that defines what data the file format can store.
The *other* part to file-level meta data though is the *program support*. Meta data in any given file format is generally defined in such a way that it is *optional* to support it. You could have a JPG reader that does not have any support for viewing - much less editing - of meta data. It could be totally unaware of Exif, IPTC, and the rest, yet still be able to load the core JPG image data and display the image. Similarly with Exif to IPTC to XML, there are imaging programs that *only* support Exif, ones that support both Exif and IPTC or Exif and XML, etc.
So to get meta data into a file, you need a file format that supports it, and a program that supports editing that data. Storing meta data in a file is generally best because then that data is entirely portable, i.e. it is not tied to a particular operating or file system, and if you send the file to someone else, the data remains intact. If either piece is missing - support for meta data in the file format, or support in your application for that meta data - then you can resort to operating system meta data, but remember that it is not portable and is likely to be more general (i.e. lacking fields specific to a given format's capabilities, like geometry count for an OBJ for example) as well as more limited (fewer fields).
Regarding saving of info like what programs a file has gone through, this is unlikely and not something I'm aware of being broadly available or supported, although some formats - e.g. Microsoft Word - do have some history/revision data, etc. in them. The key think to understand there is that it's not *just* the file format that needs to support such data, but the programs themselves need to *modify* the data. In other words let's say you have a file format that does have a meta data field for recording revisions and the programs that made them, and you have 3 programs that support loading, modifying, and saving that format. As I said before, a program can support reading of the basic format without supporting the meta data, or it can support some but not all the meta data possible in that file. So let's say Program 1 can load the file and it writes in the meta data "File X modified by Program 1 on XXXX date". Ok, great. But Program 2 doesn't support any meta data at all. You load the file and make changes, then save it, but it has no idea about meta data. Program 3 does support some of the meta data, but it's a bit older and doesn't support that specific meta data field! This is a real possibility, though if a file specification is designed correctly and the program is designed correctly, it should not be likely to happen. But these are just some of the complications you need to be aware of.
The bottom line is that meta data is very useful, but between the issues of portability and program support, it often cannot be relied upon outside of your own computer, unfortunately. Meta data support is currently best in image formats for various reasons, Exif, IPTC, and XML meta data are powerful and broadly supported now. I imagine 3D formats like FBX, Alembic, and Collada have their own meta data that is hopefully increasingly supported.
I could give specific recommendations of software that supports meta data read/modify/write, but it would be largely confined to the image processing domain. The key take-away though is that file-specific meta data relies on support in specific applications, it is not as likely to be supported by your operating system. This doesn't sound so bad if you can find programs that support the meta data you want to read/write, except remember too that a "chain of meta data" is only as strong as its weakest link. If you're lucky a load/save in a program that doesn't support the meta data will just result in unmodified meta data. In the worst case however the data will be entirely stripped/lost.
It's a complicated problem.
- Oshyan
