[Qgis-developer] Bug with floating point gains

[Nyall Dawson]

On 22 April 2015 at 01:02, Matthew Hanson
<mhanson at appliedgeosolutions.com> 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
> <mhanson at appliedgeosolutions.com> 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
>> mhanson at appliedgeosolutions.com
>>
>>
>> On Thu, Mar 5, 2015 at 11:24 PM, Nyall Dawson <nyall.dawson at gmail.com>
>> wrote:
>>>
>>> On 5 March 2015 at 03:17, Matthew Hanson
>>> <mhanson at appliedgeosolutions.com> 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
>>
>>
>