Custom format reader - adding metadata


I am currently investigating different possibilities of implementing custom formats in ij2.

Some context:
While the image data originally can come from different file types, my plugins will do some registration and finally needs to store additional data containing the transforms. So in order to not save the pixel data again, I would like to have some xml-based file format containing the transformation data, or containing a serialised transformation object.

I am looking for a possibility to implement a custom format, having the following UI functionality:

  • usable via the File > Save As and File > Import menu
  • open a file via drag and drop

For instance if I open a transform-file, what should happen is that a image file with the corresponding file name but different extension should be loaded, then additionally the mapping information will be read from the files containing some transformation. Finally the pixel data and the transformation data will be contained in an object extending DefaultDataset.

As far as I can see the AbstractFormat is tailored for image file containing pixel data and metadata. So I do not see how extending this will give me an xml-based transformation file reader.

Any pointers of how best to use scifio to solve this would be very much appreciated.


Hi @FelixM,

Have a look at this tutorial I wrote for SCIFIO: Or check out these file formats I added: Kontron, ISQ or StratecPQCT (they only support reading these files though).

AFAIK, you would have to come up with your own way how to display this metadata to the user. For example, the image info dialog in the legacy UI isn’t automatically populated by SCIFIO metadata. To access in your code call

final String source = "/my//file/";
final Format f = new ImageJ().scifio().format().getFormat(source);
final Metadata m = f.createParser().parse(source);

Best regards,

NB The format tutorial might not be 100 % up-to-date since SCIFIO is still experimental software


Dear @rimadoma

thanks for the pointers.

What I am unsure is if the additional transformation data should be written in the image file. To keep things simple and interoperable, I think putting the additional data in a second meta-data file is maybe not the cleanest, but probably the more versatile solution.

However from the examples you referenced, I already had a look at some of them. But it is unclear to me how I would combine in there a standard tiff reader/writer with an additional xml-writer using a scifio-Format.
The interesting thing about the scifio plugin mechanism to me is the integration in the ij menus and the drag and drop capability, not putting the metadata in the image file header.

This is my first attempt to write a nicely integrated io plugin of ij2, so I am unsure if this would be currently the correct way to go about this.

1 Like

I see, I guess you in your implementation of Parser.typedParser() you could try to open your addiotional metadata file. Depending on whether this additional info is crucial, you could throw an IOException from the method if reading fails.

The class ExportHeader in the pQCT plug-ins does something similar to what you’re looking for. It tries to read an additional .typ file associated with different kinds of Stratec devices, which create pQCT files. However in this case, these additional metadata files are Java resources. The code is also wholly in ImageJ1 world, but maybe it can give you ideas on how to implement your fileformat.

Best regards,

Another idea is just to have n bytes allocated in your standard file format header for possible additional meta data. This is how many existing file formats handle to the problem. before the additional metadata block, you could have a leading byte or bytes that tell you how many bytes of additional metadata there actually is. The rest would just be zeroes.

Hi @rimadoma

after some back and forth, I think I will go with simple plugin implementations for now, a bit like the example you mentioned:

With this I can get most of the functionality I need, creating additional files for the metadata. Maybe not the cleanest way, but the more versatile.
Concerning the drag and drop functionality I will play around with scijava.ui.dnd… see where DragAndDropData and _ AbstractDragAndDropHandler_ take me.

I will leave the FileFormats for another day, when I will really need them. I also admit that I am a bit confused about the file-file-formats thing and weather it makes sense to implement one if there is only additional metadata.

Thanks for the pointers @rimadoma.

1 Like