You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've looked at a handful of .xml metadata files from several different tiles, all of which contain the exact same wavelengths, indicating that the data is probably not usable. As such we turn towards actually doing the color handling directly on the .jp2 files. It seems that these files are on average about 80MB per image meaning that we would have to download and process perhaps 1GB+ data for each request. Is this intended?
Other than this, we've still only managed to work with these images in Go by converting them to JPEG, however external libraries would be needed to do this directly or alternatively use of a webservice, for which we would probably get turned down eventually due to sheer amount of data. Have you found a smarter way to do this?
The text was updated successfully, but these errors were encountered:
I think actually looking at the content of the files is the right way to go.
For this exercise, there are only three bands that are of interest:
Band 2: Blue
Band 3: Green
Band 4: Red
That should reduce the data size quite a bit :-)
The next step would be to create an index, so that you can respond to requests more quickly.
Regarding the jp2 issue, we are looking into it.
Locally, you can use http://www.openjpeg.org/ which is a C library for jpeg2000.
We've looked at a handful of .xml metadata files from several different tiles, all of which contain the exact same wavelengths, indicating that the data is probably not usable. As such we turn towards actually doing the color handling directly on the .jp2 files. It seems that these files are on average about 80MB per image meaning that we would have to download and process perhaps 1GB+ data for each request. Is this intended?
Other than this, we've still only managed to work with these images in Go by converting them to JPEG, however external libraries would be needed to do this directly or alternatively use of a webservice, for which we would probably get turned down eventually due to sheer amount of data. Have you found a smarter way to do this?
The text was updated successfully, but these errors were encountered: