Image history in metadata

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Image history in metadata

Martin Klapetek
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Gilles Caulier-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Martin Klapetek
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?
 

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.
 
Yes, that's how it's done right now.
 

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

Ok, thanks.

Marty

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Gilles Caulier-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Marcel Wiesweg
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Gilles Caulier-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Marcel Wiesweg
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Marcel Wiesweg
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Marcel Wiesweg
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Bugzilla from ahuggel@gmx.net
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Marcel Wiesweg
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
Reply | Threaded
Open this post in threaded view
|

Re: Image history in metadata

Martin Klapetek
On Sun, Jun 13, 2010 at 16:06, Marcel Wiesweg <[hidden email]> wrote:
 
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.

Ok.
 
- 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)
 
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