Log file with each acquisition.

[iandobbie]

We should dump a text logfile detailing information about each acquired image file. Softworx does this and it is extremely useful. Filename should be as the image file but with .log extension.

[carandraug]

Instead of just a log file that is difficult to parse automatically, a more interesting solution would be to dump a ome xml file. This would also solve the limits we have on the standard mrc base header.

An even more interesting approach, is to store such ome xml file in the extended header.

[iandobbie]

Carnë Draug notifications@github.com writes:

Instead of just a log file that is difficult to parse automatically, a
more interesting solution would be to dump a ome xml file. This would
also solve the limits we have on the standard mrc base header.

The log is for humans, software should read the image file metadata. I
hate XML log type files because they are so awkward for a human to
parse.

An even more interesting approach, is to store such ome xml file in
the extended header.

Good idea, this solves the software version but it is also nice to have
a readable log with descriptive data.

Ian

[carandraug]

Ian Dobbie notifications@github.com writes:

Carnë Draug notifications@github.com writes:

Instead of just a log file that is difficult to parse automatically, a
more interesting solution would be to dump a ome xml file. This would
also solve the limits we have on the standard mrc base header.

The log is for humans, software should read the image file metadata. I
hate XML log type files because they are so awkward for a human to
parse.

That's because a human shouldn't be parsing it. An application should
be reading and displaying it in a human readable form. For example,
html. You can read it on a pager but you probably should be using a
web browser. Same for a svg file which is actually a xml.

Just like you can get details from a png or jpeg, you don't need a separate
log in a text file, we should be able to do the same for mrc files. Our
needs a bit more scientific than the information in a typical jpeg. Still,
there is bioformats command line tools showinf which prints the metadata
to stdout (but that also opens a quick display of the image).

I think having to use something specific to get that information instead
of just a pager beats having to keep a pair of files together all the time.

An even more interesting approach, is to store such ome xml file in
the extended header.

Good idea, this solves the software version but it is also nice to have
a readable log with descriptive data.

[juliomateoslangerak]

Hi,

I do agree with Ian on the practical side of the log file. On my experience, on the OMX I find users and my self reading the log file very often. The usual scenario is you find your good image, open the corresponding log file and check settings, to compare, apply, etc.

We use OMERO to store the images, and it does not show all the necessary acquisition parameters. We just click in companion file and view. Boom. You get all relevant information.

I do agree that all this information should be stored in a structured way in the image file, but I do not see the conflict in duplicating thsi info in a xml header AND in a log file…

Cheers, Julio

[carandraug]

I do agree that all this information should be stored in a structured way in the image file, but I do not see the conflict in duplicating thsi info in a xml header AND in a log file…

Because if you have the data duplicated, then you need to worry about keeping
them in sync. You can't automate keeping them in sync because the log files
are not machine readable. And if you accept that it's ok to have them out
of sync, because you know which one will always be right, then you don't need
the other in the first place.

[iandobbie]

Also needs to store laser powers and camera acquisition parameters, Pointed out by Cvic and Sebastian today.