Gwyddion manages to import .poir files but has issues with the color channel, where is splits the image into 4 channels: RGB plus "LSM INVALID" one. I am not sure exactly what is the last channel - perhaps some intensity from the color sensor? Could they be combined together to form a color image as in the microscope software?
There should be six channels. Three LSM ones, HEIGHT, INTENSITY and INVALID (in some order), plus the three RGB. Prior to version 2.63 mismatches could occur – the import could mix up HEIGHT and INTENSITY for instance – but now the assignment should be always correct.
The names HEIGHT, INTENSITY and INVALID come from the file itself. If the file called a channel MR.BUNNY then Gwyddion would show the channel name as MR.BUNNY. I do not know the interpretation of INVALID. Similar formats often contain an ‘invalid’ channel marking invalid pixels, i.e. where the height could not be determined – but here it is clearly something else. It looks quite like the second derivative, but not exactly. Maybe the channel is not useful; I do not know.
As for the composite colour image from RGB channels, RGB images simply do not exist in Gwyddion. It works with height maps, not colour. We do not want to create GIMP neither we want to confuse people into thinking Gwyddion is something like GIMP.
Since Gwyddion has a mechanism for showing a different image on top of the real data (presentations), a possibility to show a composite image from three channels could perhaps be added. I am worried though that the moment we do this people will start assuming they work with the colour image. And that would be completely wrong. All Gwyddion functions would still work with the underlying data, not the displayed colour image. And people will start asking for all kinds of functions for the colour images… So I just do not like where this rabbit hole leads to.
To summarise, both INVALID and RGB are imported because they are in the file and someone might find them useful for something sometimes. But the general expectation is that they typically will not be useful. In one case because no one knows what it is and in the other because Gwyddion is not a good match for this data type.
Last edit: David Nečas 2023-06-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, I was using 2.62, where the H and I channels were inverted, but I checked with the newest version and they are represented correctly. Good job! The INVALID perhaps is related to the pre-scan of the laser (?) for max laser intensity in order to avoid sensor saturation. During scan, the objective carrousel is moving twice under the laser mode and only once in the visible microscope mode.
I understand that combining the three color channels is not priority for the SPM community since there is no color in their images, but who knows how Gwyddion will evolve in the future ...
One more small issue, which was more evident in the older versions, is the related to the physical dimensions of the images taken in stitching mode. Could you please have a look if there is some correction factor hidden in the .poir which is related to the stitching feature (% overlap)?
There are some pixel size calibration factors in microscopeConfiguration (both very close to 1). Multiplying the sizes with them seems to make the dimension in Gwyddion match the screenshots. So I changed how the dimensions are calculated (r25499). Please try tomorrow's or later development snapshot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gwyddion manages to import .poir files but has issues with the color channel, where is splits the image into 4 channels: RGB plus "LSM INVALID" one. I am not sure exactly what is the last channel - perhaps some intensity from the color sensor? Could they be combined together to form a color image as in the microscope software?
and the .poir file...
and the correct images as seen by Olympus software
There should be six channels. Three LSM ones, HEIGHT, INTENSITY and INVALID (in some order), plus the three RGB. Prior to version 2.63 mismatches could occur – the import could mix up HEIGHT and INTENSITY for instance – but now the assignment should be always correct.
The names HEIGHT, INTENSITY and INVALID come from the file itself. If the file called a channel MR.BUNNY then Gwyddion would show the channel name as MR.BUNNY. I do not know the interpretation of INVALID. Similar formats often contain an ‘invalid’ channel marking invalid pixels, i.e. where the height could not be determined – but here it is clearly something else. It looks quite like the second derivative, but not exactly. Maybe the channel is not useful; I do not know.
As for the composite colour image from RGB channels, RGB images simply do not exist in Gwyddion. It works with height maps, not colour. We do not want to create GIMP neither we want to confuse people into thinking Gwyddion is something like GIMP.
Since Gwyddion has a mechanism for showing a different image on top of the real data (presentations), a possibility to show a composite image from three channels could perhaps be added. I am worried though that the moment we do this people will start assuming they work with the colour image. And that would be completely wrong. All Gwyddion functions would still work with the underlying data, not the displayed colour image. And people will start asking for all kinds of functions for the colour images… So I just do not like where this rabbit hole leads to.
To summarise, both INVALID and RGB are imported because they are in the file and someone might find them useful for something sometimes. But the general expectation is that they typically will not be useful. In one case because no one knows what it is and in the other because Gwyddion is not a good match for this data type.
Last edit: David Nečas 2023-06-26
Thank you David for the reply!
Indeed, I was using 2.62, where the H and I channels were inverted, but I checked with the newest version and they are represented correctly. Good job! The INVALID perhaps is related to the pre-scan of the laser (?) for max laser intensity in order to avoid sensor saturation. During scan, the objective carrousel is moving twice under the laser mode and only once in the visible microscope mode.
I understand that combining the three color channels is not priority for the SPM community since there is no color in their images, but who knows how Gwyddion will evolve in the future ...
One more small issue, which was more evident in the older versions, is the related to the physical dimensions of the images taken in stitching mode. Could you please have a look if there is some correction factor hidden in the .poir which is related to the stitching feature (% overlap)?
There are some pixel size calibration factors in microscopeConfiguration (both very close to 1). Multiplying the sizes with them seems to make the dimension in Gwyddion match the screenshots. So I changed how the dimensions are calculated (r25499). Please try tomorrow's or later development snapshot.
Update: The build server is currently broken. It may take some time until regular nightly snapshots are up again. Sorry.