|
Hi all,
I'd like some advice about how to write the image history xml, which is a QString, into image's metadata. I don't know too much about metadata and rules that need to be followed when writing there. How this should be done in digiKam?
Marty
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
If someone is going to show how Image metadata is handled in digiKam, I want to learn this too. Will be very useful to me for later work.
On Fri, Jun 11, 2010 at 1:22 AM, Martin Klapetek <[hidden email]> wrote: Hi all, -- Aditya Bhatt Blog : http://adityabhatt.wordpress.com Bitbucket: http://bitbucket.org/aditya_bhatt Face Recognition Library : http://libface.sourceforge.net _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hi Martin,
The image history must follow XMP metadata. We have a digiKam XMP namespace. Image history must be recorded to this area : http://www.exiv2.org/tags-xmp-digiKam.html http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#digiKam You said that image history will be a QString. I think that we wil format XML data directly in digiKam. It's definitively a wrong way. You must delegate this point to libkexiv2/Exiv2 Indeep, in digiKam core, the image history will be something like a QMap container, used to discribe : - the image revision. - the tool used to change image. - the tool settings. In XMP, there is a lots of map container available. Look in Metadata Properties section from this doc : http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart1.pdf To host image history to XMP, use Digikam::DMetadata class. Gilles Caulier 2010/6/10 Aditya Bhatt <[hidden email]>: > If someone is going to show how Image metadata is handled in digiKam, I want > to learn this too. Will be very useful to me for later work. > > On Fri, Jun 11, 2010 at 1:22 AM, Martin Klapetek <[hidden email]> > wrote: >> >> Hi all, >> I'd like some advice about how to write the image history xml, which is a >> QString, into image's metadata. I don't know too much about metadata and >> rules that need to be followed when writing there. How this should be done >> in digiKam? >> Marty >> _______________________________________________ >> Digikam-devel mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-devel >> > > > > -- > Aditya Bhatt > Blog : http://adityabhatt.wordpress.com > Bitbucket: http://bitbucket.org/aditya_bhatt > Face Recognition Library : http://libface.sourceforge.net > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
On Fri, Jun 11, 2010 at 11:28, Gilles Caulier <[hidden email]> wrote:
Hi Martin, The image history is basically a QList containing another classes, which holds info about used filters and their settings and also revisions. This QList is transformed into XML (QXmlStreamWriter) when saving the image. And to store the XML in metadata, it's converted to QString for easy manipulation and that will go into metadata. Then it's read back when opening the image as QString and parsed by QXmlStreamReader back into the QList. That should be ok, no?
Yes, that's how it's done right now.
Ok, thanks. Marty _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2010/6/11 Martin Klapetek <[hidden email]>:
> On Fri, Jun 11, 2010 at 11:28, Gilles Caulier <[hidden email]> > wrote: >> >> Hi Martin, >> >> The image history must follow XMP metadata. >> >> We have a digiKam XMP namespace. Image history must be recorded to this >> area : >> >> http://www.exiv2.org/tags-xmp-digiKam.html >> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html#digiKam >> >> You said that image history will be a QString. I think that we wil >> format XML data directly in digiKam. It's definitively a wrong way. >> You must delegate this point to libkexiv2/Exiv2 > > The image history is basically a QList containing another classes, which > holds info about used filters and their settings and also revisions. This > QList is transformed into XML (QXmlStreamWriter) when saving the image. And > to store the XML in metadata, it's converted to QString for easy > manipulation and that will go into metadata. Then it's read back when > opening the image as QString and parsed by QXmlStreamReader back into the > QList. That should be ok, no? > well, you don't need to encapsulated your image history data to XML. Exiv2 will do it for you with XMP. XMP is already based on XML. You will see any problem to encapsulated XML into XMP directly. Use and XMP container. For the rest, all is fine for me. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
> You said that image history will be a QString. I think that we wil > format XML data directly in digiKam. It's definitively a wrong way. > You must delegate this point to libkexiv2/Exiv2 > > Indeep, in digiKam core, the image history will be something like a > QMap container, used to discribe : > > - the image revision. > - the tool used to change image. > - the tool settings. We are indeed using XML formatted directly in digikam. The purpose of this XML creation is not primarly for storing this in the metadata, but rather as a specified format that can describe the changes, slightly inspired by OpenRaster's XML. We can add attributes to all nodes and extend it in the future. The XML will also be used in other places, and it's a bit more complex than a simple map, which would be too limiting. We will also store the XML in the database. So far I did not think about the implication that XMP is also based on XML, and we now have the purpose of storing XML in XML. Hm. So we either really store it as a string, or we try to integrate it into XMP. Is XMP flexible enough to carry a custom chunk of xml? Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2010/6/11 Marcel Wiesweg <[hidden email]>:
> >> You said that image history will be a QString. I think that we wil >> format XML data directly in digiKam. It's definitively a wrong way. >> You must delegate this point to libkexiv2/Exiv2 >> >> Indeep, in digiKam core, the image history will be something like a >> QMap container, used to discribe : >> >> - the image revision. >> - the tool used to change image. >> - the tool settings. > > We are indeed using XML formatted directly in digikam. The purpose of this XML > creation is not primarly for storing this in the metadata, but rather as a > specified format that can describe the changes, slightly inspired by > OpenRaster's XML. We can add attributes to all nodes and extend it in the > future. > The XML will also be used in other places, and it's a bit more complex than a > simple map, which would be too limiting. We will also store the XML in the > database. > > So far I did not think about the implication that XMP is also based on XML, > and we now have the purpose of storing XML in XML. Hm. > So we either really store it as a string, or we try to integrate it into XMP. > Is XMP flexible enough to carry a custom chunk of xml? This is a good question to ask to Andreas. But i remember some problem to experiment something like this in the past with XML and XMP. I recommend to take a care about. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
> > We are indeed using XML formatted directly in digikam. The purpose of this > XML creation is not primarly for storing this in the metadata, but rather > as a specified format that can describe the changes, slightly inspired by > OpenRaster's XML. We can add attributes to all nodes and extend it in the > future. > The XML will also be used in other places, and it's a bit more complex than > a simple map, which would be too limiting. We will also store the XML in > the database. Some example XML (specs not fixed yet, just to give an idea): <history> <file type="raw"> <filename>pict1234.nef</filename> <originaluuid>asdf-1234-ghjk-5678-tzui</originaluuid> <creationdate>2010-05-05.16:23:56</creationdate> </file> <filter name="digikam:rawimport" version=1 category="reproducible"> <description>"Manual Raw import"</description> <param name="interpolationMethod">Bilinear</param> ... // many more params </filter> <file type="intermediate"> <filename>pict1234-1.jpg</filename> <fileuuid>ertz-3456-sdfg-1234-fghj</fileuuid> </file> <filter name="digikam:crop" version=1 category="reproducible"> <param name="rect" x="10" y="10" width="90" height="40" /> </filter> <file type="current"> <filename>pict1234.jpg</filename> <fileuuid>dfgh-4567-2345-rtzu</fileuuid> </file> </history> _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Andreas,
for the GSoc project about non-destructive image editing we have come up with an XML format in which we would like to store the image history. Now thinking about storing this in metadata, we have crossed the problem of storing XML in XMP's XML. Alternatively, the structure could be inserted directly in XMP, but it is not easily mapped to a single list or map, so using bag or other XMP structures appears not easy. For reference, see some example XML at the bottom of this mail. What is the best way to put this into metadata? Thanks, Marcel > > We are indeed using XML formatted directly in digikam. The purpose of this > XML creation is not primarly for storing this in the metadata, but rather > as a specified format that can describe the changes, slightly inspired by > OpenRaster's XML. We can add attributes to all nodes and extend it in the > future. > The XML will also be used in other places, and it's a bit more complex than > a simple map, which would be too limiting. We will also store the XML in > the database. > > So far I did not think about the implication that XMP is also based on XML, > and we now have the purpose of storing XML in XML. Hm. > So we either really store it as a string, or we try to integrate it into > XMP. Is XMP flexible enough to carry a custom chunk of xml? history> <file type="raw"> <filename>pict1234.nef</filename> <originaluuid>asdf-1234-ghjk-5678-tzui</originaluuid> <creationdate>2010-05-05.16:23:56</creationdate> </file> <filter name="digikam:rawimport" version=1 category="reproducible"> <description>"Manual Raw import"</description> <param name="interpolationMethod">Bilinear</param> ... // many more params </filter> <file type="intermediate"> <filename>pict1234-1.jpg</filename> <fileuuid>ertz-3456-sdfg-1234-fghj</fileuuid> </file> <filter name="digikam:crop" version=1 category="reproducible"> <param name="rect" x="10" y="10" width="90" height="40" /> </filter> <file type="current"> <filename>pict1234.jpg</filename> <fileuuid>dfgh-4567-2345-rtzu</fileuuid> </file> </history> _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Aditya Bhatt
> If someone is going to show how Image metadata is handled in digiKam, I > want to learn this too. Will be very useful to me for later work. All of the hard work is done for us by libexiv2. We have written a wrapper around that, libkexiv2, so you usually dont come in touch with exiv2's API at all. Have a look at the API documentation in libkexiv2/kexiv2.h. The API has grown over the years and there are many different methods, but it's all right. There are three similar groups of methods to read and write Exif, IPTC and XMP metadata. Additionally, there are some "meta" methods that read multiple keys for any of these three, like comment or rating. We use keys defined by exiv2 to identify the metadata to be read or written, the reference can be found on exiv2.org: http://www.exiv2.org/tags.html In digikam, we have the class DMetadata (derived from and extending the KExiv2 class), which you should use each time you read or edit metadata. You can open a DMetadata object from a filename and save to a given filename. Alternatively, when an image is loaded into a DImg, the metadata will be available in memory in the opaque KExiv2Data container, which you can also edit with DMetadata. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
Hi Marcel,
Technically, I think storing an XML structure in an XMP text field is not a problem, if you don't mind the overhead: First, parse the XMP with exiv2 (which uses the expat XML parser), then separately parse the embedded XML text (potentially using another XML parser). Alternatively, you can look at specifying the image editing history "language" directly in XMP as you said, either within the digiKam schema or in a new schema for this purpose. XMP allows for more than the common basic types; it also supports things like structures, qualifiers and nested types. See here for some examples in an exiv2 context and to get an idea: http://www.exiv2.org/example5.html and the XMP specifications for details: http://www.adobe.com/devnet/xmp/. Of the two options, I would prefer this one. Andreas On Fri, Jun 11, 2010 at 20:01, Marcel Wiesweg <[hidden email]> wrote: > Andreas, > > for the GSoc project about non-destructive image editing we have come up with > an XML format in which we would like to store the image history. > > Now thinking about storing this in metadata, we have crossed the problem of > storing XML in XMP's XML. Alternatively, the structure could be inserted > directly in XMP, but it is not easily mapped to a single list or map, so using > bag or other XMP structures appears not easy. > For reference, see some example XML at the bottom of this mail. > > What is the best way to put this into metadata? > > Thanks, Marcel > > >> >> We are indeed using XML formatted directly in digikam. The purpose of this >> XML creation is not primarly for storing this in the metadata, but rather >> as a specified format that can describe the changes, slightly inspired by >> OpenRaster's XML. We can add attributes to all nodes and extend it in the >> future. >> The XML will also be used in other places, and it's a bit more complex than >> a simple map, which would be too limiting. We will also store the XML in >> the database. >> >> So far I did not think about the implication that XMP is also based on XML, >> and we now have the purpose of storing XML in XML. Hm. >> So we either really store it as a string, or we try to integrate it into >> XMP. Is XMP flexible enough to carry a custom chunk of xml? > > > history> > <file type="raw"> > <filename>pict1234.nef</filename> > <originaluuid>asdf-1234-ghjk-5678-tzui</originaluuid> > <creationdate>2010-05-05.16:23:56</creationdate> > </file> > <filter name="digikam:rawimport" version=1 category="reproducible"> > <description>"Manual Raw import"</description> > <param name="interpolationMethod">Bilinear</param> > ... // many more params > </filter> > <file type="intermediate"> > <filename>pict1234-1.jpg</filename> > <fileuuid>ertz-3456-sdfg-1234-fghj</fileuuid> > </file> > <filter name="digikam:crop" version=1 category="reproducible"> > <param name="rect" x="10" y="10" width="90" height="40" /> > </filter> > <file type="current"> > <filename>pict1234.jpg</filename> > <fileuuid>dfgh-4567-2345-rtzu</fileuuid> > </file> > </history> > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
> Hi Marcel, > > Technically, I think storing an XML structure in an XMP text field is > not a problem, if you don't mind the overhead: First, parse the XMP > with exiv2 (which uses the expat XML parser), then separately parse > the embedded XML text (potentially using another XML parser). Ok Martin. This is getting into details, leading you away from getting the whole system to work. I suggest the following: - add two methods to DMetadata accepting or returning a DImageHistory object. For now, store the XML as a string. For the "better" solution below, I will study the details. We can afterwards decide if we stay with the temporary solution or the more sophisticated approach. - commit your results so far to the gsoc-2010 branch. We are looking forward to your code! - during the next week, with the basic DImageHistory code committed by you, I will start with the database integration. (We need your XML reader/writer in any case for this, regardless how it's stored in metadata) Marcel > > Alternatively, you can look at specifying the image editing history > "language" directly in XMP as you said, either within the digiKam > schema or in a new schema for this purpose. XMP allows for more than > the common basic types; it also supports things like structures, > qualifiers and nested types. See here for some examples in an exiv2 > context and to get an idea: http://www.exiv2.org/example5.html and the > XMP specifications for details: http://www.adobe.com/devnet/xmp/. Of > the two options, I would prefer this one. > > Andreas > Andreas, > > for the GSoc project about non-destructive image editing we have come up > with an XML format in which we would like to store the image history. > > Now thinking about storing this in metadata, we have crossed the problem of > storing XML in XMP's XML. Alternatively, the structure could be inserted > directly in XMP, but it is not easily mapped to a single list or map, so > using bag or other XMP structures appears not easy. > For reference, see some example XML at the bottom of this mail. > > What is the best way to put this into metadata? Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
On Sun, Jun 13, 2010 at 16:06, Marcel Wiesweg <[hidden email]> wrote:
Ok. - commit your results so far to the gsoc-2010 branch. We are looking forward - during the next week, with the basic DImageHistory code committed by you, I Will do, I just didn't want to commit this class until it's finished, the XML parser when reading the data does some bad things right now, I will fix this tomorrow and right after that I'll commit the code.
Marty _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
