Bug Hunting Session
Bug 119563 (Media-Metadata) - When importing media (eg images) to libreoffice it would be friendly to save some metadata
Summary: When importing media (eg images) to libreoffice it would be friendly to save ...
Status: NEW
Alias: Media-Metadata
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Images
  Show dependency treegraph
 
Reported: 2018-08-28 12:34 UTC by ffs
Modified: 2019-03-11 12:31 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Document properties in inkscape (40.31 KB, image/png)
2019-03-11 12:31 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ffs 2018-08-28 12:34:13 UTC
Description:
When importing an image it would be friendly to save some metadata.

The most important of this would be the original file name.  I've lost count of the number of times I've extracted an image from LO to reuse wishing that when I saved it I knew the original file name (so I could simply go find the original). It would also be really useful to get this metadat in some kind of "properties" dialogue.

Steps to Reproduce:
Import a file (image etc)
Save the file or try to find the original file details - they are gone

Actual Results:
Import a file (image etc)
Save the file or try to find the original file details - they are gone

Expected Results:
Saved the metadata:
filename:  xxx.jpg
path: /home/fred/bloggs/images/
date import: 12 Feb 1956


Reproducible: Always


User Profile Reset: No



Additional Info:
I realise that all this info won't always be there but most can be stashed in the image format's metadata headers so it should be possible.

For privacy some people would probably like to clear this.
Comment 1 Buovjaga 2018-09-23 13:31:41 UTC
Adding UX to the conversation as especially the privacy aspect needs some consideration.
Comment 2 Heiko Tietze 2018-09-23 16:18:55 UTC
Some info might be useful and is shown anyway with the image. Following [1] interoperability keywords are

* keywords
* description
* date and time*
* orientation
* rating
* copyright*
* creator*
* location created
* location shown 

where those with asterisks seems most important to me (exif [2] has much more info) plus file name, which is not part of the digital still image meta data but in the more general definition [3]

* Means of creation of the data
* Purpose of the data
* Time and date of creation*
* Creator or author of the data*
* Location on a computer network where the data was created*
* Standards used
* File size
* Data quality
* Source of the data*
* Process used to create the data

Not an easy topic.

[1] https://en.wikipedia.org/wiki/Metadata_Working_Group
[2] https://en.wikipedia.org/wiki/Exif
[3] https://en.wikipedia.org/wiki/Metadata#Definition
Comment 3 ffs 2018-09-24 07:27:14 UTC
Thanks folks for looking at this:

For me the priority would be filename, path and date - Personally I'm not bothered about the rest but I was surprised that LO doesn't preserve or allow manipulation of this data.

Personally I think that all concerns could be addressed at the point of import:

Import (without metadata)
Import (with metadata)

and an "edit metadata" option for the image.
Comment 4 V Stuart Foote 2018-09-24 14:34:29 UTC
What has OASIS and the ODF TC worked out from past sessions?

Delving too far into Exif or XMP for the benefit of raster images, with no appreciable support for other graphics seems kind of short sighted.

I'd much rather see a fully fleshed out treatment of Dublin Core [1] as the basis for metadata attribute assignment in XML of all objects held in ODF, not just raster images.

Might be doable with XMP. But, I don't think we want the overhead of manipulating Exif/TIFF binary headers for images that we convert and manipulate internally in SVM/BMP anyhow. 

IHMO keeping track of metadata during the image/graphic object lifecycle would be better handled as with the rest of an object's properties and all objects with common methods.

That has benefit of allowing us to "anonymize" the objects attributes when that is preferred/required for privacy.

=-ref-=
[1] https://en.wikipedia.org/wiki/Dublin_Core
Comment 5 Cor Nouws 2019-03-06 19:46:27 UTC
(In reply to ffs from comment #0)
> path: /home/fred/bloggs/images/
> date import: 12 Feb 1956
Please mind!  I don't see these two above here in the various links on meta data :)
Comment 6 Heiko Tietze 2019-03-07 12:00:34 UTC
Regina, has ODF dedicated fields for those information, or a) does it make sense to enhance the format first or b) should we (ab)use some meta tag?

Regarding the actual fields it doesn't matter too much whether it's based on DCMES (c4) or MWG (c2). But we should take care on the actual request (where did I take an image from, locally). Plus, we should not override relevant fields. "Source" might be an option. And for this reason (and for simplicity) I vote against editing the meta data.
Comment 7 Regina Henschel 2019-03-07 13:29:26 UTC
(In reply to Heiko Tietze from comment #6)
> Regina, has ODF dedicated fields for those information, or a) does it make
> sense to enhance the format first or b) should we (ab)use some meta tag?

No, ODF has no hidden additional information for the image itself. The user can put information into the general <svg:desc> element of the containing <draw:frame> element.

It is possible to store information in a <meta:user-defined> element in the <office:meta> element. In the UI those are in File > Properties, tab 'Custom Properties'. The user is free in the name (key) of such property, only that it has to be unique. The content (value) can be arbitrary text. If a user take the image name as key and the URL as value, he can save the information together with the document.

Both suggestion needs explicit actions by the user. I would not do such things automatically. But it sounds like a task for a script, which can be installed as extension.
Comment 8 ffs 2019-03-10 09:00:46 UTC
I would advise (as the OP) that this should be a default feature if LO and not an optional script.  Ideally it would be optional (but by default on) in the insert image dialogue "keep source filename [yes]".  

The reason being is that ideally I'd like this to have been the default the last few years so I can recover the original now - no optional script will allow me to go back in time once I realise this information isn't being stored by default and by the time anyone realises it is too late.

There are reasons not to store this information an to allow it to be opted out, edited or deleted, but for the average users it will be useful.

Personally I'd stick it in the metadata of the image rather than a private LO tag.
Comment 9 Heiko Tietze 2019-03-11 12:31:04 UTC
Created attachment 149879 [details]
Document properties in inkscape

(In reply to ffs from comment #8)
> Personally I'd stick it in the metadata of the image rather than a private
> LO tag.

We need to take care about compatibility, ie. roundtrips of the odf with other tools like OpenOffice, Calligra, with alien formats such as from MSO and when exporting/importing the image as SVG, for example.

As of SVG, Inkscape has some tags shown in the attachment. Those are saved in the metadata

<metadata
     id="metadata5">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title>Test</dc:title>
        <dc:date>11.3.2019</dc:date>
        <dc:creator>
          <cc:Agent>
            <dc:title>HT</dc:title>
          </cc:Agent>
        </dc:creator>
        <dc:rights>
          <cc:Agent>
            <dc:title>CC0</dc:title>
          </cc:Agent>
        </dc:rights>
        <dc:publisher>
          <cc:Agent>
            <dc:title>HT</dc:title>
          </cc:Agent>
        </dc:publisher>
        <dc:identifier>none</dc:identifier>
        <dc:source>self-made</dc:source>
        <dc:language>English</dc:language>
        <dc:subject>
          <rdf:Bag>
            <rdf:li>test</rdf:li>
            <rdf:li>rectangle</rdf:li>
          </rdf:Bag>
        </dc:subject>
        <dc:description>This is a test.</dc:description>
        <dc:contributor>
          <cc:Agent>
            <dc:title>RH</dc:title>
          </cc:Agent>
        </dc:contributor>
        <cc:license
           rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/" />
      </cc:Work>
      <cc:License
         rdf:about="http://creativecommons.org/publicdomain/zero/1.0/">
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#Reproduction" />
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#Distribution" />
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#DerivativeWorks" />
      </cc:License>
    </rdf:RDF>
  </metadata>

Sounds like some work for the developers.