conversion code should be refactored

[Dimitar Misev]

In many cases, existing code in source:conversion can be removed and the corresponding function can be aliased to encode(). With this we can also remove a couple of direct dependencies of rasdaman as they become indirect dependencies via gdal: bmp, jpeg, png, tiff.

These functions can be refactored:

• bmp
• jpeg
• png
• tiff

Stay internal:

• grib
• hdf
• netcdf

Not sure about:

• dem
• ecw (not compiled at the moment)

Removed

• tor (can't find information on a tor format)
• vff (can't find information on a vff format)
• int16 (= dem now, see comment:3, comment:4)

NITF reader (see comment:2):

• ntf.cc is the convertor class using the others; we should keep these sources, NTF should be renamed to NITF, and at some time this should be properly compiled into libconversion and tested.
• nitf.cc
• des.cc
• graphic.cc
• image.cc
• res.cc
• utilities.cc

Furthermore, it would be good to remove the dedicated source:insertutils/insertppm.cc and either have a corresponding ppm/inv_ppm functions or connect to decode/encode(..,"ppm")

See also #1139

[Peter Baumann]

• tor, vff: not existing anymore, can be removed
• ecw: commercial, so cannot be used in rasdaman community anyway
• last series: likely can be removed, except maybe int16
• insertppm: does more, we need to capture extra parameters when doing encode (_,"ppm") which I find a good idea

[Dimitar Misev]

These are all part of a NITF reader, even though currently they are not compiled into libconversion so I doubt it will work:

#include "nitf.h"
#include "image.h"
#include "graphic.h"
#include "text.h"
#include "des.h"
#include "res.h"
#include "utilities.h"

source:conversion/ntf.cc makes an attempt to use nitf.h, just for ingestion as far as I could see. NTF is a bad choice in this case, because it an acronym for an unrelated format: ​https://en.wikipedia.org/wiki/National_Transfer_Format

So we should keep these sources, NTF should be renamed to NITF, and at some time this should be properly compiled into libconversion and tested.

[Dimitar Misev]

source:conversion/int16.hh seems to be some sort of a DEM format? Here's the documentation in the header file:

---

Format specification:
int16

input parameters:

• geox geo reference x of upper left point (float >0)
• geoy geo reference y of upper left point (float >0)
• resx horizontal resolution (pixel distance) in meters (float >0)
• resy vertical resolution (pixel distance) in meters (float >0)
• hstep factor by which pixel values have to be multiplied to obtain real height in meters (float >0)

An int16 file contains a sequence of sizex*sizey height values, advancing from west to east and from north to south.
Each pixel consists of a 16 bit integer where the lower byte comes first in sequence (i.e., pixel value is byte[i]+byte[i+1]*256).
There is no file header, pixels start immediately at the beginning.

Points are defined as follows for pixel position (i,j) in file (starting with (0/0):

• geo position x = geox + i*resx
• geo position y = geoy + j*resy
• height = ( byte[ 2*i + 2*j*sizex] + byte[ 2*i + 2*j*sizex + 1] * 256 ) * hstep

[Dimitar Misev]

Replying to dmisev:

source:conversion/int16.hh seems to be some sort of a DEM format? Here's the documentation in the header file:

Actually replace int16 with DEM and you get the same code as source:conversion/dem.cc. So removing int16