Add direct support for image data into GVRS API

[gwlucastrig]

Discussed in #12

^{Originally posted by gwlucastrig December 9, 2021}

I propose to extend the GVRS API to provide direct support for imagery (aerial photographs, conventional pictures, etc.). To do so, the API would be expanded to include a new GvrsElement class customized for the representation for pixel data. I am considering on of the following two class names (please indicate if you have a preference):

• GvrsElementPixel
• GvrsElementRGB

Background
The GVRS file format and Java API is intended to simplify the processing of large raster data sets. One of the ideas behind GVRS is that an application can use it for high-speed processing of large data sets and then export the results to whatever data format is best suited for a user’s needs.

Currently, GVRS focuses on numerical information. Of course, there is another kind of raster information that a lot of people care about: images. I was wondering what everyone thought about implementing some sort of support for image formats in GVRS.

When I designed GVRS, I did not consider image data as being something for which GVRS could provide much “value added”. There are plenty of good graphics formats and supporting APIs out there already. Recently, however, I’ve been playing with some sample data that includes both aerial photographs and surface elevation samples. This effort involves working with two disjoint data products using separate APIs and two separate sets of data objects. It occurs to me that having limited built-in support for imagery might be a more convenient way to work. It might be an attractive feature for some users.

I spent a few evenings going through the PNG and TIFF format specifications, and have also taken a look at a less well-known format known as NITF. Image-processing is an important topic and these products all feature more complexity than might be obvious at first glance. For GVRS, I would deliberately focus on a narrow subset of these features. I list some basic features below. I will consider more advanced features such as CMYK and CIELAB color spaces, or ICC profiles. Doing so would depend on users identifying features that had the most utility and were of the highest priority. Image processing is a vast topic and it would be easy to spend a lot of time adding specialized features only to come up with a complex implementation that nobody wanted to use. I'd like to avoid that.

[gwlucastrig]

I posted an article describing my preliminary investigation into processing images using the GVRS API. You can view it at An Investigation using GVRS for Image Processing, Storage, and Data Compression

I am particularly interested in any suggestions for requirements, any insights, or any ideas that potential users may have.

[gwlucastrig]

I am considering the creation of a package named org.gridfour.imaging to handle image-related code. Although Gridfour is not an image-processing project, the ability to create image products is an important tool in the analysis of raster data products. Sp the proposed imaging package would mainly consist of support classes for the primary raster processing tools.

That being said.... I love working on image-processing problems. So I rule out nothing when it comes to future work in that area.