[Geoserver-devel] Coverages: does any recent changes on trunk induces color inversion?

Martin_Desruisseaux · September 5, 2007, 5:28pm

When using Geoserver (build from trunk) with Geotools (build from 2.4 branch) as
a WCS server for images backed by an IndexColorModel of type
DataBuffer.TYPE_USHORT, things was working until last weekend. But since a "svn
update" done Monday, we experiment an inversion of colors. The IndexColorModel
itself seems unchanged (we dumped its color map to a file and checked), but the
result is as if pixels values were changed (low pixels become high and high
pixels become low). Is there any change done recently on the Geoserver or
Geotools code base relative to WCS management? The aim is just to know if we
should look harder in our own code or dig deeper in Geoserver WCS code...

Regards,

Martin

Simone3 · September 5, 2007, 5:36pm

Ciao Martin,
we have ported over to trunk the work that was done on the 1.5.x
branch first in order to improve the speed of inversion of color and
the speed of palette creation. This might be the cause of your
problems, even though it this impact only the WMS service and not the
WCS service.

Could you describe a little bit deeper your problem so that we can
help you out to fix it?

Btw, I am on IRC right now if you want to chat a bit.

Ciao,
Simone.

On 9/5/07, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

When using Geoserver (build from trunk) with Geotools (build from 2.4 branch) as
a WCS server for images backed by an IndexColorModel of type
DataBuffer.TYPE_USHORT, things was working until last weekend. But since a "svn
update" done Monday, we experiment an inversion of colors. The IndexColorModel
itself seems unchanged (we dumped its color map to a file and checked), but the
result is as if pixels values were changed (low pixels become high and high
pixels become low). Is there any change done recently on the Geoserver or
Geotools code base relative to WCS management? The aim is just to know if we
should look harder in our own code or dig deeper in Geoserver WCS code...

Regards,

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Martin_Desruisseaux · September 5, 2007, 5:50pm

Simone Giannecchini a écrit :

we have ported over to trunk the work that was done on the 1.5.x
branch first in order to improve the speed of inversion of color and
the speed of palette creation. This might be the cause of your
problems, even though it this impact only the WMS service and not the
WCS service.

Oups! I made a typo in my previous email; our issue was with WMS, not WCS. So it
may be related to the merge you described.

Could you describe a little bit deeper your problem so that we can
help you out to fix it?

Cedric could tell more; he will be there tomorrow. But I would just like to
know: if WMS performs an inversion of colors, which criterions are used in order
to decide if such inversion should be performed or not?

Martin

Andrea_Aime3 · September 5, 2007, 6:02pm

Martin Desruisseaux ha scritto:

Simone Giannecchini a écrit :

we have ported over to trunk the work that was done on the 1.5.x
branch first in order to improve the speed of inversion of color and
the speed of palette creation. This might be the cause of your
problems, even though it this impact only the WMS service and not the
WCS service.

Oups! I made a typo in my previous email; our issue was with WMS, not WCS. So it
may be related to the merge you described.

Could you describe a little bit deeper your problem so that we can
help you out to fix it?

Cedric could tell more; he will be there tomorrow. But I would just like to
know: if WMS performs an inversion of colors, which criterions are used in order
to decide if such inversion should be performed or not?

Color inversion is the operation that takes a full color image (24/32 bit per pixel) and turns it into a paletted, 8 bit per pixel image.
This inversion, as far as I know, happens only if you:
* provide the palette=xxx parameter to the request, where xxx is a palette name
* ask for image/png8 output format, which will render the map to 24
   bits, then figure out an optimal 256 colors palette, and again reduce
   the output to paletted
* add the new format_options:antialias:none, which will enable GeoServer
   to inspect the SLD for vector data and figure out an optimal palette
   that will be used directly for rendering. But this happens only if
   the SLD does not contain any raster symbolizer, translucent
   symbolizers, or attribute dependent color (does not look like your
   case).

In hightly doubt you are in any of these cases? Anyways, my suggestion
would be to add some debug code and see what's the image generated by
DefaultRasterMapProducer: if it's inverted, then the problem is in
rendering, otherwise it is in encoding (in that case you'll have
to debug the output format you're using).

Hope this helps
Cheers
Andrea

Simone3 · September 5, 2007, 6:05pm

minor addition, see below...

On 9/5/07, Andrea Aime <aaime@anonymised.com> wrote:

Martin Desruisseaux ha scritto:
> Simone Giannecchini a écrit :
>> we have ported over to trunk the work that was done on the 1.5.x
>> branch first in order to improve the speed of inversion of color and
>> the speed of palette creation. This might be the cause of your
>> problems, even though it this impact only the WMS service and not the
>> WCS service.
>
> Oups! I made a typo in my previous email; our issue was with WMS, not WCS. So it
> may be related to the merge you described.
>
>
>> Could you describe a little bit deeper your problem so that we can
>> help you out to fix it?
>
> Cedric could tell more; he will be there tomorrow. But I would just like to
> know: if WMS performs an inversion of colors, which criterions are used in order
> to decide if such inversion should be performed or not?

Color inversion is the operation that takes a full color image (24/32
bit per pixel) and turns it into a paletted, 8 bit per pixel image.

given a certain reference palette...

This inversion, as far as I know, happens only if you:
* provide the palette=xxx parameter to the request, where xxx is a
palette name
* ask for image/png8 output format, which will render the map to 24
  bits, then figure out an optimal 256 colors palette, and again reduce
  the output to paletted
* add the new format_options:antialias:none, which will enable GeoServer
  to inspect the SLD for vector data and figure out an optimal palette
  that will be used directly for rendering. But this happens only if
  the SLD does not contain any raster symbolizer, translucent
  symbolizers, or attribute dependent color (does not look like your
  case).

In hightly doubt you are in any of these cases? Anyways, my suggestion
would be to add some debug code and see what's the image generated by
DefaultRasterMapProducer: if it's inverted, then the problem is in
rendering, otherwise it is in encoding (in that case you'll have
to debug the output format you're using).

Hope this helps
Cheers
Andrea

Moreover, which output format are you using?

Ciao,
Simone.
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Martin_Desruisseaux · September 5, 2007, 6:10pm

Thanks a lot for all the explanation.

Simone Giannecchini a écrit :

Moreover, which output format are you using?

PNG, but again I need confirmation from Cedric.

Our source image is indexed 16 bits, which is not supported by the PNG format (I
think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
check which transformation chain is performed exactly (maybe [indexed 16 bits]
--> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.

Regards,

Martin

Andrea_Aime3 · September 5, 2007, 6:24pm

Martin Desruisseaux ha scritto:

Thanks a lot for all the explanation.

Simone Giannecchini a écrit :

Moreover, which output format are you using?

PNG, but again I need confirmation from Cedric.

Our source image is indexed 16 bits, which is not supported by the PNG format (I
think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
check which transformation chain is performed exactly (maybe [indexed 16 bits]
--> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.

png does support 16bit palettes, but this is not relevant because whatever image you're using it'll be drawn onto a graphics, not served directly. The graphics will usually be obtained from a full color
+ alpha buffered image, see the code in DefaultRasterMapProducer

Yet the idea of serving rasters more or less straigh seems kind of an
interesting optimization, which could be performed if:
* the map has no other layer other than the coverage
* there is no color map inside the raster symbolizers
Simone, what do you think?

Cheers
Andrea

Cedric_Briancon · September 6, 2007, 9:28am

Martin Desruisseaux a écrit :

Thanks a lot for all the explanation.

Simone Giannecchini a écrit :

Moreover, which output format are you using?

PNG, but again I need confirmation from Cedric.

Yes the format requested is image/png.

However I have a question about the class org.vfny.geoserver.wms.responses.GetMapResponse.
In a recent commit on Geoserver trunk, the produceMap() method that is called around line 370 has lost the parameter variable map (a WMSMapContext variable).
So in the code, we can see :
this.delegate.produceMap();
If I do a WMS request with the png format for output, I get a Null Pointer Exception on DefaultRasterMapProducer at a line that I can see :
final int width = mapContext.getMapWidth();
Consequently I can thinl that the parameter mapContext is null. I've tried to add this line to the GetMapResponse class, in the method execute():
delegate.setMapContext(map);
This line is just before the call of the produceMap() method. I do not get a null pointer exception, because the map context is set before. But I get an inverted color image...

This WMSMapContext parameter is set with some values, but doesn't seem to be used in the end (or I've missed something). I can assume that here is a problem with some unused code lines.

Regards,
Cédric B.

Our source image is indexed 16 bits, which is not supported by the PNG format (I
think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
check which transformation chain is performed exactly (maybe [indexed 16 bits]
--> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.

Regards,

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Andrea_Aime3 · September 6, 2007, 9:48am

Cédric Briançon ha scritto:

Martin Desruisseaux a écrit :

Thanks a lot for all the explanation.

Simone Giannecchini a écrit :

Moreover, which output format are you using?

PNG, but again I need confirmation from Cedric.

Yes the format requested is image/png.

However I have a question about the class org.vfny.geoserver.wms.responses.GetMapResponse.
In a recent commit on Geoserver trunk, the produceMap() method that is called around line 370 has lost the parameter variable map (a WMSMapContext variable).
So in the code, we can see :
this.delegate.produceMap();
If I do a WMS request with the png format for output, I get a Null Pointer Exception on DefaultRasterMapProducer at a line that I can see :
final int width = mapContext.getMapWidth();

Cedric are you sure you're not playing with locally modified code
that had some issues with a merge of the changes we've performed?
If there was a null pointer exception in such a simple case we would
already have noticed.
My checkout has no modifications and it's working fine.

Anyways, you're right in stating that the produceMap() call changed,
now the mapContext is provided to the delegate using a setter... why
this happened, I don't know... unfortunately Simone mixed reformats
and make real modifications impossible to see, so I was left with
the only possibility of checking that the code looked fine and that
it did not break without really knowing what changed in detail ;(

I suggest you apply whatever your changes were to a clean checkout
and see if the problem is still there.

Cheers
Andrea

Cedric_Briancon · September 6, 2007, 10:01am

Andrea Aime a écrit :

Cédric Briançon ha scritto:

Martin Desruisseaux a écrit :

Thanks a lot for all the explanation.

Simone Giannecchini a écrit :

Moreover, which output format are you using?

PNG, but again I need confirmation from Cedric.

Yes the format requested is image/png.

However I have a question about the class org.vfny.geoserver.wms.responses.GetMapResponse.
In a recent commit on Geoserver trunk, the produceMap() method that is called around line 370 has lost the parameter variable map (a WMSMapContext variable).
So in the code, we can see :
this.delegate.produceMap();
If I do a WMS request with the png format for output, I get a Null Pointer Exception on DefaultRasterMapProducer at a line that I can see :
final int width = mapContext.getMapWidth();

Cedric are you sure you're not playing with locally modified code
that had some issues with a merge of the changes we've performed?
If there was a null pointer exception in such a simple case we would
already have noticed.
My checkout has no modifications and it's working fine.

When I did a svn update on geoserver trunk last week, I got 3 files in conflict, GetMapkvpReader, GetMapRequest and GetMapResponse. I've tried to stay the closest as I can to the svn new changes, but maybe I've done a mistake on resolving the conflicts ... I will inspect the svn diff for these classes, in order to see if I've forgotten something...

Anyways, you're right in stating that the produceMap() call changed,
now the mapContext is provided to the delegate using a setter... why
this happened, I don't know... unfortunately Simone mixed reformats
and make real modifications impossible to see, so I was left with
the only possibility of checking that the code looked fine and that
it did not break without really knowing what changed in detail ;(

I suggest you apply whatever your changes were to a clean checkout
and see if the problem is still there.

Cheers
Andrea

Simone3 · September 6, 2007, 10:01am

Ciao Cedric,
please, read below....

On 9/6/07, Cédric Briançon <cedric.briancon@anonymised.com> wrote:

Martin Desruisseaux a écrit :
> Thanks a lot for all the explanation.
>
> Simone Giannecchini a écrit :
>
>> Moreover, which output format are you using?
>>
>
> PNG, but again I need confirmation from Cedric.
>
>
Yes the format requested is image/png.

However I have a question about the class
org.vfny.geoserver.wms.responses.GetMapResponse.
In a recent commit on Geoserver trunk, the produceMap() method that is
called around line 370 has lost the parameter variable map (a
WMSMapContext variable).
So in the code, we can see :
this.delegate.produceMap();
If I do a WMS request with the png format for output, I get a Null
Pointer Exception on DefaultRasterMapProducer at a line that I can see :
final int width = mapContext.getMapWidth();

This is pretty strange, if you check at the top of the method we are
setting the mapcontext explicitly on the delegate:

this.delegate.setMapContext(map);

    // enable on the fly meta tiling if request looks like a tiled one
    if (MetatileMapProducer.isRequestTiled(request, delegate)) {
      if (LOGGER.isLoggable(Level.FINER)) {
        LOGGER
            .finer("Tiled request detected, activating on the fly meta tiler");
      }

      this.delegate = new MetatileMapProducer(request,
          (RasterMapProducer) delegate);
      this.delegate.setMapContext(map);
    }

so it should never happen to get a null pointer exception. As aaime
said, such an error should have been caught by the test-cases or by
our own test pretty quickly.
Maybe some local changes got mixed up after the update.

Anyway, co

Consequently I can thinl that the parameter mapContext is null. I've
tried to add this line to the GetMapResponse class, in the method execute():
delegate.setMapContext(map);
This line is just before the call of the produceMap() method. I do not
get a null pointer exception, because the map context is set before. But
I get an inverted color image...

I don't have a clear idea about this inverted color image. Can you
please give more detail about what you are doing? If you want you can
find me on GTalk today at anytime. Just use my email as my id and I'll
help you out.

This WMSMapContext parameter is set with some values, but doesn't seem
to be used in the end (or I've missed something). I can assume that here
is a problem with some unused code lines.

Regards,
Cédric B.

Ciao,
Simone.

PS
Sorry about the reformat, but I forgot that jalopy reformatting was turned off!

> Our source image is indexed 16 bits, which is not supported by the PNG format (I
> think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
> check which transformation chain is performed exactly (maybe [indexed 16 bits]
> --> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.
>
> Regards,
>
> Martin
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Cedric_Briancon · September 6, 2007, 10:22am

Simone Giannecchini a écrit :

This is pretty strange, if you check at the top of the method we are
setting the mapcontext explicitly on the delegate:

    this.delegate.setMapContext(map);

    // enable on the fly meta tiling if request looks like a tiled one
    if (MetatileMapProducer.isRequestTiled(request, delegate)) {
      if (LOGGER.isLoggable(Level.FINER)) {
        LOGGER
            .finer("Tiled request detected, activating on the fly meta tiler");
      }

      this.delegate = new MetatileMapProducer(request,
          (RasterMapProducer) delegate);
      this.delegate.setMapContext(map);
    }

so it should never happen to get a null pointer exception. As aaime
said, such an error should have been caught by the test-cases or by
our own test pretty quickly.
Maybe some local changes got mixed up after the update.

Hi Simone,
instead of what you've written, I have this :

this.delegate = getDelegate(outputFormat, wms);

        // enable on the fly meta tiling if request looks like a tiled one
        if (MetatileMapProducer.isRequestTiled(request, delegate)) {
            LOGGER.finer("Tiled request detected, activating on the fly meta tiler");
            this.delegate = new MetatileMapProducer(request, (RasterMapProducer) delegate);
        }

... So I have surely done a mistake when I've tried to resolve my conflicts for this class It is probably the code before the commit that I've kept, sorry ...
I will try to see if there is no other problems between my local version and the svn, and I will send a new email on the list to tell you what happens.
Thanks a lot.

Cédric B.

Anyway, co

Consequently I can thinl that the parameter mapContext is null. I've
tried to add this line to the GetMapResponse class, in the method execute():
delegate.setMapContext(map);
This line is just before the call of the produceMap() method. I do not
get a null pointer exception, because the map context is set before. But
I get an inverted color image...

I don't have a clear idea about this inverted color image. Can you
please give more detail about what you are doing? If you want you can
find me on GTalk today at anytime. Just use my email as my id and I'll
help you out.

This WMSMapContext parameter is set with some values, but doesn't seem
to be used in the end (or I've missed something). I can assume that here
is a problem with some unused code lines.

Regards,
Cédric B.

Ciao,
Simone.

PS
Sorry about the reformat, but I forgot that jalopy reformatting was turned off!

Our source image is indexed 16 bits, which is not supported by the PNG format (I
think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
check which transformation chain is performed exactly (maybe [indexed 16 bits]
--> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.

Regards,

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Simone3 · September 6, 2007, 10:24am

No problem on that Cedric,
the more eyes we have on the code the better it is. Sorry about the
reformat thing, I have to be more careful on that :-).

Btw, I am still a bit puzzled about the image with colors inverted. If
you have time I would like to investigate this a bit today on GTalk.
I'd need more info to help you out there.

Ciao,
Simone.

On 9/6/07, Cédric Briançon <cedric.briancon@anonymised.com> wrote:

Simone Giannecchini a écrit :
> This is pretty strange, if you check at the top of the method we are
> setting the mapcontext explicitly on the delegate:
>
>
> this.delegate.setMapContext(map);
>
> // enable on the fly meta tiling if request looks like a tiled one
> if (MetatileMapProducer.isRequestTiled(request, delegate)) {
> if (LOGGER.isLoggable(Level.FINER)) {
> LOGGER
> .finer("Tiled request detected, activating on the fly meta tiler");
> }
>
> this.delegate = new MetatileMapProducer(request,
> (RasterMapProducer) delegate);
> this.delegate.setMapContext(map);
> }
>
> so it should never happen to get a null pointer exception. As aaime
> said, such an error should have been caught by the test-cases or by
> our own test pretty quickly.
> Maybe some local changes got mixed up after the update.
>
>
>
Hi Simone,
instead of what you've written, I have this :

       this.delegate = getDelegate(outputFormat, wms);

       // enable on the fly meta tiling if request looks like a tiled one
       if (MetatileMapProducer.isRequestTiled(request, delegate)) {
           LOGGER.finer("Tiled request detected, activating on the fly
meta tiler");
           this.delegate = new MetatileMapProducer(request,
(RasterMapProducer) delegate);
       }

... So I have surely done a mistake when I've tried to resolve my
conflicts for this class It is probably the code before the commit
that I've kept, sorry ...
I will try to see if there is no other problems between my local version
and the svn, and I will send a new email on the list to tell you what
happens.
Thanks a lot.

Cédric B.
> Anyway, co
>
>
>> Consequently I can thinl that the parameter mapContext is null. I've
>> tried to add this line to the GetMapResponse class, in the method execute():
>> delegate.setMapContext(map);
>> This line is just before the call of the produceMap() method. I do not
>> get a null pointer exception, because the map context is set before. But
>> I get an inverted color image...
>>
>>
>
>
> I don't have a clear idea about this inverted color image. Can you
> please give more detail about what you are doing? If you want you can
> find me on GTalk today at anytime. Just use my email as my id and I'll
> help you out.
>
>
>> This WMSMapContext parameter is set with some values, but doesn't seem
>> to be used in the end (or I've missed something). I can assume that here
>> is a problem with some unused code lines.
>>
>> Regards,
>> Cédric B.
>>
>>
>
> Ciao,
> Simone.
>
> PS
> Sorry about the reformat, but I forgot that jalopy reformatting was turned off!
>
>
>>> Our source image is indexed 16 bits, which is not supported by the PNG format (I
>>> think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
>>> check which transformation chain is performed exactly (maybe [indexed 16 bits]
>>> --> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.
>>>
>>> Regards,
>>>
>>> Martin
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>>
>>
>
>
>

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------

Cedric_Briancon · September 6, 2007, 11:18am

Simone Giannecchini a écrit :

No problem on that Cedric,
the more eyes we have on the code the better it is. Sorry about the
reformat thing, I have to be more careful on that :-).

Btw, I am still a bit puzzled about the image with colors inverted. If
you have time I would like to investigate this a bit today on GTalk.
I'd need more info to help you out there.

I've copied my changes in an other directory, reverted the code to the version of the svn, and added my changes to the svn version on my local machine. But I still get an inverted color image.
So I will surely try to contact you by the GTalk chat in this afternoon.
Thanks,
Cédric B.

Ciao,
Simone.

On 9/6/07, Cédric Briançon <cedric.briancon@anonymised.com> wrote:


Simone Giannecchini a écrit :


This is pretty strange, if you check at the top of the method we are
setting the mapcontext explicitly on the delegate:

              this.delegate.setMapContext(map);

              // enable on the fly meta tiling if request looks like a tiled one
              if (MetatileMapProducer.isRequestTiled(request, delegate)) {
                      if (LOGGER.isLoggable(Level.FINER)) {
                              LOGGER
                                              .finer("Tiled request detected, activating on the fly meta tiler");
                      }

                      this.delegate = new MetatileMapProducer(request,
                                      (RasterMapProducer) delegate);
                      this.delegate.setMapContext(map);
              }

so it should never happen to get a null pointer exception. As aaime
said, such an error should have been caught by the test-cases or by
our own test pretty quickly.
Maybe some local changes got mixed up after the update.

Hi Simone,
instead of what you've written, I have this :

       this.delegate = getDelegate(outputFormat, wms);

       // enable on the fly meta tiling if request looks like a tiled one
       if (MetatileMapProducer.isRequestTiled(request, delegate)) {
           LOGGER.finer("Tiled request detected, activating on the fly
meta tiler");
           this.delegate = new MetatileMapProducer(request,
(RasterMapProducer) delegate);
       }

... So I have surely done a mistake when I've tried to resolve my
conflicts for this class It is probably the code before the commit
that I've kept, sorry ...
I will try to see if there is no other problems between my local version
and the svn, and I will send a new email on the list to tell you what
happens.
Thanks a lot.

Cédric B.


Anyway, co

Consequently I can thinl that the parameter mapContext is null. I've
tried to add this line to the GetMapResponse class, in the method execute():
delegate.setMapContext(map);
This line is just before the call of the produceMap() method. I do not
get a null pointer exception, because the map context is set before. But
I get an inverted color image...

I don't have a clear idea about this inverted color image. Can you
please give more detail about what you are doing? If you want you can
find me on GTalk today at anytime. Just use my email as my id and I'll
help you out.

This WMSMapContext parameter is set with some values, but doesn't seem
to be used in the end (or I've missed something). I can assume that here
is a problem with some unused code lines.

Regards,
Cédric B.

Ciao,
Simone.

PS
Sorry about the reformat, but I forgot that jalopy reformatting was turned off!

Our source image is indexed 16 bits, which is not supported by the PNG format (I
think it supports only 24/32 bits [A]RGB or indexed 8 bits). We will need to
check which transformation chain is performed exactly (maybe [indexed 16 bits]
--> [24 bits RGB] --> [indexed 8 bits]). We will put some debug code tomorrow.

      Regards,

              Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel