uDIG
  1. uDIG
  2. UDIG-1786

Map to Image Export creates bad images

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: UDIG 1.2.2, 2.x
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      windows XP,
      windows 7 64bit,
      ubuntu 11.04 32bit,
      JRE : jre 1.6.0_25-b06 (included in uDig installation)
      natural earth data set + WMS

      Description

      If the map has multiple layers and the user tries to export Map via 'File -> Export .. -> Map to Image' the exported PNG image is black in areas where the top level layer has no data.
      The attached image MapToImage-MapView.png shows the original Map in the application. The other two images show the exported Images. Map-TopLevel-Fill.png shows the result, when the top level layer (shp) has fill style with opacity to 25, the other one is the result of the Image export with no fill style.

        Activity

        Hide
        Frank Gasdorf added a comment -
        created a pull request to solve this issue : https://github.com/uDig/udig-platform/pull/102
        Show
        Frank Gasdorf added a comment - created a pull request to solve this issue : https://github.com/uDig/udig-platform/pull/102
        Hide
        Andrea Antonello added a comment -
        Hi Frank, thanks for the patch. You really are saying that it got black because the panel was wrongly drawn black? :)
        Show
        Andrea Antonello added a comment - Hi Frank, thanks for the patch. You really are saying that it got black because the panel was wrongly drawn black? :)
        Hide
        Frank Gasdorf added a comment - - edited
        Andrea,
        yeah, I assumed that the problem came from the graphic element itself (BufferedImage TYPE_INT_RGB vs. TYPE_INT_ARGB), but its not. I've no clue, why the method calls setBackground() and clear() are in this class, maybe rendering optimizations for update events with a ReferencedEnvelope?
        Do you think that the problem is coming from somewhere else?

        Right now I'm not sure why the MapViewer haven't had any problems with shapefiles. My guess was, both Image Exporter and MapViewer uses the same rendering subsystem with the same registered Renderers from extension registry. But my guess seems to be wrong. Properly the result of rendering differ because of different Hints for accessing RendererFactories (with its metrics) or droperly the different RendereContext's?

        Could anybody help with better knowledge of rendering architecture?
        Show
        Frank Gasdorf added a comment - - edited Andrea, yeah, I assumed that the problem came from the graphic element itself (BufferedImage TYPE_INT_RGB vs. TYPE_INT_ARGB), but its not. I've no clue, why the method calls setBackground() and clear() are in this class, maybe rendering optimizations for update events with a ReferencedEnvelope? Do you think that the problem is coming from somewhere else? Right now I'm not sure why the MapViewer haven't had any problems with shapefiles. My guess was, both Image Exporter and MapViewer uses the same rendering subsystem with the same registered Renderers from extension registry. But my guess seems to be wrong. Properly the result of rendering differ because of different Hints for accessing RendererFactories (with its metrics) or droperly the different RendereContext's? Could anybody help with better knowledge of rendering architecture?
        Hide
        Jody Garnett added a comment -
        Update from email ...

        BasicFeatureRenderer trying to solve one problem (clearing a small area that needs and update) in the wrong section of code.

        The Renderer API render(Graphics2D, ReferencedEnvelope, IProgressMonitor) method is used in three situations:

        a) Renderer render(IProgressMonitor) - which creates a new raster to hold the contents of the layer, and then calls renderer( Graphics2D, … ) etc to fill it with content

        b) ApplicationGIS drawMap which uses the renderer( Graphics2D , … ) method directly to draw every layer into the same graphics

        So to fix this issue we need to move the "clearRectangle" into one of two spots (not sure which yet). It could be done in the layer.refresh( … ) method; or in the renderer( IProgressMonitor ) method.

        Aside: Moovida and I also had a bit of fun checking how the map background colour was passed around the system. The Black colour mentioned in your bug report was confusing - I suspect that when ApplicationGIS drawMap makes a copy of the original Map it may be failing to copy the background colour over?
        Show
        Jody Garnett added a comment - Update from email ... BasicFeatureRenderer trying to solve one problem (clearing a small area that needs and update) in the wrong section of code. The Renderer API render(Graphics2D, ReferencedEnvelope, IProgressMonitor) method is used in three situations: a) Renderer render(IProgressMonitor) - which creates a new raster to hold the contents of the layer, and then calls renderer( Graphics2D, … ) etc to fill it with content b) ApplicationGIS drawMap which uses the renderer( Graphics2D , … ) method directly to draw every layer into the same graphics So to fix this issue we need to move the "clearRectangle" into one of two spots (not sure which yet). It could be done in the layer.refresh( … ) method; or in the renderer( IProgressMonitor ) method. Aside: Moovida and I also had a bit of fun checking how the map background colour was passed around the system. The Black colour mentioned in your bug report was confusing - I suspect that when ApplicationGIS drawMap makes a copy of the original Map it may be failing to copy the background colour over?
        Hide
        Jody Garnett added a comment -
        I have pushed up a fix for testing. While I have stepped through the code with a debugger so I am confident what is going on more testing is needed :-)
        Show
        Jody Garnett added a comment - I have pushed up a fix for testing. While I have stepped through the code with a debugger so I am confident what is going on more testing is needed :-)

          People

          • Assignee:
            Unassigned
            Reporter:
            Frank Gasdorf
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: