#1275 closed enhancement (fixed)

conversion code should be refactored

Reported by: dmisev Owned by:
Priority: major Milestone: 10.0
Component: conversion Version: development
Keywords: Cc: pbaumann, vmerticariu, mdumitru
Complexity: Medium

Description (last modified by dmisev)

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

Change History (9)

comment:1 Changed 14 months ago by pbaumann

  • 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

comment:2 Changed 12 months ago by dmisev

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.

comment:3 follow-up: Changed 12 months ago by dmisev

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

comment:4 in reply to: ↑ 3 Changed 12 months ago by dmisev

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

comment:5 Changed 12 months ago by dmisev

  • Description modified (diff)

comment:6 Changed 12 months ago by pbaumann

correct, this was a DEM format specifically requested by an agency earlier. It seems to be used by some, so let us only remove it if DEM can do exactly the same (ie, 16-bit int).

comment:7 Changed 12 months ago by pbaumann

altogether, a good move which hopefully makes life easier in future.

comment:8 Changed 11 months ago by dmisev

I've aliased png, jpeg and bmp to GDAL, and removed insertppm as it can be completely replaced by rasql and decode. With this we remove the libpng, libjpeg, and netpbm dependencies.

I can't decide yet about tiff, our implementation seems faster than GDAL, for RGB especially up to 50% faster.

comment:9 Changed 11 months ago by dmisev

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.