Bug report #17102

Editing raster pseudocolor classification seems to trigger unwanted auto-classification after validation and by the same clearing all modifications

Added by Dominique Lyszczarz over 6 years ago. Updated about 6 years ago.

Status:Closed
Priority:High
Assignee:Mathieu Pellerin - nIRV
Category:Symbology
Affected QGIS version:master Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:25001

Description

Process to reproduce the issue :

load an one-band raster, open layer properties, create a new pseudocolor classification and then press ok
-reopen the properties, try to modify the classification (value, color or add/remove step) and then press apply >> the modifications are not taken into account and the classification reverts back to its initial state.
 on the other hand, the following modifications are properly applied

The issue concerns only QGIS master and happen both on properties window and style panel.

qgis bug report 17102.jpg (129 KB) Dominique Lyszczarz, 2018-01-19 09:48 AM

tst.qgs (7.48 KB) Dominique Lyszczarz, 2018-01-28 07:12 PM

clip.tif (861 KB) Dominique Lyszczarz, 2018-01-28 07:12 PM

after apply.JPG (34.3 KB) Alister Hood, 2018-02-13 01:07 AM

after load style before apply.JPG (32.8 KB) Alister Hood, 2018-02-13 01:07 AM

Associated revisions

Revision 51c5805e
Added by Mathieu Pellerin - nIRV about 6 years ago

[raster] don't auto-classify upon customizing values tree (fixes #17102)

History

#1 Updated by Giovanni Manghi over 6 years ago

  • Regression? changed from No to Yes

#2 Updated by Nyall Dawson about 6 years ago

  • Status changed from Open to Feedback

Can't reproduce - is this still an issue? If so, please post step-by-step instructions on reproducing (or a video)

#3 Updated by Dominique Lyszczarz about 6 years ago

I can't replicate the bug in the layer's properties dialog but it still occur in the style panel. In attachment a screenshoot that illustrate the problem.

It seems it happen only after selected another layer and then come back to edit the classification, for example:
- load a raster and create a simple classification
- duplicate the layer and select the new unchecked layer
- now trying to edit the classification of this layer and here the problem occurs

#4 Updated by Dominique Lyszczarz about 6 years ago

Please find in attachment a test file containing a raster classification. Trying to edit this classification or even change color settings like brightness, completely mess up the classification.

#5 Updated by Mathieu Pellerin - nIRV about 6 years ago

I'll have a look at this. It's not a bug per say but we might have to tweak the UX a bit. Right now, modifying classes automatically reclassify the renderer.

#6 Updated by Dominique Lyszczarz about 6 years ago

  • Status changed from Feedback to Open

Thanks Mathieu, now that's it's confirmed I change the statut. Not sure about the bug definition but this is an unwanted behaviour in the ui mecanism and this is a very anyoning problem making raster styling pretty unsuable in day by day tasks. Workaround is to save the colormap to an external txt file and then reload it after classification messup.

#7 Updated by Mathieu Pellerin - nIRV about 6 years ago

  • Assignee set to Mathieu Pellerin - nIRV
  • Pull Request or Patch supplied changed from No to Yes

#8 Updated by Mathieu Pellerin - nIRV about 6 years ago

  • % Done changed from 0 to 100
  • Status changed from Open to Closed

#9 Updated by Dominique Lyszczarz about 6 years ago

  • Status changed from Closed to Reopened

Thanks for the fix but unexepected auto-classification still occurs after:
- changing color interpolation mode
- autocompute min max stats
- editing the color of a class
- editing label of a class
- changing layer rendering options like blending mode, brightness, saturation, contrast ...
- changing resampling options

It seems to me that classification should happen only and only if the user explicitly click on the classify button, this auto-classification mecanism is really disturbing and unexepected.

#10 Updated by Dominique Lyszczarz about 6 years ago

Note that this auto-classification only occurs at the first edit of any style option

#11 Updated by Mathieu Pellerin - nIRV about 6 years ago

  • Status changed from Reopened to Closed
  • Resolution set to fixed/implemented

Dominique,

OK, I've pushed a follow up commit to fix what I consider is the last remaining issue here, whereas colors changed through the tree widget could be overwritten.

As for the other raised issues, I think it might actually be desired behavior in most cases :) for e.g, yes, auto-computing min/max should trigger a classification. I can't reproduce the interpolation, blending, etc. issue here.

Thanks for raising this auto-classification issue to begin with.

I'll close this now, please open new ticket(s) with steps to reproduce if you still hit some problems that's not directly related to editing of the classification via the tree widget. Thanks.

#12 Updated by Dominique Lyszczarz about 6 years ago

Thank you very much Mathieu for your help, I'll try this in the next days.

#13 Updated by Alister Hood about 6 years ago

Hi guys, I still have a problem. I'm not sure if you want me to file this in a different ticket - rather than being "directly related to editing the classification via the tree widget", it is about loading a style file that was produced by editing the classification:

I get unwanted classification after doing "load style" when I click "OK" or "Apply" (in the main layer properties dialog). See the screenshots attached.

I don't know that I can test this in the style panel - I can't see a "load style" option there.

I think that if the intended behaviour is to always autoclassify, then there needs to be another classification mode called "manual".

#14 Updated by Alister Hood about 6 years ago

  • Status changed from Closed to Reopened

#15 Updated by Mathieu Pellerin - nIRV about 6 years ago

Alister, have you tried saving a style from a current build and loading that? That shouldn't cause unwanted auto classification. If the style is from QGIS 2.X, that s a different story.

#16 Updated by Alister Hood about 6 years ago

Thanks Mathieu - yes, that solves the problem, and at least in my case the style files are backwards compatible.

I only have 3 styles, so it isn't a problem for me to recreate them, but I imagine if this is necessary in the final QGIS 3 release it could be quite painful for some people, and should probably be documented prominently as a "known issue". Is it not possible to avoid?

#17 Updated by Mathieu Pellerin - nIRV about 6 years ago

  • Status changed from Reopened to Closed

Alister, glad to hear it works. Regarding the 2.X style imperfection, I don't intent to work on that. Feel free to file an issue, although I'm not sure it'd be worth the energy ;-P

#18 Updated by Alister Hood about 6 years ago

I don't think another ticket is necessary unless someone is likely to work on it.

I've noticed a related issue though.

Regardless of the "render type" (I first noticed it using "hillshade"), when you load a style using the "layer properties" dialog it initially renders using the zoomed in and out resampling options from the qml file, but the settings displayed in the dialog remain the same as they were before you loaded the style. Then when you click "apply" it is re-rendered with the settings from the dialog.

Shall I file another ticket for this?

#19 Updated by Alister Hood about 6 years ago

Also note that there is a similar long-standing issue with unwanted raster stretching: (3) at #4160

#20 Updated by Alister Hood about 6 years ago

Alister Hood wrote:

I don't think another ticket is necessary unless someone is likely to work on it.

I've noticed a related issue though.

Regardless of the "render type" (I first noticed it using "hillshade"), when you load a style using the "layer properties" dialog it initially renders using the zoomed in and out resampling options from the qml file, but the settings displayed in the dialog remain the same as they were before you loaded the style. Then when you click "apply" it is re-rendered with the settings from the dialog.

Shall I file another ticket for this?

Filed as #18153

Also available in: Atom PDF