Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rick.ca]

All of my photos are in JPEG format. I've been using ACDSee to organize them, and will probably continue to do so. It seems I'm not going to be able to use any tags created by ACDSee in MC. ACDSee will "batch set" it's data to images, but only to EXIF. It seems MC looks only to IPTC for the equivalent information (e.g., keywords).

This is disappointing, but at least I can display may collection based on my reasonably organized file structure, and, of course, the date the photos were shot. Well, it seems not. For reasons I can't begin to fathom, the program puts a bunch of EXIF tags in a pseudo-tag called "format." Among them is the data/time shot, it's not available as a tag that can be included in a layout. Rather than simply recognizing these files are photos and setting the date field with the date shot, the import routine uses the irrelevant date modified, which already has it's own field! To add insult to injury, it also sets "album" to date modified. Is that by design, a sinister plot to annoy me, or a bug?

...I stopped ranting long enough to figure out not all of my images are behaving this way. It seems to be only those for which I've written GPS data to EXIF. The GPS date/time is exactly the same as the date/time shot—that's how it's matched to the image. But it's existence must somehow throw the program off the date/time shot and cause it to select the date modified instead.

I hope someone can explain how I can fix this. Assuming theatre mode will only display "date," the preferable solution would be to change "date" to to the EXIF date/time shot, rather that just finding a way to display this in a view scheme. And, BTW, "album" is still set to "date," regardless of how "date" has been set. I can just delete it, but it would be nice to know why this is happening.

I'm not hopeful, but I would be very happy if someone could tell me how to get ACDSee categories and/or keywords into MC. It looks like the best ACDSee can do is write these into EXIF "image description" or "user comment" tags. Maybe these can be accessed by MC expression language, even though they're not normally used in MC?

[JimH]

MC reads EXIF tags.  You could probably find JimN's description by searching here.

[rick.ca]

You could probably find JimN's description by searching here.

I've reviewed all hits on JimN+exif. I read most of them before, and I'm still not sure if I've seen what you're referring to. What I have learned is it's much more complicated than implied (to me, anyway) by the statement, "MC reads EXIF tags." Yes, it reads some information and puts some elements of it into its database, but that doesn't mean all of the information is available for user manipulation, or even viewing. So, for example, when the date has not been set to the EXIF date, I assume I can fix it with the expression tag(exif: Date). But (it seems) that expression does not read EXIF—it only returns the value originally read from EXIF and saved in the database. So if MC got the date from elsewhere, the EXIF date is not available to the tag function.

I can see how my specific problem may be unique, caused somehow by data written to EXIF by RoboGEO. Maybe another RoboGEO user can shed some light on that. In the meantime, is my understanding about the availability of EXIF data correct? Do I have to let go of the idea of importing EXIF data not otherwise used by MC?

At my level of understanding, maybe I shouldn't be offering suggestions, but... Clearly, I'm not the only one confused by this. That may suggest a design issue, but I suspect it's just inherently complicated. If that's the case, the fact the program obscures where meta data came from and where it's currently stored just adds to the confusion. I understand the interface—because it handles all kinds of media—probably needs to stay as it is. But maybe a supplementary tag view for images could be added that shows clearly what information is currently stored and where—in the database and the various file tags. With that as a starting point for a tagging interface, update options could be set (e.g., which file tag to get a data element from) and utility functions (e.g., copy this tag to that tag) added. Having all this laid out in front of me would help immensely in my appreciation the various issues involved (e.g., how information maintained in MC might be made available to other programs, and vice versa).

[JimH]

There are no universally accepted standards for tagging. 

JRiver had tag support in photos before some of the "standards" even existed.  Our wiki has more information:
http://wiki.jrmediacenter.com/index.php/Photo_Tagging

[Matt]

I assume I can fix it with the expression tag(exif: Date). But (it seems) that expression does not read EXIF—it only returns the value originally read from EXIF

That expression will read from the physical file tag, not the database.

I can see how my specific problem may be unique, caused somehow by data written to EXIF by RoboGEO. Maybe another RoboGEO user can shed some light on that. In the meantime, is my understanding about the availability of EXIF data correct? Do I have to let go of the idea of importing EXIF data not otherwise used by MC?

If there are specific fields you would like supported, please give us a list of fields and email a sample file to matt at jriver dot com.

At my level of understanding, maybe I shouldn't be offering suggestions, but... Clearly, I'm not the only one confused by this. That may suggest a design issue, but I suspect it's just inherently complicated. If that's the case, the fact the program obscures where meta data came from and where it's currently stored just adds to the confusion. I understand the interface—because it handles all kinds of media—probably needs to stay as it is. But maybe a supplementary tag view for images could be added that shows clearly what information is currently stored and where—in the database and the various file tags. With that as a starting point for a tagging interface, update options could be set (e.g., which file tag to get a data element from) and utility functions (e.g., copy this tag to that tag) added. Having all this laid out in front of me would help immensely in my appreciation the various issues involved (e.g., how information maintained in MC might be made available to other programs, and vice versa).

Image tagging is messy, because there's no one good standard.  MC supports EXIF, IPTC, XMP, and MJMD.  It's a good list.

You might look at Action Window > Tag > Details format information to see a full tag dump for a file.

[rick.ca]

Our wiki has more information

Thanks. That, of course, just makes me more eager to get my existing information into MC so I can tag there. 

That expression will read from the physical file tag, not the database.

That's not what I got from some of posts I read—but if that's true, it narrows my problem. When I use that expression on a geo-tagged image, it returns nothing. If it really is trying to read the file, then perhaps the problem is the geo-tagging has changed the structure of the EXIF block so MC (specifically, the tag function) can no longer find the date (the original date/time data is still there). Hmmm. This is not looking good. 

If there are specific fields you would like supported, please give us a list of fields and email a sample file to matt at jriver dot com.

Thanks. So as to not waste your time, I'll do more research to see if I can figure out exactly how ACDSee is writing the information I'm interested in.

You might look at Action Window > Tag > Details format information to see a full tag dump for a file.

I've been doing that, but it's an alphabetic list of MC tags that doesn't explicitly show what information resides in the EXIF and IPTC blocks of the image. ACDSee, for example, does this by showing the data on three separate tabs.

[Matt]

That's not what I got from some of posts I read—but if that's true, it narrows my problem.

I promise.  That's why we added the expression -- to provide direct access to file tags.

I've been doing that, but it's an alphabetic list of MC tags that doesn't explicitly show what information resides in the EXIF and IPTC blocks of the image. ACDSee, for example, does this by showing the data on three separate tabs.

Click the "Format" item (or the top line of the Tag window).  It shows a full tag dump, not tied to the database.

[rick.ca]

Click the "Format" item (or the top line of the Tag window).  It shows a full tag dump, not tied to the database.

Thanks. I saw that, but didn't appreciate what I was looking at. 

It seems I'm not going to be able to use any tags created by ACDSee in MC.

Thanks to my magical powers of obsession, I've resolved this. While I cannot recommend this to the sane, similarly-afflicted users may want to know how:

• In ACDSee, batch set filename to an otherwise unused field. Append categories and keywords to filename.
• In MC, delete and re-add the files. If necessary, update name with "=filename()".
• In MC, use quick search to filter each unique category/keyword, and tag as appropriate using Pane Tagging.
• In ACDSee, rename the files back to the original name.
• In MC, delete and re-add the files. If necessary, update name with "=filename()".

At first, I found it nerve-wracking to delete files and hope that they could be re-added without loss of tagging information. After a few times, however, I began to appreciate how remarkably robust MC is in keeping track of files whose name has changed or have been moved. At first, this was frustrating (if not terrifying) because it seemed MC was refusing to forget about the old files, and start fresh with the new. Now I'm not sure if that is because I was not immediately refreshing the information with update library (with tags), and perhaps slow to discover =filename(). So a question lingers... Is there a way to remove all information in the database for deleted files, so it can "start fresh" when the same files are re-added?

If there are specific fields you would like supported...

The best I can do with ACDSee is write its category and keyword data to the EXIF User Comment field. I believe the proper name is Exif.Photo.UserComment (tag #37510). It would be wonderful if I could access this from MC. I would probably still have to redo the tagging manually, but it would still be a huge time-saver.

It would also be nice if MC's places and people could be written to tags (perhaps IPTC sublocation and object name) so they would be accessible by other software. I do understand, however, writing data to tags is a much more complicated matter—conflicts with existing data, etc.

When I use {=tag(exif: Date)} on a geo-tagged image, it returns nothing...

I never did figure out what the problem was with images tagged with RoboGEO. Most dates seemed to be fixed by my re-tagging process, but for a few hundred of them I just had to enter the correct (i.e., shooting date) manually. I had no such problem with images not yet geo-tagged, and geo-tagging those images after they were in MC didn't seem to introduce any problems. One remaining question... I notice latitude and longitude appear in the (detailed format section of the) tag pane as degrees without decimals or minutes/seconds. I presume this is just for the sake of brevity in the display, and not an indication MC is unable to read the information correctly?


Thanks very much for your help. I'm very impressed with MC's tagging system. It's at least on par with that of ACDSee—a program largely based the need for photo organization. I need to stick with ACDSee for it's editing and photo-specific organizing features, so I hope there will be more efficient ways for me to integrate the two.

[raldo]

Hey rick.ca!

I have a question for you! How do you deal with people, places events?

MC reorders the entries in these tags alphabetically when you add/change these fields. This is not what i would like because the ordering can be used to indicate "who is ho" in the people tag. Would you say that the MJMD tag is forwards compatible with other tag types? (Just in case I start using another application in the future )

I have thousands of pictures in my collection and I'd rather not do a lot og work and find later that my work was pointless.

I have brought up this issue in a couple of threads a while ago.

Thanks.

[rick.ca]

Hi raldo,

Well, you're probably a much wiser person than me. I prefer to do a lot of hard work, and then consider whether it was pointless or not later. 

So far, I'm using places, people and keywords. I've created a few "albums" and "events," but with the others done, there's not much need for them (e.g., date and place uniquely identify most events).

Considering the nature of tagging (i.e., the user's process of setting, resetting and rearranging the tags), it's better that the program keeps them alphabetic. I use nesting rather than ordering to keep them organized (e.g., Relative\family\person, Friend\person, etc). Nesting not only makes tags more organized and easier to find, but allows tagging at an appropriate "level." For example, my cat is tagged with the keyword Animal\cat\tiger.ca, a street cat is Animal\cat, and any dog (because I'm a cat-person) is just Animal. The point is the selection of any tag will include all lower level tags, which is a lot easier than picking multiple items from (even a carefully ordered) list.

If I understand correctly, places, people and events are just MC fields. Despite the term "tags," they are not saved as EXIF or IPTC tags in the images themselves. They are therefore unavailable to other software. Keywords, on the other hand, are saved as IPTC keywords. They stand a chance of being available to other software that can read the same IPTC tag. Others here have warned these standards are not particularly standard, so compatibility is not a sure thing.

Your question makes me think of something that didn't occur to me before. There doesn't seem to be any reason why places, people and events cannot all be saved as keywords (imagine them all being top-level classifications in a system of nested tags). It would be a little less convenient in use, but you could still open any number of panes for keywords and use a separate one for each of places, people and events. Or, just create however many keyword panes you want and use each one for whatever seems convenient at the time. On the downside, all of the keywords would be crammed into one field, making detail views less informative. You would also lose the ability to refer to them separately using expressions. But if compatibility with other software a more important issue, this would be worth considering.

I suppose another possibility is to use some other MC tag for whatever you would otherwise use keywords for. Then use an expression to consolidate all the MC tags to the keywords tag, which the program will then write to the file as an IPTC tag. Just don't ask me how—I haven't got that far yet!

[darichman]

Writing EXIF data has been an oft requested feature. While some argue that these tags shouldn't need to be changed, there are a few reasons, like incorrect camera dates or GPS data. I have also noticed that if I use another program to edit the EXIF date field and get MC to "update library from tags" it ignores the new EXIF data and uses the MJMD field instead. Even if I clear it...

I prefer to do a lot of hard work, and then consider whether it was pointless or not later. 

Here here!

And you raise some interesting points. I came precariously close to combining my major photo fields into the keyword field... Although you gain the benefit of compatibility with other software, at the same time you raise a lot of issues when you try to access the field for expressions/filtering purposes At the moment, there is no way for MC to get the info from a single level of a nested field...

Referring to a particular level in a nested field
   - It would be good to be able to refer to a particular level in a nested field for use in expressions and rename functions.
   - For example, how can I output [Level B] in an expression? Maybe something like =[Field]!2 or similar to refer to the second level

Regarding the alphabetising of fields (like People)... I guess the idea here is that MC uses the field primarily as a filter (eg How can I find photos with "bob" in them) rather than for display purposes (eg Who is in this photo). It would certainly be nice to be able to tag faces in photos ala *facebook* to keep track of which person is which.

I suppose another possibility is to use some other MC tag for whatever you would otherwise use keywords for. Then use an expression to consolidate all the MC tags to the keywords tag, which the program will then write to the file as an IPTC tag. Just don't ask me how—I haven't got that far yet!

Exporting to xml is an option here, but there are much more learned than I on the board here...

[rick.ca]

Writing EXIF data has been an oft requested feature. While some argue that these tags shouldn't need to be changed, there are a few reasons, like incorrect camera dates or GPS data.

That's a good point. I don't think I would ever want to change any of the technical data coming directly from the camera or GPS. This generally is the purpose of EXIF, while IPTC is for the subject classification information I'm interested in. However, ACDSee only writes to EXIF, which provides only a few tags that are suitable. Fortunately, one of those is a comment field that (I suppose) can take whatever is thrown into it. Also, the fact it's a "user comment" tag suggests it's use will not conflict with the usual EXIF technical data. Nor should it conflict with similar information from other sources—because that's likely written to IPTC (as MC does).

At the moment, there is no way for MC to get the info from a single level of a nested field...

Thanks for confirming my suspicion. But if the keyword field is used only for the purpose of combining the information from other fields, and some other field (comment, description, or custom) is used for keywords, would there be any adverse consequences? I'm assuming there's nothing unique about the keywords field, that nested tags can be used in other fields as well. On the other hand, I might be unaware of other considerations. Perhaps keywords are treated in a particular way in other areas of the program (theatre view, for example) because it is expected certain data will be stored there.

It would certainly be nice to be able to tag faces in photos ala *facebook* to keep track of which person is which.

Dare I admit it... I'm over 30, and don't use Facebook!    Is it literally a tagging of faces in an image? That would be cool!

(I pity the person who has to maintain the MC wish list.  )