Print

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

[Listener]

I want a way to edit an image and make a Jpeg file that reflects my editing changes and contains the tag information I associated with the original image.

My wife and I take lots of pictures of wildflowers and wildlife.  I've used JRiver for managing audio files for over ten years and depend on the database features and the custom views. I want the same features for managing images. I've looked at a number of programs for image management (and lots of image editors that do some image management.)  I haven't found any other software at a reasonable price that has the features and user interface that I want.

One thing that I haven't figured out about using JRiver to edit photos.  Once I get a set of photos tagged, I'd like to use JRiver to edit the keepers and save the edited version with all the tags from the original in the edited version.  I may or may not keep the original long term but I always want to keep the cropped version with the tags (including Exif info) in the file.

I've tried using the "Save..." command. 

If I click on the "Save changes in Library only" radio button, the edited file is not saved as a Jpeg file.  Only the original Jpeg file is present.  If I try to view that file in another program, I don't see the effect of my editing changes.

If I click on the "Save changes to file" radio button and give the file a different name from the original, that Jpeg file will reflect my editing changes but it won't have the tags that I carefully added to the original image.

I've tried using the "Save&Exit" command.  The original Jpeg image file is still present and contains my tags but if I try to use that file in another program, it is just the original image file with no editing changes.  I have looked at using the "Send to" command to send the edited version to the web or to another program but that is just too limited and too cumbersome.

I want a way to edit an image and make a Jpeg file that reflects my editing changes and contains the tag information I associated with the original image.

I know that some people on this forum have experience using JRiver for image editing and management.  How do you get tags into edited files?

[MusicHawk]

MC is good (almost great) for image organization and management thanks to the database and tags. But MC's built-in image editor does a lot, but not quite how I want to work.

Instead, I use Google Picasa for Windows, a now-abandoned product. It is peculiar in many ways, a shame that Google stopped updating. But Picasa is excellent for common image editing -- straightening, cropping, and some degree of image enhancement (the "I'm Feeling Lucky" button often does amazing improvement). It's free. I don't know how/where it can still be downloaded, but it is worth looking for. I'm using Picasa 3.9.141, which I think is the last version before Google intentionally broke it. This version is from 2015 but works perfectly with Windows 10.

Here's the good part: The few tags in an image file that can be updated via Picasa are readable by MC. And the many tags used by MC are not affected by Picasa. It supports very few tags, mainly Caption and Date-Time, but if they are changed, MC sees the changes. In my experience all MC tags are preserved when the photo is edited and resaved (Ctrl+S) in Picasa. Note that if the photo is not explicitly saved in Picasa, any image changes will only be seen in Picasa, not in MC or anywhere else, because Picasa stores the changes for display but doesn't actually update the original image file. To do that requires Save/Ctrl+S (and/or, Picasa allows Save As and Save a Copy). Picasa does its display-only image changes by storing the original in a subfolder, which allows reverting the changes, but also potentially doubles up on disc space use, something to manage.

I run both, at the same time. I do all image/photo tagging in MC. But if an image needs tweaking (straighten, crop, color, contrast) I do that in Picasa. Then almost immediately MC shows me the improved photo. Or, if I revise the Caption in MC, I immediately see the changed caption in Picasa. They seem to happily live together, open at the same time, viewing and updating the same image files.

Caution: Apparently Google abandoned Picasa as a Windows app in their semi-blind belief that everything must be done on a Google Photos-enabled phone+Google Drive. Whatever that is good for, it is not a reasonable alternative to a separate image editor, and has zero of the power of JR Media Center. Huge caution: Do NOT enable or use the ability of Picasa to upload ("synch, but not really) with anything online. Mainly, don't sign-in to Google via Picasa. Because Google messes with image resolution and even colors, tends to create dupes and/or delete local copies, and likely will disable or break a local Picasa install. Just use Picasa as a local editor.

There are several other image editors, some free (Gimp, notably, and image editors in various versions of Windows). But Picasa stands out for being easy to use for most needs, with good results.

But if other MC users have suggestions, please advise, I'm always looking for a good-better-best.

[marko]

I'm the same as MusicHawk, only I use Adobe Lightroom instead.

Import into Lightroom.
Tag in Lightroom.
Edit in Lightroom.
Export from Lightroom to a watched MC folder.

MC picks up the exported photos, imports all of the tags, automatically replicating the Lightroom tag heirarchy, presenting them for viewing on the HTPC.

The MC editor started to make inroads some years ago, but is still wanting in many areas.
As Listener has learned, there is no 'export' command. So, while it is great that MC edits are non-destructive, it's pretty pointless without an export command.
If we edit an image in MC, then upload said image to FTP or online service, only the original file is uploaded. Same applies if we choose to email the image to someone... only the original is sent.

It has been a while since I tried them, but when I did, I found the editing tools quite crude, with very little scope for fine control, ultimately finding the whole thing too frustrating. The deal breaker for me, very quickly, was the lack of export/retention of tags, ie. no EXIF.

I have waited patiently through each major build since those years back, hoping that maybe this cycle would see some more work in this area, but so far, it's been TV all the way, baby!

Maybe not the answers Listener was looking for, but it's where I'm at and how I do it. For me, MC is not adept enough at handling internally edited files, and the editing tools are still a bit on the course side to be of any real use. I do still live in hope though, that one day, I may be able to ditch Lightroom.

-marko

[Listener]

MusicHawk, thanks for your detailed reply.

I found one idea in your post to be especially interesting: tag a photo in JRiver, edit it externally and save back to the same file name.  The external editor may not write the JRiver tags back to the image file. However, the JRiver tags are still in the its database. If I update tags from library, the tags will be written back into the edited file.  I tried it out using ACDSee Pro as the external editor.  ACDSee does not write the JRiver tags back to the edited file but doing the update tags from library command seems to store the tags in the file.

I downloaded a copy of the Windows based Picasa editor some time ago but have never used it.  Finding a separate photo editor isn't my central problem.  Building a workflow that lets me handle everything from initial selecting and tagging through editing to final tagging for permanent storage is my goal. Recently I have been using ACDSee Pro for selecting and editing.  I store common name and scientific name in the image file name and place those selected and edited files in a selected folder.  No tags at all.

I'd like to get a complete workflow that lets me use tags.  I like JRiver's database and UI for both initial tagging and later image management.  If it could also  be used for my routine editing, that would make for a really well integrated workflow.

[MusicHawk]

Lots of ways to use MC and an external image editor, no right or wrong. For tougher tasks I use PhotoShop, GIMP, IrfanView and other image editors.

But for the majority of snapshot-type photos, I settled on Picasa to AVOID extra steps. That's the benefit to me, but it comes with the limitations of what Picasa can do. MC and Picasa are working with the same paths, folders and files. There is NO import/export involved, and because it does not seem to touch tags it doesn't support (or, mess up Caption or Date, just about the only tags editable in Picasa).

The benefit is, I just work on a photo's tags in MC, and I work on a photo's image characteristics in Picasa....nothing to do. No copy step needed (unless I want to for another reason), import/export/update tags, nothing. I always have MC set to store tags in files, so that simply happens. If I change a Caption in Picasa, when I switch back to MC, it is showing the revised caption. Nothing involving tags or the image files is imported/exported, all the work is done on the same file at its normal location, separated in time by seconds as I switch between the apps. Both apps immediately reflect whatever I did. That's a very simple fast workflow for what I need to do.

Of course, I'm limited to the image editing scope of Picasa, to do more I do have to locate the image file via some other app, do the work, then put it back where MC can find it.

Since Google is not going to further develop Picasa, the hope is that JRiver will either improve MC's image editor, or strengthen the ability to two-way integrate with external editors without a bunch of steps.

Of course, when moving files among various editors, plus cameras and scanners, it would be very nice for everyone to use the same tags.

Years ago I stopped directly using MC's proprietary image tags for People, Places, Events, etc, because it was a dead-end, these tags seem to be invisible to other apps. Instead I use the trick of stashing these tags (and a couple of other custom fields) in the Keywords field which is more-or-less standard. For instance, I have separate views of major tag categories that are actually nested values in Keywords, such as !Events, !Homes, !People, !Places, !Roads (most of my photos are travel-related).

It is even possible to use Picasa's face recognition and get the associated name stashed in a file tag that MC can read.

(For details and steps, search the forums, probably discussed in earlier versions of MC but the methods still work for me in MC22.)

[Listener]

Marko, I was hoping that you would respond.  Before starting this thread, I searched for old posts about image editing and tagging.  I found some of your posts so then I searched for your posts on the subject.

My comments in bold type below.

I'm the same as MusicHawk, only I use Adobe Lightroom instead.

Import into Lightroom.
Tag in Lightroom.
Edit in Lightroom.
Export from Lightroom to a watched MC folder.

I've had Lightroom for several years (started with v. 3xx) but I just find it to be slow, awkward and un-intuitive.  I made another effort a few days ago without no better results.  I didn't find clear answers in the documentation about what is written to the files and when and using the program was as awful as ever.  Although ACDSee Pro has similar modes, it is quick, slick and intuitive to use.

MC picks up the exported photos, imports all of the tags, automatically replicating the Lightroom tag heirarchy, presenting them for viewing on the HTPC.

Are you using Keywords to store tag info in Lightroom?  I was aware of the idea of nested keywords.  However, I expect to have 500-1000 different for common names and a like number of scientific names and the Lightroom UI might not scale well well. (Or the JRiver UI for hierarchical keywords.)  ACDSee Pro can read IPTC keywords but it uses its own format for hierarchical tags and doesn't write them back to the file unless you explicitly tell it too.

The MC editor started to make inroads some years ago, but is still wanting in many areas.
As Listener has learned, there is no 'export' command. So, while it is great that MC edits are non-destructive, it's pretty pointless without an export command.

OK, that's the answer that I was looking for. BUMMER!

If we edit an image in MC, then upload said image to FTP or online service, only the original file is uploaded. Same applies if we choose to email the image to someone... only the original is sent.

It has been a while since I tried them, but when I did, I found the editing tools quite crude, with very little scope for fine control, ultimately finding the whole thing too frustrating.
The deal breaker for me, very quickly, was the lack of export/retention of tags, ie. no EXIF.

Yes, I used JRiver to tag photos while we were on a 6 week trip in Australia.  When I saved a file to a different file name, I had to go through the tagging process again.  That gets old pretty fast.

I have waited patiently through each major build since those years back, hoping that maybe this cycle would see some more work in this area, but so far, it's been TV all the way, baby!

Maybe not the answers Listener was looking for, but it's where I'm at and how I do it.

I appreciate getting your answer.  I can stop beating my head against the wall.

For me, MC is not adept enough at handling internally edited files, and the editing tools are still a bit on the course side to be of any real use. I do still live in hope though, that one day, I may be able to ditch Lightroom.

Most of the time, I select the best image of a type, crop to suit my purpose and save it to a new file name.  I could live with JRiver's image editing for most of my needs and use an external editor for the exception cases.

I'll continue trying to find a workflow solution that fits my needs.

[marko]

Editing aside, MC is great for working with pictures, but, this may not be quite true 'out of the box'.

Over the years, I've made several adjustments to my workflows, and really leveraged the power of MC's database (custom fields) and expressions, just about everywhere in my image library. Expressions in thumbnail text are coloured red if I've forgotton to tag an artist (photographer), for example, and much more.

'tag on import' rules abound, and several creative expression based fields created purely to group photos I need to work on in a way that helps me get that work done.
If I were to list them all, you would think I was mad, but, these things really are maintenace free. Once set, you really can forget them. So much so, that I use MC's notes feature to record the expressions used, just in case I need a reminder about what's going on. I can't remember the last time I looked at them.

I'll continue trying to find a workflow solution that fits my needs.

Over the years, I've entertained both ends of the conundrum...
tag and organise in MC, then edit externally, and where I'm at now, tag and edit externally, then send to MC, where they're good to go immediately.

The basics of the latter are outlined above.

Thinking out loud about things that used to help back in the day when I only had cheap cameras (no RAW), imported and tagged in MC, then would edit in Photoshop, also, try and answer some of your questions from above:

Are you using Keywords to store tag info in Lightroom?  I was aware of the idea of nested keywords.  However, I expect to have 500-1000 different for common names and a like number of scientific names and the Lightroom UI might not scale well well. (Or the JRiver UI for hierarchical keywords.)  ACDSee Pro can read IPTC keywords but it uses its own format for hierarchical tags and doesn't write them back to the file unless you explicitly tell it too.

Yes. All of my tags are held in keywords. Everything out there reads them, though they all handle nesting heirarchies a little differently from each other. As MusicHawk already mentioned, the proprietry MC tags for Events, Places, People etc do not transport well so are lost when shared with friends/family.

Lightroom, on export, can save a flat, comma separated, set of keywords to the IPTC field, but, also saves pipe separated heirarchy in the exported XMP data. MC can now read that from XMP, and with some lateral thinking, we can get MC to import that data to keywords (and/or a separate custom field) in such a way as to reporduce the heirarchy. It's a recent thing, and is working a treat. Full info is here: Re: Lightroom Hierarchical Subject - How can I create a tag in j.river

If you're going to be dealing with several thousand keywords, I would suggest that nesting would be an absolute necessity. MC will be able to handle them all, so no worries there.
I don't know how, or where, AcdSee saves its heirarchies, but there's a good chance MC would be able to read that, and if necessary, we could manipulate that info into a format MC could use for nesting.

This could be useful for you...

When I saved a file to a different file name, I had to go through the tagging process again.  That gets old pretty fast.

If you predominantly tag and organise inside MC, consider this...
In MC's arsenal, is "Send to... > External"
When you add an external program to send to, you can choose to have MC send a copy, instead of the original... you with me?
I have two entries in my list for photoshop... one sends the original file, one sends a copy.
Here's the good bit...
If you send a copy, MC will "stack" it with the original file, placing it 'on top of the stack' so that although both original and copy are in your library, you only see the copy. Once you save the changes you made to the file in the external editor, so long as the folder is in the auto import list, MC will automatically pick up those changes and update its thumbnail etc. If your editor removed any of the tags, run update tags from library to have MC rewrite them.

So, with one "send to" command:
That's the 'save to a different filename' taken care of, MC appends _EDIT to the filename.
Tagging taken care of.
Import to MC taken care of.
Management in MC somewhat taken care of.

I say 'somewhat' taken care of, because, if you're anything like me, you'll want to be able to have some way of managing your stacks of images. Should you find that this is the beginnings of a workflow you could use, I can, if you want, get you right up to speed with stacks (there's posts somewhere, didn't save them, would need to search, wouldn't take long ) as well as give a 'stack management' view to ease the OCD anxiety brought about by not having one!

-marko.

[Listener]

Lots of ways to use MC and an external image editor, no right or wrong. For tougher tasks I use PhotoShop, GIMP, IrfanView and other image editors.

But for the majority of snapshot-type photos, I settled on Picasa to AVOID extra steps. That's the benefit to me, but it comes with the limitations of what Picasa can do. MC and Picasa are working with the same paths, folders and files. There is NO import/export involved, and because it does not seem to touch tags it doesn't support (or, mess up Caption or Date, just about the only tags editable in Picasa).

The benefit is, I just work on a photo's tags in MC, and I work on a photo's image characteristics in Picasa....nothing to do. No copy step needed (unless I want to for another reason), import/export/update tags, nothing. I always have MC set to store tags in files, so that simply happens. If I change a Caption in Picasa, when I switch back to MC, it is showing the revised caption. Nothing involving tags or the image files is imported/exported, all the work is done on the same file at its normal location, separated in time by seconds as I switch between the apps. Both apps immediately reflect whatever I did. That's a very simple fast workflow for what I need to do.

Of course, I'm limited to the image editing scope of Picasa, to do more I do have to locate the image file via some other app, do the work, then put it back where MC can find it.

Since Google is not going to further develop Picasa, the hope is that JRiver will either improve MC's image editor, or strengthen the ability to two-way integrate with external editors without a bunch of steps.

Of course, when moving files among various editors, plus cameras and scanners, it would be very nice for everyone to use the same tags.

Years ago I stopped directly using MC's proprietary image tags for People, Places, Events, etc, because it was a dead-end, these tags seem to be invisible to other apps. Instead I use the trick of stashing these tags (and a couple of other custom fields) in the Keywords field which is more-or-less standard.

It is even possible to use Picasa's face recognition and get the associated name stashed in a file tag that MC can read.

(For details and steps, search the forums, probably discussed in earlier versions of MC but the methods still work for me in MC22.)

Your earlier post gave me the idea of editing an image file with an external editor and saving the result back to the same file.

Marko added the ideas about editing a copy of the original image file and saving the result back to that copy.  Back in JRiver, the copy is treated as part of a stack with the original image file.

Using those two ideas, I can see a way to construct a workflow that will fit my needs.

I understand your point about JRiver's fields being a dead end.  However, within the JRiver system, those fields and the views I create offer flexibility that helps me tag image files very quickly.

I'm inclined to stick with JRiver fields for regular use and to look for a way to copy the key information back to IPTC fields and keywords once the metadata is stable.  That would give me a way to use my metadata with other programs.

I Googled for info about Picasa's handling of keywords and other metadata.  This article seems quite relevant:

http://www.organizepictures.com/2013/09/everything-you-need-to-know-about-picasa-metadata

If it can write heirarchical keywords that Lightroom could read, that might be useful to me.

Thanks for giving me good information and new ideas that moved my thinking along.  I see light at the end of the tunnel now.

[Listener]

Editing aside, MC is great for working with pictures, but, this may not be quite true 'out of the box'.

Over the years, I've made several adjustments to my workflows, and really leveraged the power of MC's database (custom fields) and expressions, just about everywhere in my image library. Expressions in thumbnail text are coloured red if I've forgotton to tag an artist (photographer), for example, and much more.

'tag on import' rules abound, and several creative expression based fields created purely to group photos I need to work on in a way that helps me get that work done.
If I were to list them all, you would think I was mad, but, these things really are maintenace free. Once set, you really can forget them. So much so, that I use MC's notes feature to record the expressions used, just in case I need a reminder about what's going on. I can't remember the last time I looked at them.
Over the years, I've entertained both ends of the conundrum...
tag and organise in MC, then edit externally, and where I'm at now, tag and edit externally, then send to MC, where they're good to go immediately.

The basics of the latter are outlined above.

Thinking out loud about things that used to help back in the day when I only had cheap cameras (no RAW), imported and tagged in MC, then would edit in Photoshop, also, try and answer some of your questions from above:

Yes. All of my tags are held in keywords. Everything out there reads them, though they all handle nesting heirarchies a little differently from each other. As MusicHawk already mentioned, the proprietry MC tags for Events, Places, People etc do not transport well so are lost when shared with friends/family.

My uses for images are probably rather different from yours.  Metadata isn't involved when I share photos with friends.  I expect to use it mostly for my wife's and my retrieving images from our inventory.  A casual count turns up 130,000+ image files totaling over 670 GB.

Lightroom, on export, can save a flat, comma separated, set of keywords to the IPTC field, but, also saves pipe separated heirarchy in the exported XMP data. MC can now read that from XMP, and with some lateral thinking, we can get MC to import that data to keywords (and/or a separate custom field) in such a way as to reporduce the heirarchy. It's a recent thing, and is working a treat. Full info is here: Re: Lightroom Hierarchical Subject - How can I create a tag in j.river

I'd like to go the other way: JRiver fields to hierarchical keywords and IPTC standard fields.

If you're going to be dealing with several thousand keywords, I would suggest that nesting would be an absolute necessity. MC will be able to handle them all, so no worries there.

Flat keywords clearly wouldn't work for a large number of values.  My choice is between nested keywords and JRiver fields.  I've been testing the new taq field lately to see whether the severe bug I encountered in 2015 is still present.  So far not.  A couple of days ago, I was able to tag 800+ out of 1336 image files n 2-3 hours using JRiver fields and a panes view I constructed.

I don't know how, or where, AcdSee saves its heirarchies, but there's a good chance MC would be able to read that, and if necessary, we could manipulate that info into a format MC could use for nesting.

ACDSee can store  keywords in an IPTC standard format.  It has a separate set of metadata for its own ACDSee keywords and categories.  That metadata is stored as XML data but not in the Lightroom format.  Two links

http://dev.exiv2.org/boards/3/topics/1912

https://forums.adobe.com/thread/1260616

I think that JRiver's team would have to do some work to bring this data in.  Or perhaps a user might write a plug-in.  XML is all text in a standardized format so code to read and write it can be template driven.  If JRiver invested a bit in creating the code to use templates to read and write metadata in XML format, JRiver might be able to read and write a variety of metadata understood by a number of different programs.

This could be useful for you...If you predominantly tag and organise inside MC, consider this...
In MC's arsenal, is "Send to... > External"
When you add an external program to send to, you can choose to have MC send a copy, instead of the original... you with me?
I have two entries in my list for photoshop... one sends the original file, one sends a copy.
Here's the good bit...
If you send a copy, MC will "stack" it with the original file, placing it 'on top of the stack' so that although both original and copy are in your library, you only see the copy. Once you save the changes you made to the file in the external editor, so long as the folder is in the auto import list, MC will automatically pick up those changes and update its thumbnail etc. If your editor removed any of the tags, run update tags from library to have MC rewrite them.

So, with one "send to" command:
That's the 'save to a different filename' taken care of, MC appends _EDIT to the filename.
Tagging taken care of.
Import to MC taken care of.
Management in MC somewhat taken care of.

Boy, you really earned your keep with that suggestion.  If you ever come my way, I'll buy you dinner.

I tried the idea out and got it working using ACDSee to edit the _EDIT file.  I found that the "Expand stack" command doesn't work in the Recently imported playlist but when I tried it in a normal view, I could see the _EDIT file and verify that all the metadata fields were in the database for the _EDIT file.  I need to verify that the corresponding tags are in the _EDIT file.

I say 'somewhat' taken care of, because, if you're anything like me, you'll want to be able to have some way of managing your stacks of images. Should you find that this is the beginnings of a workflow you could use, I can, if you want, get you right up to speed with stacks (there's posts somewhere, didn't save them, would need to search, wouldn't take long ) as well as give a 'stack management' view to ease the OCD anxiety brought about by not having one!

 Yeah, more things to figure out.  However, you really gave me a new way forward. I've already started making a list of things to investigate and figure out.

- I've never used stacks in JRiver before.  I need to get myself up to speed.  You mentioned links or other resources.

- After I edit the _EDIT copy externally and save it, JRiver picks up the change in the watched folder but the thumbnail on top of the stack appears to be that of the original image file.  I'd like to have direct access to the _EDIT file without having to expand the stack for every such _EDIT file.

- I'd prefer to work with JRiver fields rather than hierarchical keywords in JRiver.  Once I've finished tagging files from an occasion, I'd like to be able to copy the metadata to the image files in IPTC and Lightroom standard fields and keywords.  Got macros for that?

- The editing workflow you described fits my most common case very well.  Crop the image, store it in a stack with the original. 

Another case: I see a small insect on a flower and crop once to show the whole flower.  Then I create a closer crop to show the insect in more detail. 

Another case: An original image has two separate areas of interest so I need to crop once to capture one area of interest at adequate size and then crop the original again to capture the other area of nterest.

I need to remember all the usual cases that come up and be sure my new workflow can handle every one.

Your posts have been very helpful to me.  I'd welcome anything else you have to say.

[marko]

I'd like to go the other way: JRiver fields to hierarchical keywords and IPTC standard fields.

I'll have to have a think about this. Perhaps we can revisit it later on once you've firmed up your workflow and settled on the fields being used?
As it is right now, MC saves it's keywords data to the IPTC keywords field.
When using nesting, MC uses Windows Explorer type paths, so, "This\Is\A\Flower" would be nested in MC exactly as if it were a folder path.
If that was a tag, then MC would also save that literal keyword to the IPTC tag... "This\Is\A\Flower"
Lightroom can be set to translate that to its own heirarchy system, which in turn, also alters the IPTC keywords, as Lightroom would save those as individuals, "This, Is, A, Flower"
You can set Lightroom not to auto update the file tags if you like.
I do not know if AcdSee has a similar 'convert' feature when importing new files.

I think that JRiver's team would have to do some work to bring this data in.  Or perhaps a user might write a plug-in.  XML is all text in a standardized format so code to read and write it can be template driven.  If JRiver invested a bit in creating the code to use templates to read and write metadata in XML format, JRiver might be able to read and write a variety of metadata understood by a number of different programs.

MC currently has the "Tag()" function in its expression list. The theory is that we can use it to extract any specified tag data from a file, into MC. In practice, it's quite difficult to use as the referenced data has to be referenced exactly as it is in the metadata, and knowing what that is is all but impossible. Matt was able to add the Lightroom parsing quite quickly though, which leaves me feeling reasonably confident that, if required, with a little help from Matt, we could probably get at the AcdSee data. Nothing is ever guaranteed mind you, and I have no idea at all what Matt has to actually do to make that work for us

Yeah, more things to figure out.  However, you really gave me a new way forward. I've already started making a list of things to investigate and figure out.

- I've never used stacks in JRiver before.  I need to get myself up to speed.  You mentioned links or other resources.

In this post, I've shared the 'Stack Manager' view that I use. Somewhere in that post, is a "click here to read" link that leads to another post I made where I try to explain the mechanics of stacking in MC as best I understand it. If these generate more questions than answers, just ask

- After I edit the _EDIT copy externally and save it, JRiver picks up the change in the watched folder but the thumbnail on top of the stack appears to be that of the original image file.  I'd like to have direct access to the _EDIT file without having to expand the stack for every such _EDIT file.

I'll need to test this to make sure nothing has gotten broken as it's been a while since I used it, but what you've said doesn't sound right.
When you "send a copy" to an external program, MC should place the "_EDIT" file on top of the stack, so you should always see that one, and need to expand the stack to see the original?
Also, once you've saved the changes to the "_EDIT" file, and MC picks up those changes, it should also update the thumbnail?
Sometimes, I find that auto import falls asleep on me and doesn't pick up on the 'file with external changes' quick enough for my impatience. In those rare cases, an "Update tags from library" followed by an "Update library from tags" always sorts things out. MC usually picks up the change within minutes, but I have known it take longer than that, up to five or ten minutes longer sometimes.

- I'd prefer to work with JRiver fields rather than hierarchical keywords in JRiver.  Once I've finished tagging files from an occasion, I'd like to be able to copy the metadata to the image files in IPTC and Lightroom standard fields and keywords.  Got macros for that?

Yes, maybe...
As mentioned above, MC automatically writes its keywords data to IPTC keywords. It uses a semicolon as a delimiter, and we have no control over it. MC just does it and that's the way it is. This has never been an issue for me.
Lightroom can read that keyword data on import and convert it to it's own heirarchy format.
In the "Lightroom Heirarchical Subject" thread I referenced earlier, I mention a method of pushing data from combined fields into MC's keywords field. Again, we are probably better to revisit that once you've firmed up your workflow and fields. I'm pretty confident that whichever way you go in MC, we can get the data from your chosen fields combined into the keywords field, hopefully with nesting too if you prefer that, which in turn, should make said data available to other programs.

- The editing workflow you described fits my most common case very well.  Crop the image, store it in a stack with the original.

Another case: I see a small insect on a flower and crop once to show the whole flower.  Then I create a closer crop to show the insect in more detail.

Been there. Once I'm done with the first one, I would send a "copy of the copy" to photoshop, and edit further. As I want both edits available in the library, I then remove the second edit (the _EDIT_EDIT file) from the stack, and rely on tagging to keep them grouped where needed. "Date" most often takes care of this, but as they're all copies, they all have the same tag data anyway, so it's not difficult, whatever you want to key off.

Another case: An original image has two separate areas of interest so I need to crop once to capture one area of interest at adequate size and then crop the original again to capture the other area of interest.

Again, just send another copy to the external editor. This time, MC will create an "_EDIT(1)" file, as the first copy, "_EDIT" already exists. Once done, remove from the stack and apply the same logic as above for grouping in other views.

The 'stack manager' view I referenced above is handy for this kind of thing, as you can see the entire stack regardless of its expanded/collapsed state. Even if collapsed, you can see the 'hidden' original file, and still 'send a copy' of it to your external editor, and while you edit, back in MC, the new file appears in the stack group with the others, so once done editing, removal from the stack is a breeze.
=====

[marko]

Ahhh, the beauty of 'set and forget' eh

I broke my image display caption for a short while last week by adding a second level of nesting (friends and family) to my "People" branch.

Can you remind me of the structure?
What are the expressions and where are they used?

If you can give me that, we should be able to sort it. (maybe start a new thread for that?)

[Listener]

Another very useful post, Marko.

My comments in bold type.

I'll have to have a think about this (JRiver fields to hierarchical keywords and IPTC standard fields).  Perhaps we can revisit it later on once you've firmed up your workflow and settled on the fields being used?

OK.  I'm working through smallish practical details now.  My use of individual fields and the details of my workflow will continue to evolve. 

As it is right now, MC saves it's keywords data to the IPTC keywords field.

Yes. I've looked at the XMP with XNView and with ACDSee.

When using nesting, MC uses Windows Explorer type paths, so, "This\Is\A\Flower" would be nested in MC exactly as if it were a folder path.
If that was a tag, then MC would also save that literal keyword to the IPTC tag... "This\Is\A\Flower"

I was with you until "If that was a tag".




In this post, I've shared the 'Stack Manager' view that I use. ...
If these generate more questions than answers, just ask

I had a look.  Useful ideas.

I'll need to test this to make sure nothing has gotten broken as it's been a while since I used it, but what you've said (_EDIT file not on top of the stack) doesn't sound right.

You are right.  I made some mistakes in doing the experiment.  I am seeing that the _EDIT file is on top after I do the external edit and the MC updates the thumbnail when the auto-import runs.


Yes, maybe...
As mentioned above, MC automatically writes its keywords data to IPTC keywords. It uses a semicolon as a delimiter, and we have no control over it. MC just does it and that's the way it is. This has never been an issue for me.


Lightroom can read that keyword data on import and convert it to it's own heirarchy format.

ACDSee supports ITPC Keywords but doesn't seem to support nesting there.  So when it reads the IPTC Keywords written by MC, it doesn't show the contents as hierarchies.  ACDSee has separate ACDSee Keywords and Categories.  Data is not stored in the Lightroom format and the contents of the IPTC Keywords are not propagated to the ACDSee Keywords.

In the "Lightroom Heirarchical Subject" thread I referenced earlier, I mention a method of pushing data from combined fields into MC's keywords field. Again, we are probably better to revisit that once you've firmed up your workflow and fields. I'm pretty confident that whichever way you go in MC, we can get the data from your chosen fields combined into the keywords field, hopefully with nesting too if you prefer that, which in turn, should make said data available to other programs.

Yes, an expression to combine label/value for several fields into one MC field seems doable.  I don't yet see how to automatically copy that combined value into the MC Keyword field.

Been there (In response to "I see a small insect on a flower and crop once to show the whole flower.  Then I create a closer crop to show the insect in more detail."). Once I'm done with the first one, I would send a "copy of the copy" to photoshop, and edit further. As I want both edits available in the library, I then remove the second edit (the _EDIT_EDIT file) from the stack, and rely on tagging to keep them grouped where needed. "Date" most often takes care of this, but as they're all copies, they all have the same tag data anyway, so it's not difficult, whatever you want to key off.
Again, just send another copy to the external editor. This time, MC will create an "_EDIT(1)" file, as the first copy, "_EDIT" already exists. Once done, remove from the stack and apply the same logic as above for grouping in other views.

I will experiment with different approaches to find one that is simple and can be executed reliably without error. 

I was out locating and photographing wildflowers for four hours yesterday.  128 Jpegs and 3 videos. I imported the folder and spent several hours just browsing through the images.  Big smile on my face for hours. Then I got down to tagging the files. Today, I'm selecting the winners and editing.  The MC-centric workflow let me concentrate on the content rather than the process.  It's dead easy to select all the images of wallflowers and select the winners.  The simple editing case is quick and natural.

[marko]

Well well... Whilst trying to figure out what on earth I had been responsible for in MusicHawk's library, this come up in my search results...
"Nested events - how to display, batch delete, batch assign, etc."

It's from 2014, and, it seems, I do love to spout on about my image library 

A lot of that might have been repeated above, but still, there could maybe be something of interest there too.

MusicHawk,
I moved your expression question into it's own thread, here, http://yabb.jriver.com/interact/index.php/topic,110343.0.html to help keep this one focussed on the original questions.

-marko

[marko]

I have a tab in MC that is always present. It loads up a single photo, picked at random from a set of criteria, one of which is that there are no people (I'm the most anti-social person I know ) and this morning, it offered this up, which made me think of Listener...

I've no idea what it is, a lily of some kind, I guess...

How are you getting on with your image library?

[Listener]

I have a tab in MC that is always present. It loads up a single photo, picked at random from a set of criteria, one of which is that there are no people (I'm the most anti-social person I know ) and this morning, it offered this up, which made me think of Listener...
...
I've no idea what it is, a lily of some kind, I guess...

How are you getting on with your image library?

Thanks for thinking of me.  Very nice image of some kind of lily.  I  make an effort to ID wildflowers but I just ask my wife about the cultivars.

I'm using MC as the central part of my image workflow now.  I import folders from an outing or event, remove the outright duds, select the winners and edit those.  I still have some wrinkles to work out.

Stuff I can do now:

- tagging images with ID info.  So much better with MC.

- selecting winners.  We often get a lot of good photos so winnowing down to a few to publish online takes several rounds.  MC is a good tool for this.

- editing the winners using ACDSee. I'm using your "send to" suggestion to edit the _EDIT copy.  Quite slick.

- copy and rename files with database fields in the filename.  I've done this several times using a calculated field.  I need to refine it with a macro to allow for missing values.

- produce several different edited images from one original.  Duck soup for additional crops and resized files.

I think I know how to copy MC fields values into the IPTC keyword field.   I can create a calculated field to stack the field contents into a single field.  (Just need a macro to deal with missing values.) I can then select files with the keywords field empty and copy the calculated field to the keyword field.

I've been seeing lots of insects this year.  I can't identify very many and I'd like to get better.  When I do get an ID, MC fields seem the right place to keep that info.  The insects are usually in a picture with plants so now I've got two sets of common names and scientific names.  I'm experimenting with list fields and simply a second set of string fields.  I lose some MC  data entry features with list fields.  A second set of string fields is ugly database practice.  However, I think that it might be workable with a second insect oriented view.

The late stages of the workflow where I  set up a SmugMug gallery, copy images to that gallery and add text remains burdensome.  Easier if I just post images to Facebook.

A gallery from a recent outing  made with MC in the workflow:

 https://naturelover.smugmug.com/Nature/Shell-Ridge-Open-Space-Lower-and-Upper-Buck-Trails-4152017

I'm about to post another gallery of pictures from a ~400 image file outing.

Your suggestions really made a difference.  Thanks.

[JimH]

Great photos.  Thanks for sharing.

[Listener]

Great photos.  Thanks for sharing.

Thanks, Jim.

I'm always way behind in processinbg what my wife and I photograph.  We have some things on Flickr

https://www.flickr.com/photos/bill_lesley_photos/

and some galleries from neighborhood walks at

https://naturelover.smugmug.com/Bills-Recovery-photo-therapy

Maybe if I get my MC based workflow really tuned, I might catch up a bit.