vnlog output for mtf_mapper

[dima]

Hi. This is a proposal. Currently mtf_mapper produces .txt files containing tables of numbers, with comments. The comments are for human consumption. With a small tweak, these data files can be consumable by computers too. The vnlog project (https://github.com/dkogan/vnlog/) provides a set of tools to manipulate such data and the feedgnuplot project (https://github.com/dkogan/feedgnuplot/) allows you to make plots. Both of these are powerful, but also very quick to learn. I wrote both, but there are many other users, they're in Debian, etc.

I patched mtfmapper to produce these files (patch attached in the follow-up post). Then I ran mtf_mapper, and produced the annotated MTF plot from the output:

$ f=frame00104-cam0.png

$ mtf_mapper -v 2 -q -t 0.45 -a --esf-sampler quadratic $f .

$ < edge_mtf_values.vnl \
    vnl-filter -p 'edge_[xy]',mtf50='sprintf("%.2f",mtf50)' \
  | feedgnuplot \
      --tuplesizeall 3 \
      --domain \
      --with 'labels textcolor "blue"' \
      --image $f \
      --square \
      --hardcopy /tmp/annotated-nocolor.png

The result is attached. For simplicity, this doesn't do the color-coding. I did that too, but that's for the other thread. Would you consider merging this? I'm going to be doing all my analysis off this data, and it's a tiny patch with little downside.

[dima]

Here's the patch. Changes all existing comments to use ##, and adds a single # comment for the field labels. vnlog uses the first # comment for the field labels, so moving the # comment to the start will allow the remaining comments to stay unchanged.

[Frans van den Bergh]

Ok, I think the changes so the contents of the files are fine, but changing the extension of the output files in a blanket approach will break things for other users (I assume).

Can we make this entire patch an optional command-line flag? That will maximise backwards compatibility?

I have attached a proposed patch. If this works for you, I can merge it.

[dima]

Hi. Thanks for looking at this. I think a separate --vnlog option is maybe overkill. Would you be adding this just for me, or do you anticipate youself or others using it? I think there's a clear use case: I was able to produce MTF results from multiple images together using this tooling (in the wide-angle post) with zero work. Other simpler options:

1. No changes at all. Instead of

< edge_mtf_values.vnl | vnl-filter -p ...

I could say

{ echo "# block_id edge_x edge_y mtf50 corner_x corner_y cnr_mean oversampling_factor edge_length";
  < edge_mtf_values.txt } | vnl-filter -p ...

That's more work, but works just fine. If we think this is a useful capability to have, maybe requiring the extra work isn't great.

1. A tiny 3-line patch that only adds the headers the the output files (attached). This works:

< edge_mtf_values.txt | vnl-filter -p ...

The downsides are that it isn't obvious to the user that the .txt file is usable with the vnl tools. And the files themselves are a bit visually unclear: there are many # comments, and you would need to know that the first one is the one that is used. But it's a tiny patch, and presumably the old tools would keep working.

I'm surely ok with adding a --vnlog, but do you want such a proliferation of options in your program?

If we do end up with a separate --vnlog, then we effectively have a new format. And in that case, can I make another request? Can we join edge_mtf_values and edge_sfr_values into a single table? In the data processing in the other post I had to merge these together (with vnl-paste) to get enough data to construct the resulting plots, so it makes sense to generate a pre-merged data file. And if we do THAT, can we make a column for mtf10, mtf20, mtf30, ..., mtf90? If that was available, that table alone could be used to make lensprofile plots. I can send you a patch, if you let me know what direction you prefer.

Thanks

[Frans van den Bergh]

I'm fine with adding the command line flag, MTF Mapper already has so many of them :)

The combined data you are looking for is already available in the serialized_edges.bin file. This file was originally intended for more efficient passing of data between the MTF Mapper command line tool and the GUI, but I have since found many more uses for it, e.g., this Python/Docker tool. The binary format is many times more efficient than parsing the text files, and provides fields not covered by edge_sfr or edge_mtf such as the chromatic aberration data. It also addresses another oversight in the edge_sfr format: the actual spatial frequencies are listed explicitly. This makes it much more useful for extracting and SFR-derived values like MTF20.

This binary format is undocumented, though, and it does not have an explicit field for storing the format version, which will likely become important going forward.

So that leaves us a few options:

1. I'm happy to merge the full --vnlog functionality as shown in the patch I posted here. It's a small enough change that does not affect backwards compatility.
2. For more involved merging of data, I would prefer to formalize and document the serialized_edges.bin format. I'd much rather do that than merge the edge_sfr and edge_mtf text formats.

What are your thoughts on this?

[dima]

Hi. I'm a lot less excited about relying on serialized_edges.bin. Some of the
nice things you get from vnl data is

• The ability to use the output directly on the commandline, without needing to
  write any code

• The format is self-documenting

• The format is future-proof: you can add or reorder columns, and existing
  tooling will continue to work

• You can stream it. You can imagine an "mtfmapper server" where mtfmapper reads
  images on stdin, and writes its output as a vnl on stdout. This would be easy
  to implement, and would be a straightforward way to get mtf results to child
  programs, without weird stuff like inotify watchers and such. I can implement
  a prototype, if you want.

So I'll happily take any vnl support you're willing to implement, preferably
with lots of stuff in a single file.

By the way, I also wrote tools for realtime camera focusing and such:

https://github.com/dkogan/mrcam

This uses aravis, so all genicam machine vision cameras are supported (no pylon
or spinnaker needed) and v4l2 also. Currently mrcam-focus uses a plain laplacian
as a measure of sharpness, but integrating mtf into it would be great too.