<br><br><div><span class="gmail_quote">2007/8/31, Marcel Wiesweg <<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Dnia środa 29 sierpień 2007, Marcel Wiesweg napisał:<br>> > Hi,<br>> ><br>> > It is a long-planned task for the next release to store more information<br>> > than currently in the database.<br>
> > We are currently collecting which fields exactly we want to add.<br>> ><br>> > To qualify for inclusion, IMO a field should fulfill one of these two<br>> > criteria:<br>> > - the field can be of interest in connection with the image it belongs
<br>> > to - searching for the field is a considerable feature<br>> > AND this criterion:<br>> > - the information is usually available for images in a common usage<br>> > pattern of digikam<br>>
<br>> I think we can split all data about image in 3 parts:<br>><br>> - information about file<br>> - information about image ("hardware")<br>> - metadata, here I think the best choice (as industry standard) is "IPTC
<br>>   Core"<br>><br>> > Currently I have these fields on my list:<br>> ><br>> > - comment<br>> > - rating<br>> > - creation date<br>> > - modification date<br>> > - size ( dimensions in pixels)
<br>> > - color depth (8, 16)<br>> > - color model (RGB, CMYK, ...)<br>><br>> - If px size is included why not weight (size in KB/MB)? I know it can<br>>   be read from filesystem but putting info in db could make some queries
<br>>   faster<br><br>Yes I think about it.<br>It comes together with modification date. Both need to be updated after edits.<br>Makes sense.<br><br>> - all path related things (Album path, name of file)<br><br>That was implied ;-)
<br><br>><br>> > - make of the camera<br>> > - model of the camera<br>> > - aperture<br>> > - focal length<br>> > - focalLength as for 35mm film<br>> > - exposure time<br>> > - exposureMode
<br>> > - exposureProgram<br>> > - sensitivity<br>> > - flash<br>> > - whiteBalance<br>> > - orientation<br>><br>> - metering mode<br>> - focus mode<br>> - file number (although it can have different formats so its usefulness
<br>>   can be questionable)<br><br>Are these available from libkexiv2?</blockquote><div><br>Yes and no. This is depand where data are store : in standard Exif or in Makernotes.<br><br>Standard Exif is not a problem to extract. Tags name and value are define in Exif spec.
<br><br><a href="http://www.exiv2.org/metadata.html">http://www.exiv2.org/metadata.html</a><br><br>Makernotes is a big problem. A lots of code need to be written to check all possibilities. Nothing is standardized.<br><br>
This is why i recommend to host only the Exif Standard tags in a first time, and progressivly to add Makernotes. Look my previous post for details.<br> <br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Will someone want to search for the file number, will it ever be displayed in<br>the "Properties" sidebar tab (or only in the metadata tab?)<br><br>> Big question is handling of metadata. I'd like to see whole IPTC Core
<br>> put into database... For fast querying of those items and making it<br>> independent of actual images.<br><br>How many fields does that make?</blockquote><div><br>It's bigger. Look here :<br><br><a href="http://www.exiv2.org/iptc.html">
http://www.exiv2.org/iptc.html</a><br><br>We need to choose the most important. <br><br>Unforget than the new standard is XMP, which remplace IPTC. In general we found a lots of tags IPTC in XMP, but few have been removed, and new have been added. I recommend to use XMP as ref.
<br> <br><a href="http://www.iptc.org/IPTC4XMP/">http://www.iptc.org/IPTC4XMP/</a><br><br></div></div>Gilles<br>