Bug report #6360
no data value (defined in the "transparency" tab of the raster property window) not applied to displayed ECW raster on qgis master
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: |  Radim Blazek | ||
| Category: | Rasters | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15628 |
Description
QGIS master, i.e. what will become 2.0, has an issue whereas it is not applying the no data value defined by the user in the transparency tab of the raster property window. See the screenshot for a more graphic explanation.
This is a big problem when displaying multi-band rasters. In the attached screenshot, a true-color rendering of landsat imagery is filed with holes (highlighted in bright pink background color / white) when rendering hits a point with either of the 3 bands having null / no data.
Setting the no data value to 0, 1, 2, 3, etc. doesn't file the holes.
I'm seeing this on a ECW raster, not sure whether the problem is confined to the ECW raster provider or is affecting a greater set of raster formats.
History
#1
Updated by Giovanni Manghi over 11 years ago
- Operating System deleted (
all) - Status changed from Open to Feedback
- Target version set to Version 2.0.0
Is this a regression in master since 1.8?
#2
Updated by Mathieu Pellerin - nIRV over 11 years ago
Yes and no:
- Yes it's a regression as setting a value other than 0 with qgis 1.8 does have a visible impact on the holes while setting a value other than 0 with qgis master doesn't do anything;
- No, as problem goes beyond the above regression. While things are somewhat better under qgis 1.8, it's still not perfect. More importantly, QGIS - under both 1.8 and master - doesn't properly deal with 0 as no data value when rendering rasters.
#3
Updated by Giovanni Manghi over 11 years ago
- Priority changed from High to Severe/Regression
nirvn - wrote:
Yes and no:
- Yes it's a regression as setting a value other than 0 with qgis 1.8 does have a visible impact on the holes while setting a value other than 0 with qgis master doesn't do anything;
ok, then is a regression
- No, as problem goes beyond the above regression. While things are somewhat better under qgis 1.8, it's still not perfect. More importantly, QGIS - under both 1.8 and master - doesn't properly deal with 0 as no data value when rendering rasters.
this is a known issue for qgis up to 1.8, and in the next release it MUST be fixed (if not already)
#4
Updated by Mathieu Pellerin - nIRV over 11 years ago
Giovanni, I'll soon attach a cropped version of the ECW (currently +/- 70mb) I used in the above screenshot for devs to work on resolving the issue.
#5
Updated by Radim Blazek over 11 years ago
The user defined no data value was not applied correctly in master until 3032f71666.
But, I think that it is misunderstanding, the no data value set in transparency tab does not mean that the value will be assigned to original data source pixels without data. In contrary, it means that the pixels with the values specified will be treated as no data.
It is correct that pixels with no data value (in at least one band) are rendered fully transparent.
You are probably asking for a new feature (which was already discussed in list): a possibility to assign a color to no data values. Please fill a more clear issue and close this.
#6
Updated by Mathieu Pellerin - nIRV over 11 years ago
- Resolution set to fixed
- % Done changed from 0 to 100
- Assignee set to Radim Blazek
- Status changed from Feedback to Closed
Radim, I've changed status to closed and resolution to fixed as this issue did cover a bug which you fixed (thanks!) in commit 3032f71666.
For the record, changing no data value to -1 fixed true-color landsat raster, wouhou! I was totally misunderstanding this no data value.
That said, I think this episode did reveal another real issue, that is a semantic problem with the "no data value" label. While I'm not a native English speaker (French being my mother tongue), I get the sense the label is at best obscure, and in my case was misleading. I read the label as meaning "value that should be applied to no data".
Should I open a new ticket with the above raised semantic issue? I'd think a label along the lines of "value used as no data" would be much better!
Finally, I believe the current QGIS behavior with regards to automatically setting the above value is wrong. What happened in my case highlights a real problem:
- open a true-color (3-band RGB) landsat imagery for the first time in QGIS
- QGIS automatically assigns 0 as no data value
- rendering of true-color raster broken when any of the R, G, or B band has the value 0; that's a huge problem in itself, and is just nasty when rendering water areas (as seen in attached screenshot) which often has the red band = 0
It might be good for QGIS to get a bit wiser on this one. Maybe when QGIS opens a 3-band raster, it should go down the "safe" road and assume it'll be a RGB raster and refrain from setting 0 as value for no data.
#7
Updated by Mathieu Pellerin - nIRV over 11 years ago
- File after-commit-cannot-change-0.png added
- Status changed from Closed to Reopened
- % Done changed from 100 to 50
- Resolution deleted (
fixed)
Oups, re-opening as above commit made the situation somewhat worse.
Your commit allowed to specify an additional no data value, which is useful, but now prevents user from changing the default data for no value (which is a regression from 1.8).
Not being able to change 0 as default no data value for an 3-band RGB raster is pretty bad (see attached screenshot).
#8
Updated by Radim Blazek over 11 years ago
The problem is that we need at least one nodata value, if a layer is reprojected, we need to represent pixels outside original extent as nodata, for example. That was the reason why I allowed additional values only.
In your example, if data type is byte (0-255), and you specify nodata -100, it cannot be used as nodata in reprojection because it does not stay within 0-255.
If it may happen, that original (from source data given by GDAL) nodata value is wrong and it has to be optionally treated as regular value, I see as only possibly solution to always internally represent rasters with wider data type so that internal nodata value is guaranteed to be outside the original data range.
#9
Updated by Mathieu Pellerin - nIRV over 11 years ago
I see. With QGIS master (prior to commit 3032f71666), I could manually change nodata value via editing of .xml to -1 and get a hole-free rendering of the raster. I feel like your last paragraph (which must have been the way things were) might be the safest option here. Is your more recent commit 35d869cf doing that?
#10
Updated by Mathieu Pellerin - nIRV over 11 years ago
Always representing with wider data type allows -1 to be used, but we probably also need a way to change the default nodata value to a different value. That is, a friendlier way than hand-editing the <raster_name>.xml file :)
#11
Updated by Radim Blazek over 11 years ago
It is now possible to disable original nodata value.
I think that everything should work OK.
#12
Updated by Mathieu Pellerin - nIRV over 11 years ago
- Status changed from Reopened to Closed
- % Done changed from 50 to 100
Closing this bug after verifying the problems raised in this issue have all been fixed by Radim's commits.
For the record, Radim's work surrounding this issue led to:
- re-adding cutstom nodata value feature (fixing regression from 1.8)
- nodata value applied to all bands
- separating nodata value provided by raster vs user-defined nodata value
- possibility to deactivate nodata value provided by raster
Kudos Radim.