Neaspec readers

[borondics]

We seem to have duplicate code but there might be a reason for it.
Specifically, I am referring to gsf.py and neaspec.py where the functionality of GSFReader and NeaReaderGSF are very close. @stuart-cls, the log says both were made by you on the same day but I think this is due to the refactoring of the directory tree when we moved the readers in separate files. I vaguely remember working on these but no idea why we have two types.

I like GSFReader more because it uses the _spectra_from_image helper that will enforce column naming to map_x and map_y.

However, NeaReaderGSF reads both phase and amplitude values, which are sometimes required for calculations, so I don't just want to delete those and we also need a meta column in future calculations that contains the phase/amplitude information.

My ideal solution would be:
Unify the two classes into one, where the new Orange.data.Table will contain

metas: map_x, map_y, type 
data

The type meta column would contain the phase/amplitude information.

Any suggestions?

[raul-freitas]

The Multifile reader has these 2 formats related to Neaspec:

1. NeaSPEC (*.nea *.txt)
2. NeaSPEC raw files (*.gsf)

*.nea files were the very first format of files, long ago discontinued. The *.txt format in 1) is still active as it reads spectra data saved as *.txt. Finally, the *.gsf reader was dedicated to read single optical channel raw interferograms, however, the company no longer saves them in this format. It is important to highlight that 2) has nothing to do with SPM imaging data.

My suggestion is to merge the new multichannel interferograms reader (*.txt) and a unique flag could distinguish between spectra.txt or interferograms.txt. Remember that only interferograms files have the M column (maybe this could be a flag...).

[ngergihun]

Maybe it would be a good practice to distinguish the readers by adding some hint in the name if it is related to neaspec spectrum or neaspec images. Especially with the GSF readers. As @raul-freitas told, the old NeaSPEC raw files (*.gsf) reader has nothing to do with the images. For sure it can read gsf but for the images, we structure the data after reading differently. Neareader, I agree, it is too common and broad naming. I like, that Raul has put the NeaSPEC multichannel (raw) IFGs as a description, but probably we can also mark these somehow in the name already. NeaReaderMultiChannel even myself would have no idea which type of neaspec data it reads, and imagine a user with no history with neaspec. Can we later figure out some convention? The problem of course arises from the fact that neaspec measurement file has several different structures. I will change our reader name temporarily to NeaImageGSF with DESCRIPTION = 'Single NeaGSF image files' so it is more obvious to the user.