Use csv file as raster file and stitch them together

Question

I'm having an issue trying to stitch together 100 32bit Tiff files (coming from thermal imagery video and extracted as 32bit Tiff).

I used Hugin to mosaic the pictures extracted from the video which give good result but has the bad habits to distort the finale stripes.

I can as well extract as CSV, the file is then a matrix of 640 columns and 480 lines of temperature value. I was wondering if there is anyway to stitch those csv together in a way to obtain a no distorted finale file using R by exemple.

Is a script could be able to say ok I recognize this combination of value in those two csv and I can stitch them together.

We considered some structure from motion software to do this work but they usually don't handle the 32bit Tiff.

It is a bit unusual question but the development of UAV technology will lead to the multiplication of data as movie that will need to be transfer in GIS application so it might be interesting to find a solution.

Answer 1

I suspect that Hugin is trying to treat the video images as a panoramic view, hence the distortion. I assume that your images are not georeferenced otherwise I would recommend using GIS mosaic tools in preference to Hugin (although that is a good piece of software).

I don't know of any off-the-shelf script to do what you are asking for CSV files. I think you would have to write one yourself.

However, here's a slightly unconventional idea that might work: Even if the images are not georeferenced, if you know the frame-rate of the video and travel speed of the camera (or some other information about the overlap - perhaps even Hugin can tell you that for each frame - I think it might be able to but I don't use it enough to be certain) you could fairly easily write a script to generate a set of fake world files for your images and then use conventional GIS raster mosaic tools. This gets complicated if you cannot guarantee a steady speed or path for the camera but, if there are good metrics for the pass from which the imagery comes from, that too can be solved - though having Hugin tell you the offsets for each from (if it can) would be a whole lot simpler as that helps automate the process.

This is just a suggestion as you've had no answers and perhaps somebody has a better solution.

EDIT: Hugin is OpenSource so, if it won't give you the overlap data directly, perhaps you or a friendly programmer could hack it to spit that information out for you.

EDIT #2: I just checked my copy of Hugin and, of course, it provides the control-point data for you. So from this you should be able to calculate offsets to fake your world files. So perhaps my suggestion is not so "off-the-wall" after all. Here's the work flow: Use Hugin to calculate the overlap but don't use the mosaic decause of the unwanted distortions in the final result that you've experienced. Generate a set of fake world-files from the control-point data Hugin provides and then switch to conventional GIS mosaicing (R has one I think, as does GRASS, GDAL, SAGA etc if you're looking for something free).

EDIT #3 (more detail on faking the world files):
A world file is a simple text file defined as follows:
Line 1: pixel size in the x-direction in map units/pixel
Line 2: rotation about y-axis
Line 3: rotation about x-axis
Line 4: pixel size in the y-direction in map units, almost always negative[3]
Line 5: x-coordinate of the center of the upper left pixel
Line 6: y-coordinate of the center of the upper left pixel

We want all the images from the video to be positioned relative to each other. We don't need to know anything about their actual position in the real world and nor do we know anything about the scale but as long as we are always talking in relative terms, that doesn't matter here.

Let's say that your images are 512 pixels square for the sake of argument. The first image will have a world file something like this:

1
0
0
-1
0
512

Now let's say that the control points tell us that the next image is offset by 123 pixels to the right and 3 pixels up, relative to the first one. It then has a world file something like this:

1
0
0
-1
123
515

Obviously the control points can tell you something about any rotational component too but I've left that out for simplicity here.