[Gwyddion-users] keeping metadata through all image preparation processes

[Daniil Bratashov]

Nice idea about keeping metadata in all stages of graphics conveyor:
http://libregraphicsworld.org/blog/entry/commons-machinery-you-will-never-forget-collaborators-in-credits-again

Should it be implemented in image storing module of gwyddion?

WBR, Daniil Bratashov.

[David Nečas (Yeti)]

Post by Daniil Bratashov
http://libregraphicsworld.org/blog/entry/commons-machinery-you-will-never-forget-collaborators-in-credits-again
Should it be implemented in image storing module of gwyddion?

This thing is clearly meant for art. While you can put the name of
whoever exported the presentational image in the file as Creator, you
will more likely want to acknowledge whoever did the measurement. But
the identity of this person is already lost if you don't remember it
yourself (though we may get some kind of operator id from a few file
types) and, more importantly, he is not a creator/author/whatever you
call it. The entire concept is woefully inadequate for things that are
not works of art but objective data that were measured, calculated, ...
There are lots of grey and controversial areas and I don't want to
introduce any frameworks leading to formalisation of rubbish authorship.

Well, I don't want to introduce anything that looks like preparation of
ground for DRM in general. It doesn't matter it is not intended for
enforcement. If it takes off it will be (ab)used for enforcement –
without any regard to fair use or common sense as usual.

Which takes me to whether it will take off. I doubt. But then, I'm
always sceptical regarding visionary plans to solve all the non-existent
problems of this world by a piece of XML. In any case, at this moment
there is zero [released] creative software supporting it. There is no
reason for Gwyddion, which is not a creative software, to be the first.
We can wait 10 years and then check the progress...

Regards,

Yeti

[Daniil Bratashov]

On Tue, 31 Dec 2013 14:06:01 +0100

Post by David Nečas (Yeti)
This thing is clearly meant for art. While you can put the name of
whoever exported the presentational image in the file as Creator, you
will more likely want to acknowledge whoever did the measurement.

No, the main idea not to store creator name, but to add some more
meaningful information inside the images, mainly scan metadata, so one
can simply take the image from report and got all the parameters how
this image was taken and how it was processed from raw data, maybe raw
data filename and scan name also. I'll rather prefer to find scan
file name and scan number from gimp menu, than from dusty logbook.

WBR, Daniil Bratashov.

[Jérôme Borme]

Hello,

I do not say this new initiative is the right way to implement it, but
it surely would be nice to have a way to keep track of some metadata For
example WSxM keeps track of the operations performed by appending to the
titlebar of each window, the name of the processes that were applied to
the data showed in that window. You get a title like:

channel_1:flatten:drift_correction:FFT:...

It's far from perfect (numerical parameters are lost) but the idea is
useful. Regarding the measurement metadata, if you give meaningful names
to the exported files, then you can always find again the original file
and open it in Gwyddion to read the metadata. However I do not know a
way in Gwyddion to remember the operations that lead to a particular
image export (did I apply some polynomial background correction or just
a plane fit on this image I now want to show at a conference?), and I
think it would be nice to find a way to keep track of some relevant
information (the name and folder of the orginal file, and the name of
the transforming operations applied).

Regards,
Jérôme Borme

Post by Daniil Bratashov
On Tue, 31 Dec 2013 14:06:01 +0100

Post by David Nečas (Yeti)
This thing is clearly meant for art. While you can put the name of
whoever exported the presentational image in the file as Creator, you
will more likely want to acknowledge whoever did the measurement.

No, the main idea not to store creator name, but to add some more
meaningful information inside the images, mainly scan metadata, so one
can simply take the image from report and got all the parameters how
this image was taken and how it was processed from raw data, maybe raw
data filename and scan name also. I'll rather prefer to find scan
file name and scan number from gimp menu, than from dusty logbook.
WBR, Daniil Bratashov.

[David Nečas (Yeti)]

Post by Jérôme Borme
I do not say this new initiative is the right way to implement it, but
it surely would be nice to have a way to keep track of some metadata For
example WSxM keeps track of the operations performed by appending to the
titlebar of each window, the name of the processes that were applied to
channel_1:flatten:drift_correction:FFT:...
It's far from perfect (numerical parameters are lost) but the idea is
useful.

This could be certainly useful. I would not put the operation sequence
to the title but to some new kind of metainformation (log).

AFAICT it can't be done automagically, without adding explicit support
to each data processing module, because the data flow is not derivable
from outside. But it can be probably be done so that the amount of code
required in modules to support this is pretty minimal – a couple of
lines per module. At least if we keep the chain linear and give up on
representation of Arithmetic or Mark With. And solve the interaction
with undo.

The log can then include also the current module parameters (essentially
a subset of ~/.gwyddion/settings). I suspect the next request would be
to make these logs replayable though, and this way lies peril. I can
imagine about three hundred ways it will break if we ever try to
implement it... Some people took this concept to the extreme and
generally always try to keep input data and to reply the operations (see
e.g. GEGL and non-destructive editing) but this requires a different
approach to, well, pretty much everything.

Regards,

Yeti

[Andrés Muñiz Piniella]

Post by David Nečas (Yeti)

Post by Jérôme Borme
I do not say this new initiative is the right way to implement it,

but

Post by Jérôme Borme
it surely would be nice to have a way to keep track of some metadata

For

Post by Jérôme Borme
example WSxM keeps track of the operations performed by appending to

the

Post by Jérôme Borme
titlebar of each window, the name of the processes that were applied

to

Post by Jérôme Borme
channel_1:flatten:drift_correction:FFT:...
It's far from perfect (numerical parameters are lost) but the idea is
useful.

This could be certainly useful. I would not put the operation sequence
to the title but to some new kind of metainformation (log).
AFAICT it can't be done automagically, without adding explicit support
to each data processing module, because the data flow is not derivable
from outside. But it can be probably be done so that the amount of code
required in modules to support this is pretty minimal – a couple of
lines per module. At least if we keep the chain linear and give up on
representation of Arithmetic or Mark With. And solve the interaction
with undo.
The log can then include also the current module parameters
(essentially
a subset of ~/.gwyddion/settings). I suspect the next request would be
to make these logs replayable though, and this way lies peril. I can
imagine about three hundred ways it will break if we ever try to
implement it... Some people took this concept to the extreme and
generally always try to keep input data and to reply the operations (see
e.g. GEGL and non-destructive editing) but this requires a different
approach to, well, pretty much everything.

I would not do the replayable bit. Just log what was done: that way if I ask someone to do some data analisys I'd be able to see how they got there. Or if I do It I can see how I did it 9 months down the line. I'd even log the undos.

[David Nečas (Yeti)]

Post by David Nečas (Yeti)
This could be certainly useful. I would not put the operation sequence
to the title but to some new kind of metainformation (log).

I started an implementation, so I'm moving further discussion to the
devel mailing list.

Yeti

[David Nečas (Yeti)]

Post by David Nečas (Yeti)
I started an implementation, so I'm moving further discussion to the
devel mailing list.

The logging implementation should be finished (sort of) now. So if you
are willing to use nightly snapshots, please test them. The user guide
already contains some documentation, see

http://gwyddion.net/documentation/user-guide-en/logging.html

Regards,

Yeti