![]() ![]() Different organizations and audiences will have different needs that can only be addressed by human judgment. Where I live in the US, some locations aren’t in incorporated municipalities. Some human supervision is a good idea here, anyway. Photo Mechanic lead developer Kirk Baker is on the case. The correct city information is there in OSM, but surfacing it isn’t as straight forward as one would hope. Open Street Map doesn’t understand the idea of “city” the same way that most photographers (and the IPTC) do. Photo Mechanic uses the open source Open Street Map database. I have seen occasions when reverse geocoding fails to fill the City field. In some cases, I’ve seen it resolve down to the name of a business or landmark, like my favorite bar. Now you can automatically, or on command, resolve GPS coordinates embedded in the Exif data to fill in your IPTC location fields – City, State or Province, and Country. Photo Mechanic 6 adds reverse geocoding to its impressive portfolio of GPS features. But we should avoid doing that.) Fun functionality ![]() For other TIFF based RAWS, many applications – Photo Mechanic included – will attempt to write into such files if you insist on it. (Note that Adobe DNG files are intended to carry embedded metadata. But, if you do, it’s worth bearing in mind how Photo Mechanic now handles them. Most readers of this blog will tread close enough to best practices that they – hopefully – will rarely encounter RAW files with embedded metadata. In such a case, Photo Mechanic now evaluates both instances of the metadata and goes with the newest. Photo Mechanic no longer askes whether to read from the XMP sidecar or embedded metadata in the case of RAW files that have both. The big news here is that it now evaluates each field individually! This aligns Photo Mechanic’s behavior with most newly-developed applications and with the current behavior of Adobe products. If there’s a value there, it will read it. Photo Mechanic will now always look for the XMP version of a field first. No longer must we specify in the preferences whether we want to prefer one or the other. Metadata geeks – the readers of this blog included – will be interested to learn that version 6 simplifies and automates the matter of read order between the IIM and XMP data blocks. But after using version 6 for a few weeks now, I can attest that it does feel snappier. So, for most users, the speed increase won’t be glaringly obvious. It’s clever enough that it draws thumbnails first where ever you scroll the contact sheet. Generally, it reacts to commands instantly. Of course, Photo Mechanic has always been fast. Photo Mechanic 5 took 5 minutes and 45 seconds to complete my test and Photo Mechanic 6 blasted through the folders in a minute and 57 seconds. I conducted a highly unscientific test on a directory tree with a couple thousand images in it. Orlosky said the most noticeable improvement is in the generation of thumbnails. Camera Bits claims a two to three times increase. In any case, the jump to 64 bits, and improvements in how the program handles cache bring with them a significant jump in speed. The downside is that if you’re still running an ancient 32-bit copy of Windows XP, you’ll either have to upgrade the old OS or stay on Photo Mechanic 5. Now, it’s to be the next one, in a year or so. Apple threatened to orphan 32 applications in their just-released OS. ![]() ![]() It’s now compatible with new, modern operating systems. This is a complete rewrite of the program. The headline item is that Photo Mechanic is now a 64-bit application. So, what’s new in this long-awaited new version of Photo Mechanic? I’ll go over some of the high points here. I demonstrate most of the new features in the video. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |