On 22 April 2015 at 01:02, Matthew Hanson <[email protected]> wrote: > Hi, I was wondering if this fix could be backported to 2.8 (or even all > affected versions which is everything later than 2.2). We are currently > still running 2.2, but it's becoming more of a problem as plugins stop > working, dependencies get upgraded, etc.
It's been backported to 2.8 already, so will be included in 2.8.2. There's no plans for backports to earlier versions. Nyall > > > On Tue, Mar 17, 2015 at 12:15 PM, Matthew Hanson > <[email protected]> wrote: >> >> Thanks Nyall, >> >> Sorry for the delay, I was at FOSS4G last week. I tested this out and >> confirms it is working now as intended. Any clue on when it might be >> available in a 2.8 update? >> >> Thanks again! >> >> matt >> >> Matthew Hanson >> Applied GeoSolutions >> (603) 659-3363 x91 >> http://appliedgeosolutions.com >> [email protected] >> >> >> On Thu, Mar 5, 2015 at 11:24 PM, Nyall Dawson <[email protected]> >> wrote: >>> >>> On 5 March 2015 at 03:17, Matthew Hanson >>> <[email protected]> wrote: >>> > Hello, >>> > >>> > I filed a bug report on this some weeks ago: >>> > http://hub.qgis.org/issues/11573 >>> > >>> > But it hasn't gotten the required attention. It's a rather egregious >>> > bug, >>> > which currently is restricting us to QGIS v2.2, which is becoming more >>> > of a >>> > problem the more outdated it gets. >>> > >>> > In short, when using a floating point gain with integer images the >>> > datatype >>> > is not promoted, so you end up with an image that is rounded to the >>> > nearest >>> > integer. It's fairly common practice to store indices, like NDVI, as >>> > an >>> > Int16 with a gain of 0.0001 as it is half the space. But in QGIS, these >>> > images end up being rounded to mostly 0. >>> > >>> > The feature of auto-applying the gain is nice in practice, but without >>> > promoting the data type of the output it is counter-productive. It >>> > would >>> > be good to either revert this feature or properly promote the datatype. >>> > >>> > I'd be happy to do more digging and try fixing this and issue a PR if >>> > someone could get me started by pointing me in the general direction of >>> > the >>> > code responsible for this. >>> >>> >>> This should be fixed in master now - can you please test and confirm? >>> If so, I'll backport to 2.8. >>> >>> Nyall >> >> > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
