Modify

Opened 3 months ago

Closed 2 months ago

Last modified 2 months ago

#15878 closed defect (fixed)

Colorfulness layer visibility slider does not work

Reported by: aseerel4c26 Owned by: team
Priority: normal Milestone: 18.02
Component: Core imagery Version: latest
Keywords: template_report layers visibility saturation colorfulness Cc: michael2402

Description

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.

Attachments (0)

Change History (13)

comment:1 Changed 3 months ago by Don-vip

Cc: michael2402 added

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.

comment:2 Changed 3 months ago by 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).

comment:3 in reply to:  2 Changed 2 months ago by 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 :)

comment:4 Changed 2 months ago by Don-vip

Keywords: visibility added; visbility removed
Priority: minornormal

comment:5 Changed 2 months ago by michael2402

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

comment:6 Changed 2 months ago by michael2402

Resolution: fixed
Status: newclosed

In 13397/josm:

Fix #15878: Implement colorfullness filter for indexed images.

comment:7 Changed 2 months ago by 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 ;-)

comment:8 in reply to:  7 ; Changed 2 months ago by 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.

comment:9 Changed 2 months ago by Don-vip

Component: CoreCore imagery
Milestone: 18.02

comment:10 in reply to:  8 ; Changed 2 months ago by 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.

comment:11 in reply to:  10 ; Changed 2 months ago by 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.

comment:12 in reply to:  11 Changed 2 months ago by 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 ;-)

comment:13 Changed 2 months ago by aseerel4c26

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

Thank you!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.