If there are places where changes are not being applied inside the program, it's a bug.
Please see Point #1 below.
Way back in July I posted some pretty comprehensive feedback with regards to the image editor, and Jim prompted to pick 3 issues that I felt were most important.
Here's a copy/paste of that post:
Which three are most important?
Well now, I've had to give this a fair bit of thought over the weekend, and rolled back to .0.34 to get an editor to work with. The list I came up with, in order of importance...
1. "Send to... > ftp/mail recipient/drives and devices" all use the original file on disk. Pix01 and flickr send the file with the edits applied. They should all apply the edits prior to sending.
I also note that the file that is sent to Flickr is less than half the size of the original file, so figure that there must be some pretty aggressive jpg quality settings going on there. Perhaps consider increasing the
quality, or giving us a slider. Additionally, I see that the file uploaded to Flickr contains XMP and IPTC tags, but no EXIF data. I fully understand that it's a grey area, but I've always been of the opinion that
when saving/sending these 'new' files, MC should also preserve the EXIF data, as there's a lot of useful info in there that shouldn't be discarded because of a simple red-eye fix.
The "Drives and Devices" branch of the "Send To" menu was tested using a USB drive I have here configured as a handheld device. I see that I could have chosen a disc burner here too; I didn't test this option,
but I would expect that the original file will probably be used there too?
2. Moving/Copying the file to a new disk location using MC. When dropping a file with edits at it's new location and selecting the move option, all is good. As expected, MC tracks the file in the database and keeps everything updated.
Note that even when browsing "My Computer" locations within MC, MC still shows edited versions of files with edits. I feel this is correct.
When
copying files to the drop location however, MC simply copies the original file, without edit info, to the specified location. It does this without warning or prompt. I feel this is incorrect.
I can envisage instances where both may be desirable, but, I figure it's far more likely that the end user will be blissfully unaware that the source file contains edits and believe that he/she will be making a file
copy of the file that they see before them. This situation requires a prompt, or warning, possibly with a 'don't show again' option.
3. Confusion with editor history list and file saving. Here's a test file I was messing around with. I put in two text stamps, then some white balance, and finally, a third text stamp.
That's the history list above. This is great while edits are saved in the library, as later on, you can load up the editor and roll back changes. This is not so great if you save as file:
If you save the changes to the original file, then close the editor and the preview window, then open them back up again, you should note the following (using the example history list shown above)
- The white balance has been re-applied to the image, washing it out.
- In the history list, selecting "White Balance" does not remove the final text stamp.
- In the history list, selecting the second text stamp removes the "White Balance" adjustment.
- If you now press "save and close", then open again, the second text stamp remains selected in the history list.
- Despite the fact that MC is applying a double-dose of white balance, and displaying little x's beside the history items, the edits cannot be removed.
So, I feel that....
After saving changes to the original file, the history list should be removed completely.
If you save the changes to a new file, everything as far as the editor is concerned is hunkey-dorey; there is no history to get confused about.
Sadly, there is also not one single tag block in this new file. No EXIF, no XMP, no IPTC, no MJMD, and MC then imports this new file and gives it the windows modified time and date as it's data rather than the
time and date the original photo was actually taken.
Once again I'll say that I'm a strong proponent of propogating all existing tags from the original to the edited file upon any save/upload/send action. Aside from the fact that it's essentially a "new file" so you
could argue that applying metadata from it's source would falsify information about this new image, in real world usage, I can't imagine anyone
not wanting their tags propogated, and if my gut feeling is
correct, then there will be a small minority who really don't want the tags, and for those peeps, there's the "remove tags" tool.
Did you see what I tried to do with the 'text stamp' tool there (in the pix01 link above)?
How good would it be if it could accept library fields and expressions too? Also, it would be nice if the bounding box for the text would expand as needed, and also accept multi-line text entry.
I've only made some quick tests focussing on how MC will deal with edited files vs original file on disk, rather than the individual editor tools themselves, which are sure to come under scrutiny as the editor/preview combination makes it out into the wild!!
Another thing touched upon was perhaps offering a visual indicator that an image contained edits, such as a discreet, optional, overlay icon.
I figured that so long as the issues above were addressed, and we have complete confidence that MC will
always use the edited version of the file when sending anywhere, and that it will propogate
all tag blocks from the original file to the outgoing file, then we shouldn't really need the overlay. It might be nice, but it's nowhere near as important (for me) as the the chosen three issues.
If you do persue this avenue of development, and the overlay icon doesn't make the cut, perhaps consider adding the following search item to the default image "quickies" list: -[edit info]=[] to allow users to quickly list all files that they've edited.
This post has taken an age to compose, I hope you find it helpful!!
-marko.
Author
Topic: Image editing - non-intuitive saving (Read 2112 times)