no data value (defined in the "transparency" tab of the raster property window) not applied to displayed ECW raster on qgis master

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)
Original Redmine Issue: 6360
Affected QGIS version: master
Redmine category:rasters
Assignee: Radim Blazek

---

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.

---

• raster-nodata-error.png (Mathieu Pellerin - nIRV)
• after-commit-cannot-change-0.png (Mathieu Pellerin - nIRV)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Is this a regression in master since 1.8?

---

• operating_system was changed from all to
• status_id was changed from Open to Feedback
• fixed_version_id was configured as Version 2.0.0

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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)

---

• priority_id was changed from High to Severe/Regression

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

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.

[qgib]

Author Name: Radim Blazek (@blazek)

---

The user defined no data value was not applied correctly in master until 3032f71.

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.

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

Radim, I've changed status to closed and resolution to fixed as this issue did cover a bug which you fixed (thanks!) in commit 3032f71.

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.

---

• resolution was changed from to fixed
• done_ratio was changed from 0 to 100
• assigned_to_id was configured as Radim Blazek
• status_id was changed from Feedback to Closed

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

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).

---

• 4895 was configured as after-commit-cannot-change-0.png
• status_id was changed from Closed to Reopened
• done_ratio was changed from 100 to 50
• resolution was changed from fixed to

---

• after-commit-cannot-change-0.png (Mathieu Pellerin - nIRV)

[qgib]

Author Name: Radim Blazek (@blazek)

---

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.

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

I see. With QGIS master (prior to commit 3032f71), 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 35d869c doing that?

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

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 :)

[qgib]

Author Name: Radim Blazek (@blazek)

---

It is now possible to disable original nodata value.

I think that everything should work OK.

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

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.

---

• status_id was changed from Reopened to Closed
• done_ratio was changed from 50 to 100