[gdal-dev] Using bitwise & with muparser VRT expressions

[Hugh Graham]

Many thanks to all - this is very helpful.

Dan, I'll explore some of these other options you mention. In this new PR,
is it the case that by switching to using theLLVM dialect these operators
will automatically be recognised? I suppose if this is the case then
explicitly adding the operator might not strictly be necessary...

Also, I appreciate the clarification that values are always converted to
float during the arithmetic, I agree, Javier, that in this case a bitwise
operation is a bit strange... I suspect it will however be quite a valuable
application of such expressions, given the popularity of bit masks in
various imagery collections.

I'll keep experimenting but again really appreciate the help and looking
forward to testing out new related features.

Hugh


On Thu, 4 Dec 2025 at 13:53, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:

> If I remember correctly, the arithmetic is done with floating 64b numbers,
> right? Doing bitwise operations there sound a bit (pun intended) strange.
> I know a bit portion of images used are RGB (byte images), there bitwise
> operatios are fine.
>
> On Wed, 3 Dec 2025 at 21:14, Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>> I see there's a mu::ParserInt class in
>> https://github.com/beltoforion/muparser/blob/master/include/muParserInt.h
>> , that we don't use in GDAL. A bit strange it wasn't mentionned in [1].
>> Perhaps because of this comment: "This version of the parser handles only
>> integer numbers. It disables the built in operators thus it is slower than
>> muParser. Integer values are stored in the double value_type and converted
>> if needed."
>> Le 03/12/2025 à 21:07, Daniel Baston via gdal-dev a écrit :
>>
>> Hugh,
>>
>> My read of this discussion [1] is that bitwise operators are not
>> supported and we would need to add them as a GDAL extension. This is pretty
>> easy to do: see [2]. Alternatively, bitwise operators are probably
>> supported by the ExprTk expression parser [3] (supported by GDAL) or this
>> pull request [4].
>>
>> Dan
>>
>> [1]
>> https://github.com/beltoforion/muparser/discussions/154#discussioncomment-13104418
>> [2] https://github.com/OSGeo/gdal/pull/13187/files
>> [3] https://www.partow.net/programming/exprtk/
>> [4] https://github.com/OSGeo/gdal/pull/13470
>>
>> On Wed, Dec 3, 2025 at 2:58 PM Hugh Graham via gdal-dev <
>> gdal-dev at lists.osgeo.org> wrote:
>>
>>> Hi,
>>>
>>> I am using VRT muparser expressions for bitwise operations when creating
>>> masks and wanted to understand why I can't get the *bitwise & *operator
>>> working? My current solution is to use fmod which is fine (and I think
>>> equivalent) but using "&" would be convenient and a bit easier to read...
>>>
>>> To illustrate, the following file works:
>>>
>>> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-fmodmask-vrt
>>>
>>> the expression used here is:"(fmod(Fmask, 16) >= 8) || (fmod(Fmask, 8)
>>> >= 4) ? 0 : 1"
>>>
>>> ```
>>> gdal convert "/vsicurl/
>>> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-fmodmask.vrt"
>>> "test.tif"
>>> ```
>>>
>>> However, the following file fails:
>>>
>>> https://gist.github.com/h-a-graham/6db16e70e064ae8173f1052537c59761#file-fmask-bitmask-vrt
>>> the expression parsed as: "((Fmask & 8) > 0 || (Fmask & 4)
>>> > 0) ? 0 : 1" in the XML but provided as (to my xml parser):
>>>
>>> "((Fmask & 8) > 0 || (Fmask & 4) > 0) ? 0 : 1"
>>>
>>> ```
>>> gdal convert "/vsicurl/
>>> https://gist.githubusercontent.com/h-a-graham/6db16e70e064ae8173f1052537c59761/raw/c48b15852bcc7c5252cae4b906c14b9a3205a33d/fmask-bitmask.vrt"
>>> "test.tif"
>>> 0...10...20..ERROR 1: Unexpected token "& 8) > 0 || (Fmask & 4) > 0) ? 0
>>> : 1 " found at position 8.
>>> ```
>>>
>>> So, is using "&" possible, or should I just stick with fmod and not
>>> worry about it?
>>>
>>> Any help would be much appreciated.
>>>
>>> Hugh
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>> _______________________________________________
>> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251204/db496a4f/attachment.htm>