|
From: <fac...@im...> - 2024-06-05 15:31:19
|
Hello everyone, I wanted to ask for your help with an issue I am having when trying to use the ImagePyramid plugin to generate a WMS/WMTS service. I have a rather large number of GeoTiff tiles that I combined using gdalbuildvrt, gdal_translate and gdal_retile to generate an image pyramid, and then generated a data store on Geoserver with it using the ImagePyramid plugin. My problem happens when trying to publish said pyramid as a WMS or WMTS service. I added the data store of Image Pyramid type and as far as I can see the shapefiles created to reference the different levels of the pyramid are generated correctly. The problem is, when using even the default configuration for this type of layer, that the service delivers the images with the pixel values inverted, as in, instead of having a value of (x,y,z,t), each pixel has a value of (255-x,255-y,255-z,255-t). This results in images shown in "negative" colors. Below is an example of this layer shown in QGIS, but in other services and in the layer pre-visualization tool in Geoserver it looks the same. The point selected is one that corresponds to a white rooftop, and therefore has values that are closer to 255. So in this case, it's shown in black and its values are close to 0. I've checked that this does'nt happen with the individual GeoTiff images in any level of the pyramid, and the color values for the different images appear to work correctly. The images have 4 channels (R,G,B and NiR) and this behaviour occurs in all of them. Below is an example comparison in QGIS with my WMS service and a sample image from the same pyramid. (Also, the GeoTiff files look normal when opened in any standard image viewer). The values of the mvd_geotiff_n layer correspond to the original image, while the others correspond to the WMS service. As you can see, this "inversion" phenomenon happens in all 4 bands independently. I've checked that this does'nt happen due to an incorrect use of the 4th band, since the only issue with that band is that it is sometimes incorrectly used as a transparency mask. I made a raster style that only uses the RGB bands to solve this, but even when using the default raster style the image looks the same but semitransparent, so I don't believe that is the cause of this issue. Also, checking the different shapefiles the plugin generates to index the images I have not found anything that could cause this issue there, as well as the .properties file generated. Therefore, the cause of this is probably the Geoserver layer itself. I've tried different tweaks to the configuration of the layer, but haven't been able to make it work yet (below is an example). This configuration does'nt stray far from the default and has worked for smaller pyramids that i tried out first, so I don't know what may be introducing this "inversion" phenomenon. And in the "Publication" tab, this are the formats: I have tried this in 2 different GeoServer instances, with versions 2.23.SNAPSHOT and 2.25.0, with OpenJDK-11. If you know of any possible cause for this issue please let me know. Thanks in advance, Facundo Pedreira, Municipality of Montevideo. ----- El presente correo electronico y cualquier posible archivo adjunto esta dirigido unicamente al destinatario del mismo y contiene informacion que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente de su sistema, el correo electronico y los posibles archivos adjuntos al mismo. Esta prohibida cualquier utilizacion, difusion o copia de este correo electronico por cualquier persona o entidad que no sean las especificas destinatarias del mensaje. La Intendencia de Montevideo no acepta ninguna responsabilidad con respecto a cualquier comunicacion que haya sido emitida incumpliendo nuestra normativa municipal, asi como lo previsto en la Ley 18.331 de Proteccion de Datos Personales y la Ley 18.381 de Acceso a la Informacion Publica. This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. The City Council of Montevideo is not responsible for any communication emitted without respecting our Organization Policy or the Data Protection Act and Habeas Data Action No. 18.331 and the Information Access Act N 18.381. |