BEAM Development

Installing C API on Windows

2010-09-07T19:28:11Z

Hi, further to my last message about the C API, I'm having some problems installing it on two new Windows machines. One runs Windows 7, the other Windows XP. I'm using MS Visual Studio (C++) on both machines.

I've downloaded the latest version (2.2) of the API from the BEAM website, but I'm not sure where to go from here. How do I create a library, or otherwise let my application know to look for the source code in the right place. Including the /src directory in my project still gives me lots of "unresolved external" errors.

Any good ideas? Best regards,
Anders

RE: Continued support for C (or C++) API

2010-09-07T18:14:00Z

Hi Anders,

this question should be directed to ESA. We maintain and further develop BEAM under ESA contract, i.e. it is an ESA decision if and how BEAM including the C-API will be continued for Sentinel-3. We would be ready and happy to do so, and currently ESA is preparing a maintenance contract for the next few years.

The BEAM toolbox is purely user driven, and as long as there are user requirements for the C-API (and there is, indeed) we will maintain it.

This thread is a good place to express the requirement for the C-API, and any other user reading it should reply and express its need as well.

Carsten

Continued support for C (or C++) API

2010-09-07T14:52:41Z

Hi, I'm using the C API for AATSR data, and I was wondering how large a user community there is of this API. The project I work on is preparing for the launch of the Sentinels, primarily 2 and 3, so it would be great for us if we could also count on there being at least a simple C/C++ API to read and quality check Sentinel 2 and 3 data. If anybody else would also be interested in this, it may be important to let the relevant people know (through this forum), so it ends up being developed.

Cheers,
Anders

RE: PNG, JPG and co...

2010-09-06T13:05:14Z

At least, I've unedrstood the JAI jaavadoc :-p

I will test thiss two tips a bit later. Still writing my final report ^_^

Thanks for your help !

Greetings,

Agemen.

RE: epr_api - View angle interpolation

2010-09-03T06:56:08Z

Hi Owen

Thanks for the report. We will have a look at it and see what we can do.

best wishes
Marco

RE: epr_api - Raster mirroring

2010-09-03T06:53:51Z

Hi Owen

Thanks for the patch! You work is really valuable for us and for other users.
I hope we'll find the time to apply it ASAP.

best wishes
Marco

RE: epr_api - Support ATSR1 / ATSR2 files

2010-09-03T06:50:25Z

Hi Owen

Thanks for the patches! I hope we'll find the time to apply them ASAP. Other users will be thankful.

best wishes
Marco

RE: PNG, JPG and co...

2010-09-03T06:57:25Z

I have two other tips for you.

Maybe it will help if you wrapt the image stream you get from (ImageIO.createImageInputStream(inputFile)) into a FileCacheImageInputStream.

The second tip is that you implement AbstractMultiLevelSource and use it with a DefaultMultiLevelImage. See example below. You can find more examples in our code.

1
2MultiLevelSource mls = new AbstractMultiLevelSource(createMultiLevelModel(product)) {
3    @Override
4    public RenderedImage createImage(int level) {
5       RenderedImage image = // create the image for the given level.
6       return image;
7    }};
8    mli = new DefaultMultiLevelImage(mls);

Unfortunately I have no tip for the tile size problem. we do it the same way as you do in your code.

epr_api - View angle interpolation

2010-09-01T16:29:55Z

Hello,

My last message about the epr_api for now...

The linear interpolation from tie-points to pixel positions can cause artifacts in the relative azimuth data as the variation of azimuth angle is not linear between the tie-points. I don't have a simple fix for this problem as I am currently avoiding it by using my own view angle interpolation outside the epr_api.

There are two cases where the current implementation causes large artifacts. Firstly when the azimuth wraps around from 360 to 0. decode_tiepoint_band in epr_band.c could be modified to avoid this issue with the same fix used for the longitude.

The other problem occurs around the sub-satellite point when the satellite zenith angle is zero (and there is a discontinuity in the satellite azimuth angle). This problem is much harder to fix inside the decode_tiepoint_band routine as you need access to both the azimuth and zenith angles to correctly interpolation between them.

Regards,
Owen

epr_api - Raster mirroring

2010-09-01T16:11:47Z

Hi,

When the epr_api reads AATSR Level 1b data it mirrors the raster data, but it does not mirror the tie-point data. This isn't a problem if you're using epr_api to interpolate the tie-point data to the pixel positions. However, there are cases where you need direct access to the tie-point data. I have simply disabled the line mirroring, but some people may still want the raster data mirrored in which case the tie-point data should be returned in a similar state.

The band_id structure does have a flag to indicate if the lines should be mirrored. But the code in epr_band.c which does the mirroring does not check the flag, and instead duplicates the same logic used to set the flag in the first place. The attached patch simply checks the state of band_id->lines_mirrored to determine if it should be mirroring the data (Note it also disables mirroring for AATSR)

Regards,
Owen

epr_api - Support ATSR1 / ATSR2 files

2010-09-01T15:58:14Z

Hi,

I'm using the epr_api to read AATSR Level-1b and the Envisat format ATSR1 and ATSR2 files from the NEODC Multimission Archive. I had to make a few modifications to epr_api to read the data so I'm posting the set of patches here for review/comment.

There are two problems when loading ATSR1/ATSR2 files. Firstly the product strings are AT1 and AT2 instead of ATS. Rather than duplicating all the record descriptors in epr_dddb.c I have used a quick hack to replace AT1/AT2 string at the start of the product id with ATS.

The second problem is that the ATSR1 and ATSR2 products actually make use of the attachment flag to indicate missing or empty MDS records. As far as I know the flag is never normally used for real Envisat files. However, missing data and incomplete orbits are much more common for the two earlier instruments and if the attachment flag is ignored the raster data will not match up with the tie-point data (after the first missing record)

Cheers,
Owen

RE: PNG, JPG and co...

2010-09-01T12:01:42Z

Using your trick (the first one) really improves the displaying operation. Unfortunately, I have another problem. It seems that when importing an image from a JPEG, we only get one tile as the 0-level in image, in awt and in ceres too. My problem is that i relied on the tiles put in the zoom levels, and on the fact that a tree was built by ceres. I just have a graph, now, it will be more diifficult to managge it... :-(

So I have a new question. Given a particular RenderedImage, is there a way to change the tile height and width ? I've tried using this code :

1
2ImageLayout il=new ImageLayout(0,0,imageReader.getWidth(FIRST_IMAGE),imageReader.getHeight(FIRST_IMAGE),
3                                                 0, 0, dimension.width, dimension.height, baseImage.getSampleModel(), baseImage.getColorModel());
4
5          final RenderingHints hints = new RenderingHints(
6                         JAI.KEY_IMAGE_LAYOUT, il);
7
8          // reading the image
9          final ParameterBlockJAI pbjFormat = new ParameterBlockJAI("Format");
10          PlanarImage p1 = PlanarImage.wrapRenderedImage(baseImage);
11          pbjFormat.addSource(p1);
12          pbjFormat.setParameter("dataType", baseImage.getSampleModel()
13                         .getDataType());
14
15
16          PlanarImage pi= JAI.create("Format", pbjFormat, hints);

Unfortunately, it doesn't work... If you have any advice on this topic...

by the way, the jpeg reader is changing. you cna find the last version on the svn repo here :

http://geosysin.iict.ch/irstv-trac/browser/branches/libs/grap2/grap2-platform/beam-stdformats/src/main/java/org/esa/beam/dataio/images/JPEGReader.java

RE: PNG, JPG and co...

2010-08-31T14:25:50Z

Thanks for the classes. Will have a look at them later.

Thanks for the video too. Nice work.

best wishes
Marco

RE: Geotools dependencies

2010-08-31T13:31:27Z

Some news again, more related to this topic.

As thee cts library seems to be buggy ( :-( ) we're considering to use the geotoolkit georeferencing library rather than cts in OrbisGIS. There are two main advantages upon the geotools library :

- this geotoolkit is independant of the main project. It can be used totally separately from the other geotoolkit libraries
- the code seems to be cleaner

As previously said, we will show you the result in the end. The migration should be easier, as the two libraries are quite close.

RE: PNG, JPG and co...

2010-08-31T13:24:06Z

(I'm afraid I will be a bit less responsive for a few weeks, I'm writing my final report for my internship... but the mission will continue after, and i'll try to work on this as often as possible :p )

I put the sources in attachment. They are quite similar, because the reading process are equivalent. I put them as txt, as .java is not a good extension ^_^

I'm about to investigate your first solution, by specifying directly the source image to the band. It cold be a short term solution, but its sustainability will depend on the way we'll choose to make image processing.

The second approach is not as satisfying, as I haven't use the visat-rcp package until now. I just rely on the core library and on the readers/writers (and of course on ceres ^_^ ).

If we except this problem with JPEG and PNG the integration in OrbisGIS goes well. You can find a video of the current result with a geotiff here :

http://geosysin.iict.ch/irstv-web/temp/orbisgis_raster.ogv

RE: PNG, JPG and co...

2010-08-31T08:34:56Z

Handling compressed data is always a tricky task.
What you can do is to set the band's source image directly using the RenderedImage created by JAI.
You don't have to split it up the image into several bands, if you only need it for display. But this way you will get only the red value when access pixel values of the band.
Another way just for displaying is to load the image as layer (see org.esa.beam.visat.toolviews.layermanager.layersrc.image.ImageFileLayerSource#insertImageLayer).

Please attach the reader source code.

best wishes
Marco

RE: Test mechanism in RasterDataNodeValuesTest

2010-08-31T07:13:41Z

To be more accurate, I must precise that the checkbox was checked by default when i began the thread, and i used FF 3.6. (I don't think I would have unchecked it)

PNG, JPG and co...

2010-08-31T07:04:39Z

Hi !

as i've understood how to make my threads public ( :-p ) I have some questions about the BEAM-core architecture.

Until now, i've been able to read Tiff and GeoTiff really easily, using the reader provided in the source code. Quite logical... But now, we're interested in some new readers which whould be able to read come compressed file formats, like png or jpeg. And there's a problem, of course, I wouldn't open a new thread otherwise :-p

Currently, as far as I understand, the readers are supposed to split up an image in bands (in fact, one Band in BEAM for one band in the image, it's logical). And, using Ceres, we're supposed to build a pyramid of tiles for the rendering processes. These two operations cause problems with compressed images...

On the first hand, when trying to build the tile pyramid, we're facing huge performance issues. It seem to be linked to the file format : we're making random access in the file in order to generate the tiles, and as the file is compressed, we are forced to uncompress large parts of the file just to access a few pixels.

On the second hand, when using beam, if I understand correctly what happens, we first separate the ands to put them back together after. As the file is compressed, it takes a really long time, I'm afraid, and it becomes clearly unusable. I'm not sure, here, that the problems really come from the band separation. I've tried to force my reader to use only one tile for the JPEG file I wanted to display, in order to correct the problem linked to the random access during the pyramid building.

My questions now... Have you already studied these problems ? Do you think there are solveable in a way ?

PS : i can attach you the two readers if you want. There are quite similar (in the structure) to the geottiff one, even if much simpler ((because i don't have to read custom tags in thefile metadatas). I'm bassically using the JAI reader for these file formats.

RE: Test mechanism in RasterDataNodeValuesTest

2010-08-31T06:46:07Z

Thanks for the info.
The checkbox should be checked by default.
I will investigate it further.

Thanks
Marco

RE: Test mechanism in RasterDataNodeValuesTest

2010-08-31T06:04:22Z

I use Firefox 4 and openSUSE. And there is a checkbox entitled "Public" that is not checked by default... That's why my posts were private. I missed it two times, I think :-p