iptc和exif
Related to this hack started taking a serious look at the available standards and Open Source tools for adding meta data to images, in the context of building archives of digital photography. With further prompting from reading this (Hey! MS are adopting someone else’s standard!), dumping some notes…
与此相关的黑客开始认真研究可用的标准和开放源代码工具，以在建立数字摄影档案的情况下向图像添加元数据。 阅读此书后进一步提示(嘿！MS正在采用其他人的标准！)，转储一些注释…
Store metadata in the image.
将元数据存储在图像中 。
Actually should be more precise about the word metadata here – there are essentially three significant types of metadata when in comes to digital images, when it comes to who created it and where it’s stored.
实际上，这里的元数据一词应该更精确-当涉及数字图像，涉及到谁创建它以及将其存储在何处时，本质上存在三种重要的元数据类型。
First; the stuff your digital camera attaches to the image when you take a picture (e.g. camera make, time the picture was taken, exposure etc.), second; meta data you manually add to an image, typically at the time you download images from the camera to your PC (e.g. where the picture was taken, a description, keywords, name of the photographer etc.) and third; “grouping metadata” – how a collection of images relate to each other (e.g. they were all part of a single photo shoot or they are all family pictures). For the purposes of this discussion, the first two types of metadata can be regarded as a the same thing and it’s this information that you want stored in the image.
第一; 拍照时数码相机附在图像上的东西(例如，相机的品牌，拍照时间，曝光等)； 您手动添加到图像的元数据，通常是在您将图像从相机下载到PC时(例如，拍摄的位置，描述，关键字，摄影师的姓名等)和第三次； “分组元数据” –图像集合如何相互关联(例如，它们都是单张照片的一部分，或者都是全家福)。 为了便于讨论，可以将前两种类型的元数据视为同一件事，而正是这些信息要存储在图像中 。
The third type – the “grouping” information is “relative” and, practically, can only work well if it’s stored externally from images. This may be as “lightweight” as a tree of directories on your filesystem with timestamp-based names, under which you store your images, but image archive tools may offer additional facilities in this area. Important is if you want to group a collection of images under a heading like “family”, you also want to have a keyword “family” stored in the image. In such case it may be the image archiving tool can build the groups automatically from your keywords.
第三种类型-“分组”信息是“相对的”，实际上，只有从图像外部存储时，它才能很好地工作。 这可以像文件系统上的目录树一样“轻巧”，具有基于时间戳的名称，您可以在该目录树下存储图像，但是图像存档工具可以在此区域提供其他功能。 重要的是，如果要将图像集合分组在“家庭”之类的标题下，则还希望在图像中存储关键字“家庭”。 在这种情况下，图像存档工具可能会根据您的关键字自动构建组。
But you want the first two types of metadata in the image, so that if you switch archiving tools, transfer your images to another system or forget to backup the archive database but remember the images, it won’t be lost. A decent archiving tool will probably generate it’s own database from this inline metadata, to make searches etc. efficient, but the final authority should be the image itself.
但是，您需要图像中的前两种元数据类型，因此，如果切换归档工具，将图像传输到另一个系统或忘记备份存档数据库但记住图像，则不会丢失。 一个不错的存档工具可能会从此内联元数据生成自己的数据库，以提高搜索效率，但最终的授权应该是图像本身。
The next question is how is data stored in an image. File formats like JPEG, RAW and TIFF, commonly used in digital photography / processing, allow additional metadata to be stored in the image file.
下一个问题是数据如何存储在图像中。 数字照相/处理中常用的文件格式(如JPEG ， RAW和TIFF)允许将其他元数据存储在图像文件中。
So here’s a “avoid too much detail” view: there are three significant inline metadata formats here – Exif, IPTC and XMP. Exif is used by most digital cameras to attach information like exposure at the point you take a picture and tools are available for adding information manually (or automatically) such as geocoding. IPTC “extends” Exif, providing a whole load more named “tags” for metadata. Both are fragile from a technical point of view (easy to destroy / corrupt) and problematic from the point of view of extending (if there’s no named “tag” for the metadata you want to store, you’re out of luck). Meanwhile, XMP, the work of Adobe, is the “holy grail”, providing XML / RDF / Dublin core goodness for storing metadata. It’s just not well supported yet, but starting to gain significant acceptance. And of course our friend IE has it’s own opinion about XMP…
因此，这里有一个“避免过多的细节”视图：这里有三种重要的内联元数据格式-Exif ， IPTC和XMP 。 大多数数码相机都使用Exif来附加信息，例如在拍摄时曝光，并且可以使用工具手动(或自动)添加信息，例如地理编码 。 IPTC“扩展”了Exif，为整个元数据提供了更多名为“标签”的负载。 从技术的角度来看，它们都是脆弱的(容易破坏/损坏)，从扩展的角度来看，它们都是有问题的(如果要存储的元数据没有命名的“标签”，那么您就不走运了)。 同时，Adobe的XMP是“圣杯”，它提供了XML / RDF / Dublin核心优点来存储元数据。 它目前还没有得到很好的支持，但是开始获得广泛认可。 当然，我们的朋友IE对XMP也有自己的看法 ...
In practice, you need to be able to work with all three formats for effective photo archiving.
实际上，您需要能够使用所有三种格式来进行有效的照片存档。
There are a bunch of image archiving tools out there, for any and all operating systems. A good one will allow you to manually supply additional meta data about an image (e.g. keywords like “family”, “dog” etc.) but, from a straw poll, the majority store this data separately from the image, in some kind of database. Where Ubuntu is concerned GThumb does just this – stores any user supplied meta data externally from the image (if I remember right, it’s under ~/.gnome2/gthumb).
对于任何和所有操作系统，都有大量的图像存档工具。 好的可以让您手动提供有关图像的其他元数据(例如，诸如“ family”，“ dog”之类的关键字等)，但是，从稻草调查中，大多数人会以某种形式将这些数据与图像分开存储数据库。 关心Ubuntu的地方GThumb就是这样做的-在映像的外部存储任何用户提供的元数据(如果我没记错的话，它位于~/.gnome2/gthumb )。
There’s a bunch of reasons why I consider this fundamentally wrong, which become obvious the moment an image leaves your filesystem (or perhaps even changes directory / filename) plus the fact that there’s no “clear winner” in the image archiving space – there’s a good chance you’ll switch tool more than once. Bottom line: storing metadata separately from the image it refers to is just not the way to do it.
有很多原因使我认为这根本上是错误的，当图像离开您的文件系统(甚至可能更改目录/文件名)时，这一点就变得显而易见，并且在图像归档空间中没有“明显的赢家”这一事实–有一个很好的选择。您有机会多次切换工具。 底线：将元数据与它所引用的图像分开存储，但这并不是做到这一点的方法。
In the Open Source / Linux space, there are a couple of contenders which are getting it “right”, namely F-spot (C# / Mono) and jbrout (python / wxpython). Both are capable of storing metadata in the image but there are limitations, e.g. jbrout has no awareness of XMP. Some worthwhile blogs (and comments) to read are How to manage EXIF, XMP metadata on linux gnome kde, Managing Photographs and Photo organizing in Linux.
在开源/ Linux空间中，有一些竞争者正在使它“正确”，即F点 (C＃/ Mono)和jbrout (python / wxpython)。 两者都能够在图像中存储元数据，但是存在局限性，例如jbrout不了解XMP。 一些值得阅读的博客(和评论)包括： 如何在Linux gnome kde上管理EXIF，XMP元数据，在Linux中 管理照片和照片组织 。
By contrast, the model application, IMO, for how to do it right (sadly Win32 only) but free to use is PixVue.
相比之下， PixVue是模型应用程序IMO，用于正确执行操作(仅适用于Win32)，但可以免费使用 。
For starters, rather than being an monolithic application, it adds a bunch of Windows Shell Namespace Extensions meaning you can work with your images in Windows Explorer – e.g. right click and “annotate” with your metadata.
首先，它不是一堆的应用程序，而是添加了许多Windows Shell命名空间扩展，这意味着您可以在Windows资源管理器中使用图像-例如，右键单击并用元数据“注释”。
As I see it “Digital workflow”, in general, is all about procedures – you need “process oriented” applications that fit into your procedure, rather than monolithic windowed views of your images, which dictate how you work. PixVue gets this right by getting out of the way and hence my desire to extend Nautilus.
当我看到它“数字化工作流程”，在一般情况下，是所有关于程序-你需要“过程导向”的应用程序，适合你的方法，而不是你的图像，这决定你是如何工作的整体式窗口的意见。 PixVue通过避开障碍来实现这一目标，因此我渴望扩展Nautilus 。
PixVue also stores almost all metadata in the image, understanding EXIF, IPTC and XMP. The exception is the “grouping” metadata, which it provides something called “galleries”, which are a virtual directory hierarchy – in Explorer you can drag and drop images into a gallery (or galleries) to organise them but these are only “symbolic links” to the original files on your filesystem. You can also export your gallery structures as XML, to allow at least the chance of portability.
PixVue还可以存储映像中的几乎所有元数据，了解EXIF，IPTC 和 XMP。 “分组”元数据是一个例外，它提供了一个称为“画廊”的东西，这是一个虚拟目录层次结构–在资源管理器中，您可以将图像拖放到一个(或多个)画廊中进行组织，但这些仅仅是“符号链接” ”到文件系统上的原始文件。 您还可以将库结构导出为XML，以至少允许可移植性。
Also the “templates” functionality it provides helps make attaching metadata to a large collection of images as fast and painless as possible.
它还提供的“模板”功能有助于使元数据尽可能快速，轻松地附加到大量图像上。
Finally it has excellent search facilities (via the gallery view) plus it “integrates” with (populates the indexes of) Windows search and Google desktop.
最后，它具有出色的搜索功能(通过画廊视图)，并且与Windows搜索和Google桌面“集成”(填充索引)。
The only downside of PixVue is the source isn’t available and there doesn’t seem to be an API (it does register some COM components but, from a quick scan, these don’t allow you to drive it with, say, a Python script), so if you want to extend it to integrate with some geocoding tool, you’re out of luck.
唯一的缺点PixVue的是源不可用， 似乎没有成为一个API(它确实有些注册COM组件，但是，从快速扫描，这些不允许你用，比方说，一个驾驶它Python脚本)，因此，如果您想扩展它以与某些地理编码工具集成，那么您将很不走运。
So, given a less-than-ideal situation for Open Source image archiving applications, what’s available in the form of libraries, so you can hack your own?
因此，鉴于开放源图像归档应用程序的情况不太理想，有哪些库形式可用，因此您可以自己破解？
The long and short of it is more bad news. There’s a whole bunch of libraries that do a little bit, perhaps only (partially) understanding one format (typically Exif), read only – not write or lacking support for manufacturer Exif extensions.
多亏是坏消息。 有一大堆库在做一些事情，也许只是(部分地)理解一种格式(通常是Exif)，只读–不写或不支持制造商的Exif扩展。
The situation is particularly acute when it comes to Python, which is badly lacking – there’s a few “readers” out there, and the occasional writer (no XMP writer though) but nothing that’s really complete. That’s bad news for jbrout and even more bad news for Python on Series 60 phones, where being able to tag your pictures, while you sit on a train, would be a killr app.
当涉及到Python时，这种情况尤其严重，这是非常缺乏的-那里有一些“阅读器”，偶尔还有作家(虽然没有XMP作家)，但没有什么是真正完整的。 对于jbrout来说，这是个坏消息， 对于Series 60手机上的Python来说，这甚至是更多的坏消息，当您坐在火车上时，能够为您的图片加上标签将是一个杀手级应用。
There are exceptions though, the #1 being Phil Harvey’s exiftool (Perl – available via CPAN). ExifTool isn’t just good – it’s excellent. It’s basically got it all – EXIF, IPTC and XMP support (read/write), support for manufacturer extensions and a common dictionary of tag names that are, to an extent, metadata-format-independent. The only downside is there doesn’t seem to be (correct me if wrong) a GUI front-end for Linux that exposes all of Exiftool’s functionality – you’re either talking command line or writing your own Perl scripts.
但是，也有例外，排名第一的是Phil Harvey的exiftool (Perl –可通过CPAN获得 )。 ExifTool不仅好，而且很棒。 基本上就具备了所有功能– EXIF，IPTC和XMP支持(读/写)，对制造商扩展的支持以及通用的标记名字典，这些字典在某种程度上与元数据格式无关。 唯一的缺点是， 似乎并没有(如果有错，请纠正我)Linux的GUI前端，该前端公开了Exiftool的所有功能-您是在说命令行还是在编写自己的Perl脚本。
Another noteworthy exception Evan Hunter’s PHP JPEG Metadata Toolkit, which has EXIF, IPTC and XMP support and awareness of some manufacturer quirks. The API is also pretty simple.
另一个值得注意的例外是Evan Hunter的 PHP JPEG元数据工具包 ，它具有EXIF，IPTC和XMP支持，并且对某些制造商的怪癖有所了解。 该API也非常简单。
The is of course plenty of other stuff around, which offer part of the picture e.g. jempbox (Java) but YMMV.
当然还有很多其他的东西，它们提供了部分图片，例如jempbox (Java)但YMMV。
Anyway – hopefully that saves someone some time in research.
无论如何–希望可以节省一些研究时间。
翻译自: https://www.sitepoint.com/open-source-image-archiving-exif-iptc-xmp-and-all-that/
iptc和exif
相关资源：ExifReader, JavaScript Exif信息分析器.zip