Michaël, Thank you for your kind words about the Tinfour and Gridfour projects. You really made my day.
In terms of whether you can use the Commons Imaging API to access partial sections of a GeoTIFF efficiently, the answer is both yes and no. For example, the source GeoTIFFs used for the land-cover tints were absolutely huge, and there was simply no way to read them completely into memory all at once. Fortunately, Commons Imaging provides logic to permit the specification of a subimage and, just as fortunately, it works pretty efficiently. If you look at lines 151 through 154 of the LandCoverTints.java class (which is also included in the DemoCOG package), you'll see where parameters were specified for reading a sub-image. Now the unfortunate part.... When I wrote the DemoCOG application, I was aiming for simplicity. To avoid the extra complexity of reading the source data a piece at a time, the demonstration code reads the whole thing all at once (at the cost of about 400 megabytes of memory). In a practical application, I would conserve memory by having the application read it a piece at a time. The USGS GeoTIFFs are optimized to support that and the Commons Imaging API does support that function for floating-point data. Unfortunately, just after the alpha-2 release of Commons Imaging went out, I realized I'd made a mistake in my implementation of the floating-point access that wasn't caught by my unit tests. So sometimes the partial-read operations fail. They work great for images, but not so well for floating-point data. The bug is fixed in the current code base (available from Github), but not in the released version of the code. So if you wanted to use the subimage-access logic on floating-point data, you would have to download the latest data and build a jar file from that. Fortunately, the fix will be included in the upcoming alpha-3 release. Incidentally, I am currently working on the ability to read the integer-valued elevation data from the NASA SRTM global elevation GeoTIFFs. And, again, I owe something to the OpenJUMP project because I wasn't aware that the data was available until I saw the discussion on the subject in this mailing list. I'm hoping the Commons Imaging project will be able to include that feature in their next release as well. Gary On Mon, Oct 12, 2020 at 12:41 PM Michaud Michael < m.michael.mich...@orange.fr> wrote: > Gary, > > Thank you for the hint. I've noticed your great work since your first > project released on github, Tinfour, and more recently gridfour. I'm always > excited when I see successful gis opensource contributions in java. > > I'm not the best expert about raster data in openjump team, but I've > already used images converted to cog geotiff (with cogeo) in another > context, to optimize image display in QGIS. > > It is good news to know such capabilities exist in pure java with > commons-imaging. > > My experience was only in a desktop context, so I think QGIS takes > advantage of the presence of subsampled overviews in the file. I don't know > if it can also take advantage of the tiled structure of images to avoid > reading the full file. > > AFAIK, openjump does not take advantage of image overviews, tiled layout > or anything like this, but it would be of great interest. > > I had a very quick look at your DemoCOG example, but I did not see any > specific code to take advantage of overviews or tiled structure. Maybe I > must read it more attentively, or maybe the code is more to demonstrate > metadata/georeferencing reading and elevation data/shaded relief rendering. > > Michaël > > > > *envoyé :* 12 octobre 2020 à 05:28 > *de :* Gary Lucas <gwluca...@gmail.com> > *à :* jump-pilot-devel@lists.sourceforge.net > *objet :* [JPP-Devel] Reading elevation data using Apache Commons Imaging > > I first heard about OpenJUMP last month when one of your users posted a > bug report on the Apache Commons Imaging JIRA system (see > https://issues.apache.org/jira/browse/IMAGING-265). The bug is fixed now > and I am grateful for the folks here who brought it to my attention. > > Anyway, based on that posting, and some of the JPP documentation, I get > the impression that Commons Imaging is used in at least some capacity in > OpenJUMP. So I thought that I would mention another relatively new feature > in the Commons Imaging API: the ability to read floating-point elevation > data from USGS 3DEP Cloud-Optimized GeoTIFF files. This capability was > introduced in the latest release of Commons Imaging > (commons-imaging-1.0-alpha2). I don’t know if it is something the project > can take advantage of, but I thought I would bring it to your attention. > > If you would like more information on the feature, I’ve just posted an > article and some sample code showing how to use the API for creating > shaded-relief imagery. While OpenJUMP already has its own shaded-relief > capability through its Sextante plugin, I think that the article might be > of interest to folks on this mailing list because it provides background on > the USGS GeoTIFF files as well as discussing the algorithms for > shaded-relief rendering. If you are interested, you may access it at > > https://gwlucastrig.github.io/gridfour/notes/ElevationGeoTiff1.html > > Thanks, and good luck on the JUMP Pilot Project. It is an impressive > project and I look forward to studying it further. > > Gary > > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
