Menu

#293 Broken display and handling of partly of tile saturation and brightness

open
nobody
None
1
2017-05-08
2017-05-08
No

Hi all,
pls. see the attached images. The square ones are the (adjacent) input to MOBAC, the wider screenshot is what MOBAC shows and puts into map files.
My Java is on latest 8-131. The effect happens on W10 and MacOS alike.
Any idea why that is ? And how to get this fixed ?
TXs and cheers
Michael

3 Attachments

Discussion

  • r_x

    r_x - 2017-05-08

    Hi Michael,

    I am sorry but I don't see the problem. The input files are both text on a transparent background and the map in MOBAC is text on a white background (which you have selected as background).
    Unfortunately your post is missing the custom mapsource file you are using for loading them into MOBAC.

    Assuming you are using a custom XML map source your file contains #FFFFFF or #FFFFFFFF for background color (white). If you want it to be transparent you have to set it to #00000000.

    For more details see the background color help:
    http://mobac.sourceforge.net/wiki/index.php/Custom_XML_Map_Sources#backgroundColor

     
  • Michael Bechtold

    Hi Robert,
    this is the map source:
    <localtilefiles>
    <name>CapitalRepair</name>
    <sourcetype>DIR_ZOOM_X_Y</sourcetype>
    <sourcefolder>G:\Dropbox\MOBAC\MapCreation\atlases\CapitalRepair\</sourcefolder>
    <backgroundcolor>#000000</backgroundcolor>
    </localtilefiles>
    and that is all well understood and fine.
    Did you have a look at all 3 screenshots attached ? You will see that the left tile of the screenshot is bad quality and the right tile is as it should be. While the source tile files (88w and 88e) are perfectly OK. Epinal in 88e should have an equivalent look as Lahr in 88e, Nancy equivalent to Offenburg. MOBAC shows and produces a very pale result for 88w, and the correct one for 88e.
    TXs and cheers
    Michael

     
  • Michael Bechtold

    PS: I went back to Java 8-121 as well to rule out that my recent upgarde to 131 causes the issue - same problem with 8-121

     
  • r_x

    r_x - 2017-05-08

    Ok, now I see. The problematic PNG is a 8bit grayscale+alpha image where as the working image is an 8bit truecolor+alpha PNG.

    It seems like Java has a problem to interpret tha alpha channel correctly on grayscale PNG images.
    And we are not alone: http://stackoverflow.com/questions/32583772/reading-grayscale-png-image-files-without-distortion

     
  • Michael Bechtold

    That is WEIRD !! All of those files are the result of ONE command by ImageMagick:
    convert $capfile.bak.png -fuzz 20% -transparent white -crop -$CROPW+0 -crop +0-$CROPH +repage +adjoin $capfile
    Then the files are the put into the right place in a Maverick like structure.
    The difference seems: when there is a capitals (province, state, country), a real color comes into the picture, while else it is only B/W/grey and ImageMagick seems to optimize as good as possible.
    While we are not in control of Java, with your hint I will look into ImageMagick to see if I can enforce the truecolor format.

     
  • Michael Bechtold

    Workaround: convert $capfile -crop 14x8@ +repage +adjoin -define png:color-type=2 h%d.png
    Colortype 2 forces truecolor, and MOBAC now shows the expected outcome :-)

     
  • Michael Bechtold

    Not working - when I show those tiles only, the saturation is correct. HOWEVER, when using them as an overlay, there is no transparency any more - bummer ... Playing with other options now.

     
  • Michael Bechtold

    That works: convert $capfile -crop 14x8@ +repage +adjoin -define png:color-type=6 h%d.png

     

Log in to post a comment.

MongoDB Logo MongoDB