Print

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

[lawman74]

It appears that JRiver MC does  NOT  insert XMP-compliant data into JPG / JPEG files.

After using industry-leading tools to try to get at the data that MC does insert, and having no success, I contacted one of the leading experts in the world on metadata in photo files. I sent him a file in which I had inserted, using MC, "Santa" in the People field and "Jamaica" in the Places field. I had done nothing else to the file. Windows 8 Properties showed that the file increased in size from 83,337 KB to 85,911 KB (though the reported "size on disk" stayed the same at 86,016 KB, which is correct in those circumstances). MC showed the following in its JPG properties pane:

XMP Tags:

MJMD Tag: v1.0
   <MJMD>
   <Tool_Name>Media Center</Tool_Name>
   <Tool_Version>19.0.67</Tool_Version>
   <People>Santa</People>
   <Places>Jamaica</Places>
   <Date>41518.8418865740750334</Date>
   <Album>2013-09-01</Album>
   <Name>Glass home at night</Name>
   </MJMD>

Here is what the expert said about the metadata that MC inserted into the JPG file:

"The MJMD information you describe is stored in a proprietary "Media Jukebox" APP9 JPEG segment.  It is not XMP.  Not only is it not stored in the XMP APP1 JPEG segment, but it isn't even RDF/XML like XMP.  I have never seen this "Media Jukebox" segment before."

It seems clear that JRiver needs to do one of three things:
- stop storing this metadata in a proprietary format and instead put it into the appropriate fields in the IPTC Extension metadata (part of the XMP metadata; see link below); or
- correct the erroneous storage of this metadata so that it is stored in compliance with the requirements of a custom field in XMP; or
- stop claiming that it is XMP data, and correct all documentation accordingly.

http://www.iptc.org/std/photometadata/documentation/GenericGuidelines/index.htm#!Documents/iptcextension.htm

Because the IPTC Extension largely complies with the recommendations of the Metadata Working Group (see the link below), and there is no other standard that appears competitive with it, it seems clear that the first option is by far the best. The IPTC Extension was standardized in 2010 (see the link below) and provides appropriate fields for the People and Places data. For People, the Person Shown should be populated (despite the field name, multiple names can be entered). For Places, the Location Shown should be populated (it appears to allow multiple values, whereas the Location Taken appears to allow only one value).

http://www.metadataworkinggroup.com/

Granted, the destination fields proposed above may, in some cases, not be the right ones from a user's perspective, but for probably the great majority of cases they are workable, and fully automating the move seems worth the potential (and limited) problems.

Users should probably be given the alternative (or the additional option) of moving the People and Places metadata to the Keywords field in the IPTC Core metadata, where the search facility of at least most software can find it.

[JimH]

Our CTO is out for a while, so you will need to be patient.
http://yabb.jriver.com/interact/index.php?topic=86462.0

You might find something useful on the wiki.
http://wiki.jriver.com/index.php/Photo_Tagging

[cncb]

I told you before that the MC fields are not stored as XMP data so you didn't have to go to an "expert" for that information.  Once again, Keywords are written as appropriate XMP and IPTC data so you should be using Keywords if you want to share data with other programs.

Look at the Wiki link Jim posted above.  It shows a way to convert the MC Tags to nested Keywords using an expression.

[lawman74]

Thank you for the response.

I have tried to make it clear that I am new to this topic. Of course, almost none of the problems are attributable to JRiver (and what is seems to result from a lack of documentation), but I think it's time for JRiver to move its People and Places metadata into the XMP data, and preferably into the most appropriate IPTC standard fields. Otherwise, outside of MC, it is of virtually no value since it seems that little or no other software knows about it.

I repeat that I do appreciate JRiver Media Center, their forums and the responsiveness of their supporters in those forums -- all are "top-of-the-heap".

[lawman74]

I told you before that the MC fields are not stored as XMP data so you didn't have to go to an "expert" for that information.  Once again, Keywords are written as appropriate XMP and IPTC data so you should be using Keywords if you want to share data with other programs.

Look at the Wiki link Jim posted above.  It shows a way to convert the MC Tags to nested Keywords using an expression.

@cncb, you are absolutely correct -- on Jan 5/14 at 10:02 you wrote: "Note that the MC tags are stored in the image file itself but in a special MC section, not XMP."

Unfortunately, I lost that explanation in my mind, perhaps amidst something else you wrote and my interpretation of the display that MC gives of its tags, as follows:

-- cncb (Jan 5/14 08:00): I still don't understand.  What standard is MC not following?
---- [This was written to another user, but I took it to mean that the tags that MC writes are all written according to a standard, which I took to be Exif, IPTC and/or XMP. My misinterpretation, not your fault. However, I still don't know if the MJMD tags are written according to a standard, but it doesn't matter in the sense that it is not Exif, IPTC or XMP and thus is not likely to be recognized by software other than MC.]

-- cncb (Jan 7/14): Like I said you have to click on the link at the very top of the Tag window to open another window with the detailed file tag information.  You will see XMP details and "MJMD Tag: <none>" if you haven't written any MC tags to the file.
---- [Carrying out your instructions on one of my MC-tagged JPG files gives, in part, the following (exactly copied from the JPG pane, including blank lines):

XMP Tags:


MJMD Tag: v1.0
   <MJMD>
   <Tool_Name>Media Center</Tool_Name>
   <Tool_Version>19.0.67</Tool_Version>
   <People>Santa</People>
   <Places>Jamaica</Places>
   <Date>41518.8418865740750334</Date>
   <Album>2013-09-01</Album>
   <Name>Glass home at night</Name>
   </MJMD>

To me, this presentation suggests that the “MJMD Tag:v1.0” is part of the “XMP Tags:”, partly because of the colon after “XMP Tags” with no intervening data, and partly because there is no clear indicator that there is, in fact, no XMP data. (I now think that the "extra" blank line is supposed to indicate no XMP data, but I also think it is pretty uninformative for most users.) While it is obvious that the line “MJMD Tag:v1.0” is not in XML tags, I just took it as a heading like “XMP Tags:” inserted for explanatory purposes. I think it is a case of a presentation that lacks a bit of crucial information, such as the JPEG APP1 and APP9 segment identifiers. I go back to an earlier comment I made about the need for JRiver to provide full documentation of the format and placement of their tags in a JPEG file.]

I apologize for my forgetfulness and misinterpretation. I appreciate your responses.

Regarding converting the MC Tags to nested Keywords using an expression, I will certainly look at that, but as I said in another post, I regard it as only an interim measure. Better than nothing, though!

Thank you.

[suse]

+1

I never realized how great MC is for photos, I had just used it (and LOVED IT) for music for 10 or more years it seems... 

I create a photo album for the previous year for my husband for Valentine's Day and each year I struggle with trying to find all of the images that were taken in that specific year and OMG!  I'd had it all the time in MC.  I've spent many hours in the past few months trying to figure out how to get Picasa or WE or anything to do this and MC does it automatically!  Amazing!  I had finally found a way to search WE using datetaken:lastyear but it took about 8 hours to find all the images and then there was no way to add a "tag" to all 2000+ images.  Unbelievable microsoft.

So for now, until MC does this automatically (which is a feature I would upgrade for), I clicked to view all 2013 photos and then added the keyword 2013 to all of them.  Now I should be able to find them all in Picasa, which, as far as I can tell SUCKS at finding all the images for a particular year.

I'm glad someone is talking about this tagging issue, I'm amazed that it is not more standardized, like audio tags...

I also loved the conversation about facial recognition, as I too, don't trust Picasa with that information.

[Castius]

Glad to hear JMC is working for photos.
In picasa you can use the timeline view.http://www.addictivetips.com/windows-tips/12-features-of-picasa-that-you-probably-dont-know-about/

[MusicHawk]

Reviving this thread (I participated in years-ago discussions about this), probably JRiver needs a business reason to dive back into its Photo management capabilities. The time is right.

The business opportunity is that there's no other satisfactory tool, yet there are millions of people with digital photos to manage. The opportunity seems much larger than MC's focus on managing audio and video. Many of my friends are happy to use iTunes or Pandora or whatever for music, a DVR or Netflix and the like for video, not needing their own libraries.

But no such outside product or service can ever provide the personal photos we all treasure to document our lives. We create our own photo museum, then realize we must manage it. How?

Web-based photo management is simply horrible. PC-based management is way better than clumsy tablet or phone methods. Only a PC provides the screen, keyboard and storage needed for ever-ballooning photo collections. Check the packaging of USB hard drives and backing up photos is a major feature. It's a huge market.

If MC got just a few tweaks to line up with what photo tag formats exist (official and/or widespread), it would fill a massive niche. I could probably get dozens of relatives to buy MC just for this, and then they'd likely discover the amazing audio and video capabilities, tell their friends, repeat...

I don't think the Big Guys are going to get their act together anytime soon, and probably never.

Microsoft has no strategic reason to invest in photo management.

Google makes money from eyeballs on its Web pages, so why care about Picasa, which is bizarrely broken. Google tried to use it to increase Web visits by coupling with Google+, but every relative and friend has begged me to stop sending them emails, which of course is Picasa running amok. (My solution is to tag with second dummy user names that have no email addresses.) Now rumors are rampant that Google is backing off on Google+, which might make Picasa even more of an orphan. And clearly Google puts no effort into improving Picasa, witness the bugs that prevent Web syncing if, somewhere in thousands of photos, Google+ finds a single photo with a duplicate face tag. It doesn't say which photo or which tag, it just fails. And I have photos with no face tags at all that fail to sync. And the bug that causes syncing errors if Google's automatic Auto-Awesome photo-manipulation is active, or if Google+ is allowed to create photo montages. It's a massive train wreck.

Yahoo Flickr now provides 1TB of "free" photo storage, but there are no reasonable tools to work with it. One of the few that does anything was abandoned by its Italian student creator, who says he can't recall the code and has no time now that he must make a living. Flickr will easily break the upload connection due to rumored max batch limitations. And its frustrating face and other tagging is just sad to see.

Adobe still can't provide logical-to-use software, and instead is migrating its tools to the Web as if that is the solution users want (or can use). It's hard to see a business case for Adobe improving its Elements products, given the really big bucks it makes from professional tools that are now moved online.

MC seems to have an open opportunity to provide actual useful photo management and tagging software. And maybe it can also become the front-end to Google and/or Yahoo. They both provide APIs, so perhaps MC could connect to them for storage. What a package that would make!

Still hoping JR will take this on!

[JimH]

If MC got just a few tweaks to line up with what photo tag formats exist (official and/or widespread), it would fill a massive niche. I could probably get dozens of relatives to buy MC just for this, and then they'd likely discover the amazing audio and video capabilities, tell their friends, repeat...

Thanks for the details.  Could you identify 2 or 3 things you think are lacking?

[darichman]

MusicHawk, I read through your post with interest. I've stopped using Picasa for pretty much all the reasons you mentioned. It is broken. I still use MC regularly for the basic sorting and organising of my photos, and would love to use it for everything and ditch Picasa altogether, but it lacks a few functionality components that I loved about Picasa.

Jim, if I had to pick 2 or 3 things... and I'll list them as a user without much knowledge of the technical side, cost or resources needed to implement them:

1. Face recognition / tagging (play around with how picasa does this... it's fun to use and saves hours of manual tagging)

2. Geotagging / some sort of interface with google maps or earth (two things: Picasa lets you drag a pin onto a map to tag the geolocation data, and it lets you select a whole bunch of photos to see where they are on a map - this is amazing for holidays and road trips, and there is no other program out there, that I know of, that does this)

...and a small but important bug preventing the easy use of home videos from a camera

[MusicHawk]

Jim, the needed evolution of MC to manage photos has been covered pretty well in this thread.

My two added points are: It's a big, timely opportunity as the other guys pursue conflicting agendas. And, JR has been clever to tap/integrate/support/leverage other technologies and products (hacking iPods was wonderful), so do the same with photos.

Put as 3 (or so) things:

1. TAGS -- Store tags in whatever is today's most common format(s), which have evolved since MC added photo support. Primarily, do what is recommended by the Metadata Working Group, AND try to be compatible with Picasa/Google+, Flickr/Yahoo, Adobe Essentials, possibly Instagram, Apple iPad photos, and Microsoft's various products (including Windows Explorer) that can write and read tags. None of these are exactly the same, but there is common ground. Over my many years of using MC (started with MJ 6 or 7) for audio files, I believe JR worked out ways to support the various tags that became important, sometimes putting the same data in multiple tags for cross-compatibility. Just do the same for photo files.

2. ONLINE -- Online is the major way photos are shared these days. So, MC should provide users with online storage and display by connecting/syncing with online photo sites that have APIs. (I know, MC has long-provided its own online photo system, but supporting one or more major systems is a key to widespread acceptance.) Flickr might be first because it provides 1TB of free online storage, and it already supports (and lists/promotes) various half-baked upload/sync tools. Yahoo should be desperate to have a quality desktop product support its otherwise decent online photo system -- there might even be a business-relationship opportunity. The combo of MC+Flickr would be far superior to Picasa+Google+ yet JR would not have to provide the online part. If possible, also connect with Google+, Facebook/Instagram and other online photo-oriented sites.

3a. FACES -- Face recognition is cool and saves lots of time. Picasa's works well, Microsoft and Adobe fairly well. Instead of JR inventing its own way to do this, advise users who want to automate people tagging to use Picasa/Microsoft/Adobe. Then, read that data into MC. Picasa, for instance, can be set to write face tags into separate files. They have an obvious format, so MC could read them into the database. Store all the data, and use whatever part matches MC's capabilities: Put the Name tags into MC's People field. Picasa (and Facebook and Flickr) can also show name tags on faces in a photo based on coordinates, but probably this doesn't need support in MC. My friends/family view photos via a screensaver or slideshow or online or on a tablet, where they want to see caption/tags/people/place/date/etc (configurable), but they don't seem to need labeled boxes on faces.

3b. (OK, #4) PLACES -- Besides a field listing one or more locations applicable to a photo, store geo data. Even if MC does not integrate with a map as Google does, newer cameras have GPS and put location data into photos tags; there seems to be a standard for this. This geo data should be preserved in MC database. Probably stash it and ignore it for now, but someday maybe MC could for each photo generate a link to invoke Google Maps via a URL with lat-long that pops up a location map (same idea as the links that can locate a song online). It might be fairly simple to provide.

Also essential: MC must write the tags back into the photo files, just as it does with audio files that support tags. Use any/all fields/XML that are necessary for cross-compatibility. (Avoid sidecar files if possible.) This makes the photos reasonably self-contained and portable.

It's a (small?) new project to determine the tags and formats used by today's major photo apps/sites, then decide which to support in MC, but some of that investigation has already been done in this very thread. The rest of the work seems very much like what MC has already done for music and video, so possibly similar code. The devil is always in the details, but MC did much of the heavy lifting long ago. Displaying photos, tagging photos, providing fields to organize and view photos, etc, were not trivial capabilities to build, but they are already in place -- making MC "so close" to being the photo management system of choice.

[darichman]

3a. FACES -- Face recognition is cool and saves lots of time. Picasa's works well, Microsoft and Adobe fairly well. Instead of JR inventing its own way to do this, advise users who want to automate people tagging to use Picasa/Microsoft/Adobe. Then, read that data into MC. Picasa, for instance, can be set to write face tags into separate files. They have an obvious format, so MC could read them into the database. Store all the data, and use whatever part matches MC's capabilities: Put the Name tags into MC's People field. Picasa (and Facebook and Flickr) can also show name tags on faces in a photo based on coordinates, but probably this doesn't need support in MC. My friends/family view photos via a screensaver or slideshow or online or on a tablet, where they want to see caption/tags/people/place/date/etc (configurable), but they don't seem to need labeled boxes on faces.  

AdamT worked to implement this a while ago (edit: woops, I linked to a beta thread, so have quoted below). MC reads the names from Picasa's face tags (stored in the file) and puts it in MC's 'People' field. Just click 'update library from tags'. It works really well provided you have tagged the photos in Picasa first, without using MC to modify the tags. Once MC has touched the tags, it won't pull face data into the names any more (once MC has created it's people tag, there is no way to force it to read Picasa's face data anymore). It's only a small step to get this working properly... Instead of using 'update library from file', maybe have an option to force 'update people from Picasa face tag'?

Another photo update thread for me

I'm noticing MC does not update people field to reflect changes to people made in Picasa. If MC has people tagged in its database for a photo, and I add or change the name of the people tags in Picasa, MC will not pick up these changes on auto-import or on update library from tags.

It will, however, pick up new people tags from Picasa if the people field is empty in MC.

Unfortunately this, along with the dates issues, is another showstopper for using MC for photos in my permanent workflow - I really want to!

3b. (OK, #4) PLACES -- Besides a field listing one or more locations applicable to a photo, store geo data. Even if MC does not integrate with a map as Google does, newer cameras have GPS and put location data into photos tags; there seems to be a standard for this. This geo data should be preserved in MC database. Probably stash it and ignore it for now, but someday maybe MC could for each photo generate a link to invoke Google Maps via a URL with lat-long that pops up a location map (same idea as the links that can locate a song online). It might be fairly simple to provide.  

MC already stores the geodata! Check latitude, longitude etc The next step is being able to a) generate geodata for photos taken without a geotagging camera b) display the information in a useful way.

I agree that working on tagging standards is important... when friends use my photos in lightroom etc, some of the tags go across and a lot don't (keywords will, people won't, for example). I think this could be really difficult though, as MC stores a lot more information than most of the common tagging standards permit?

[adamt]

...and a small but important bug preventing the easy use of home videos from a camera

I tried importing videos with a couple different formats.  It seems MC uses the "Date Modified" tag as the "Date".  In my test, this corresponded perfectly with the date the video was shot. Does your case look different? 

[MrC]

It seems MC uses the "Date Modified" tag as the "Date".  In my test, this corresponded perfectly with the date the video was shot.

Date Modified will be incorrect when files have been copied to other storage locations.  MC shouldn't be relying on Date Modified over the internal tag values.

[adamt]

Hmmm...
I didn't realize "Date Modified" would change when copied.  I've tried copying it around and the "Date Created" seems to change.  The "Date Modified" tag seems to be the only tag that stays the same.  If "Date Modified" changes as well, which tag should MC rely on?  I could very well be missing something.

[glynor]

Adam, you're talking about filesystem metadata (Date Modified, Created, etc).  MrC is talking about the internal Date tags (IPTC/XMP metadata inside the files themselves).

There is a "Date Recorded" field of some kind (I don't know the spec and am too lazy to look it up right now) that is used for this purpose by basically every other photo management application out there.  It is the "Date Shot" and it never changes, even if the photo is copied to different kinds of filesystems and whatnot.

[raldo]

[...]
Google makes money from eyeballs on its Web pages, so why care about Picasa, which is bizarrely broken.
[...]
clearly Google puts no effort into improving Picasa, witness the bugs that prevent Web syncing if, somewhere in thousands of photos, Google+ finds a single photo with a duplicate face tag. It doesn't say which photo or which tag, it just fails.
[...]

There was a recent upgrade of Picasa which shows that there is some effort being put into the application.

I can't speak for the web syncing stuff because I don't use that.

I've been using Picasa for a long time as a standalone Face detector/recognizer and geotagger. Very few problems. I've even diffed xmp/iptc data before and after Picasa mods to see if Picasa screws up data.

I use Geosetter to look up country, state, city based on latitude/longitude.

AdamT's changes where MC imports Picasa's facetags really made a difference for my workflow! Now, changes made from within Picasa are automatically picked up by MC. Great job!

I think MC currently works quite well as a Photo organizer and I think there has to be separate tools for detecting/recognizing faces (wlpg/Picasa/etc). Improve integration with these tools; stay away from detecting/recognizing faces , this task is difficult/expensive.

MC would benefit from fixing a few things. Here's my list in prioritized order:
- Improve file tag to MC tag mappings. I'd like to see 1-1 tags. An example is the country, state, city xmp/iptc tags which are joined in mc. Please split them!
- Put effort in streamlining how mc handles iptc/xmp. Bring up the level of control to that of IDv3 (etc), as suggested earlier in the thread.
- When cropping photos, update Picasa face tags.
- Lookup city state country when geotags change.
- Display face tags
- display geotags

[MusicHawk]

I can only spread rumors from many discussions about the troubles introduced by recent Picasa 3.9 updates (latest is 137.69 in December 2013), but there's lots of discussion about how it introduced some huge new problems. That's my experience, which is why I think Google either doesn't care about the desktop app, or wants to push users to its online photo system. Rumors say the update is mainly to benefit Google+. After six months of driving users crazy, there's no sign or even promise of fixing the new problems, per statements by Google insiders on their own forums.

This update broke lots of syncing because it forbids duplicate tags in photos (montage, or person and photo of person as happens in homes, or simply mistaken tagging), and apparently even overlapping tags (two faces very close together). Syncing simply fails, silently unless the user notices the sync symbol of an album changed, gets suspicious and digs in, with no help from Picasa -- once spotted, the error message is mysterious, it doesn't identify what photos need fixing, and rather than skip the problem photos it prevents the entire album from synching. Not a very helpful "update".

Also, Google+ implemented and set by default that photo enhancement would be active, and added Auto-Awesome photo processing, yet apparently this confuses and blocks some syncing too because it alters only the Google+ photos, not the Picasa photos. (I can't verify this since I have, I think, disabled all Google alteration of my photos, though it's a very clumsy procedure.)

Further, Picasa sharing control has a checkbox to email others who are in face-tagged photos. It used to actually control this, but a recent update now forces everyone to be emailed, all the time, ignoring the checkbox, driving everyone crazy. Google wants to pull everyone to Google+ so they simple force emailing in spite of the user's preference.

Then there's the infamous new error message "Please check that you are connected to the Internet", often reported when trying to upload or sync an album or folder. Huh? It's never an Internet connection problem, but that's what Picasa declares. My hunch is, too many files in the batch or perhaps the collection, but without an accurate error message, or even better, actual docs on what is allowed/forbidden, the user is left hanging.

Also, this update installs Google+ Auto Backup for the Desktop, which then sucks up bandwidth and Google Drive storage space, separate from Picasa's uploading. For the few users who pay attention, they can control this, but most people just click through. Besides, it is presented as a Picasa feature, though really it's a separate app. It seems to be Google's version of Microsoft's clumsy attempts to force Skydrive/Onedrive on Windows users, and/or to get users to pay for additional Drive storage. It would be straightforward for Google say that Google+ is the way to backup Picasa photos, but instead they are limited in size while Auto Backup is not. After considering the tradeoffs, seems like the user only needs one of these but both are packaged in Picasa. Goofy.

Etc, etc. I don't mean to start a debate, just supporting why I think MC has such a big opportunity as Google ratchets up the many ways it disappoints its users.

[akira54]

When we added image management many years ago, there was no standard for tagging.  Ours was one of the first.  We may need to revisit this.

Please do. Collections are growing ever larger and consequently proper tagging is increasingly important.

[MusicHawk]

More on connecting MC to Yahoo's Flickr, which provides 1TB of free photo storage with no restriction on image or file size, unlike Picasa/Google+.

Here's how perhaps JR can quickly learn how to extend MC to two-way sync with Flickr:
http://flickrsync.freehostia.com
http://flickrsync.codeplex.com

FlickrSync is the thought to be the best tool to sync local folders/files with Yahoo Flickr. But it is not quite sufficient. To sync many folders requires too many steps, some of the key sync and share properties are not supported or broken, and it is not integrated with photo management.

It's a really good start, but development was stopped years ago, and the latest developer now says he has no time or desire to get back into it. The good news, it is declared to be Freeware and Open-Source and source code is on Codeplex.

[Andyd]

Ok, time to resurrect this very old thread. I started this about a year and half ago and still never tagged my photos!!!
However in the mean time over the last 6 weeks I accomplished a large project I've been wanting to do for years. I scanned all of my photo negatives!
Now that the serious pain in the ass work is done it is definitely time to tag the new scans along with the thousands of digital photos.

I just reread this whole thread and still doesn't seem like anything great has happened...however since the last post was nearly a year ago perhaps there has been some progress?
I'm still running JR v18 I know its up to 20 now.... so has there been any good updates in the photo tagging realm?

Someone mentioned that Picasso was great for using the facial recognition and JR sees those tags good but then MusicHawk gave a whole story on why Picasso sucks...

[MusicHawk]

Alas, Picassa has not improved, in fact it has been unchanged for a very long time.

Flickr/Yahoo has not yet provided a decent image uploader, so using the offered massive storage is unreachable.

MC20 doesn't have any notable Image management improvements that I'm aware of.

So, last year's comments are this year's comments.

My ongoing frustration with MC boils down to priorities. The vast, vast majority of potential MC users have mountains of images ... everyone has a camera phone, so is snapping pictures like crazy but then has zero or poor tools to store and organize. In contrast, I don't know anyone who cares about doing things with TV that would require MC (I say this as a professional broadcaster). I'm sure some folks do, justifying MC 20 being almost entirely about TV/video. Go for it. But...

Letting MC's photo/images capabilities languish seems to be missing probably 99% of the Media Center opportunity. That's unfortunate. IMHO.

[JimH]

MusicHawk,
Start a thread on the MC20 board with a _few_ nice, crisp suggestions.  We'll see if we can help.

I use MC for photos a lot and I find it very good.  For whatever that's worth.

MC20 has a couple of touch screen features that I like.  Pinch to zoom and click to zoom.

It's slightly ironic that your recommendation above for an MC improvement is based on a freeware tool that is no longer being improved.

[Andyd]

Bummer
@MusicHawk... So assuming you do have all your photos tagged... what is your software of choice at the moment?

I would be happy enough at the moment if I could simply tag in JR using person/place/event/ panes as long as I could have them embedded in the files even if only as keywords... then at least all other programs would see them.
I don't understand why if I tag with keywords in JR it will save to the file but if I use the category panes it saves nothing...

[)p(]

Bummer
@MusicHawk... So assuming you do have all your photos tagged... what is your software of choice at the moment?

I would be happy enough at the moment if I could simply tag in JR using person/place/event/ panes as long as I could have them embedded in the files even if only as keywords... then at least all other programs would see them.
I don't understand why if I tag with keywords in JR it will save to the file but if I use the category panes it saves nothing...

I would suggest to  tag using a keywords hierarchy for person, place and events. The hierarchy is saved using / as the delimiter which is used by windows. So you will see them correctly in windows explorer or windows photo gallery. And although for example Lightroom uses the | as the delimiter it also has the option to use /.

[Andyd]

I would suggest to  tag using a keywords hierarchy for person, place and events. The hierarchy is saved using / as the delimiter which is used by windows. So you will see them correctly in windows explorer or windows photo gallery. And although for example Lightroom uses the | as the delimiter it also has the option to use /.

That's the problem. I must be missing something here...
I just a photo with a place and person.
The I right clicked the file >library tools>update tags from library.
Nothing changes on my file in windows explorer.

If I add a keyword it is changed in windows explorer instantly without me doing anything.

OR... am I suppose to be adding keywords like
places/home
people/Andy

If this is the only way then that is what I will have to do BUT... when done this way under the keywords pane I have my keywords along with the people/places/events hierarchy... all under one pane can get a little crowded.
Is there a way to make the people/places etc. appear in separate panes?

[)p(]

You should be able to construct views like that with expressions from the keywords hierarchy.

What I do is is just have 4 keywords panes and branch out in them with the triangle the ones I want to work on with pane tagging.
I also use the tag section in the left menu bar a lot for keywords tagging. Its offers really good predictions of what keywords you want to add when you start typing. I actually prefer tagging this way in mc over using Lightroom.

The only thing I really miss to ditch Lightroom completely is batch processing multiple files, presets for that and the support for photoshop plugins to use for things like noise reduction.