Colorfulness layer visibility slider does not work

[aseerel4c26]

What steps will reproduce the problem?

1. Load the OSM Carto (Standard) background Layer
2. Use the Colorfulness visibility slider to increase or decrease the saturation.

What is the expected result?

Saturation changes

What happens instead?

nothing except slider move

Please provide any additional information below. Attach a screenshot if possible.

The other three sliders work.

I used a fresh JOSM config.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-02-03 19:12:36 +0100 (Sat, 03 Feb 2018)
Revision:13381
Build-Date:2018-02-04 03:01:46
URL:http://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (13381 de) Linux Linux
Memory Usage: 331 MB / 2048 MB (114 MB allocated, but free)
Java version: 9.0.4+11, Oracle Corporation, OpenJDK 64-Bit Server VM
VM arguments: [-Dawt.useSystemAAFontSettings=on, -Dswing.aatext=true]

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Don-vip]

Image is of type BufferedImage.TYPE_BYTE_INDEXED and thus ignored:

        switch (type) {
        case BufferedImage.TYPE_3BYTE_BGR:
            blueOffset = 0;
            greenOffset = 1;
            redOffset = 2;
            break;
        case BufferedImage.TYPE_4BYTE_ABGR:
        case BufferedImage.TYPE_4BYTE_ABGR_PRE:
            blueOffset = 1;
            greenOffset = 2;
            redOffset = 3;
            break;
        case BufferedImage.TYPE_INT_ARGB:
        case BufferedImage.TYPE_INT_ARGB_PRE:
            redOffset = 0;
            greenOffset = 1;
            blueOffset = 2;
            alphaOffset = 3;
            break;
        default:
            Logging.trace("Cannot apply color filter: Source image is of wrong type (" + type + ").");
            return src;
        }

Should we disable the colorfulness slider for these type of images? This is clearly confusing.

[michael2402]

I think we should convert it to a usable format instead (same as sharpen / ... filters do)

Fas way for indexed images
This is enough if we only have indexed images. Quite cool since this is significantly faster since we don't need to touch every pixel, not so hard to write...

Pseudo code.

cm = (IndexColorModel) src.getColorModel();
newModel = array of (r,g,b) values
for ((r,g,b) in (cm.getReds(), cm.getGreens(), cm.getBlues()) {
  compute new (r,g,b) values for this index
}
create dst with original raster and new color model

Universal way

It might be enough to call createCompatibleWritableRaster() on the source image, then create a new BufferedImage using this raster, as e.g. java.awt.image.ConvolveOp do this.

This might be easier than finding a reliable way to detect the image types used by a layer.

We may not care so much about speed in this case, because the colorful filter is mostly meant for enhancing sat images. But we should care about garbage collection a bit and not create an intermediate image. So the filter-Method would need to catch the case of a unsupported image format and then not use the optimized function but instead filter pixel by pixel using the normal BufferedImage methods (in hope that it is fast enough).

[Don-vip]

Replying to michael2402:

not so hard to write...

Thanks. But even with pseudo code, I don't really see what we must do. Could you please implement it? It would certainly take you a lot less time than me :)

[michael2402]

My first weekend off this year - so yes, of cause :D

[michael2402]

In 13397/josm:

Fix #15878: Implement colorfullness filter for indexed images.

[michael2402]

I added the code + tests for the byte_indexed type. I don't think we need to support custom/universal types. When I implemented the filter I did some speed tests and doing a getRGB for each pixel made JOSM very unresponsive - I'd rather have the user report bugs that it does not work in those cases so that we can see what other image formats are used by some crazy image layers.

Btw, @Don-Vip: Current JOSM is incompatible with jmapviewer 2.5. And the build.xml script of jmapviewer does not seem to work with old ant versions. And we should definitely switch to GIT some time before I accidentially commit my eclipse project config ;-)

[Don-vip]

Replying to michael2402:

Current JOSM is incompatible with jmapviewer 2.5.

Please detail.

And the build.xml script of jmapviewer does not seem to work with old ant versions.

Well, update your Ant version.

[michael2402]

Replying to Don-vip:

Replying to michael2402:

Current JOSM is incompatible with jmapviewer 2.5.

Please detail.

You did a release of jmapviewer 2.5 and changed one field visibility afterwards. So when building JOSM with jmapviewer 2.5, there are compilation errors.

And the build.xml script of jmapviewer does not seem to work with old ant versions.

Well, update your Ant version.

Yes, I figured that out. The problem was that there was no error in the ant output. It just displayed that the build was done.

[Don-vip]

Replying to michael2402:

You did a release of jmapviewer 2.5 and changed one field visibility afterwards. So when building JOSM with jmapviewer 2.5, there are compilation errors.

OK I didn't notice Paul made a change recently. We release JMapViewer at the same time of JOSM, so this is not a problem.

[michael2402]

Replying to Don-vip:

Replying to michael2402:

You did a release of jmapviewer 2.5 and changed one field visibility afterwards. So when building JOSM with jmapviewer 2.5, there are compilation errors.

OK I didn't notice Paul made a change recently. We release JMapViewer at the same time of JOSM, so this is not a problem.

Unless someone has a build script lying around that does not depend on the svn:externals. Just wanted to mention it since I did not see any release process for that project in the sources ;-)

[aseerel4c26]

great, that works! :-) tested with version 13400

Thank you!