Question

Difference bitshift between windows and linux?

  • 29 March 2022
  • 5 replies
  • 6 views
R
Rank
Badge

 

Hi,

 

I am using a pythoncaller in FME to convert the KML color from the linestyle (a string, hex ABGR) to a C# Color (ARGB 32 bits integer) (see workbench)

 

 

KML doc Colorstyle (https://developers.google.com/kml/documentation/kmlreference#colorstyle):

 

For example, if you want to apply a blue color with 50 percent opacity to an overlay, you would specify the following: 

<color>7fff0000</color>, where alpha=0x7f, blue=0xff, green=0x00, and red=0x00. (ABGR !)

 

 

 

With FME Desktop under Windows (2021.2.4), this works well.

=> 2022-03-29 18:00:28|  0.6| 0.0|INFORM|Attribute(32 bit integer)     : `line_color' has value `-16733441'

  

  

Running this workbench on the Linux FME server (docker install!) gives different results.

=> 2022-03-29 16:01:14|  0.2| 0.0|INFORM|Attribute(64 bit integer)     : `line_color' has value `4278233855'

 

I have some questions here:

 

1) Why does this happen?

2) How do I solve this?

3) Is there a more elegant and consistent way to accomplish this conversion? I do need to process the kml style element, and cannot rely on the fme_color attribute...

 

Thanks,

 

Richard.

1 Attachment

5 replies

david_r
Rank
Userlevel 4

It's actually exactly the same (bit for bit) underlying value, the difference is whether the bits are interpreted as signed or as unsigned, and whether they are interpreted as 32- or 64-bit integers.

See https://onlinetoolz.net/unsigned-signed#base=10&value=4278233855&bits=32

What happens if your use your result as-is?

R
Rank
Badge

Hi,

Thanks for the link (and the swift reply). I will look into this a bit.

I'm expecting a (signed) int both under windows and under linux, since this will be eventually be stored in Postgres (int4 datatype). However, under linux (fme server) the feature is silently dropped by the writer : "Value of attribute 'line_color' could not be converted to type 'int4'. Feature will be logged and skipped" . This results in an incomplete translation...

R
Rank
Badge

Hi,

Please find attached an adjusted version of the test workbench. This works both in FME Desktop (windows 2021.2.4) and on the FME Server (linux host / docker 2021.2.4). Questions remain, however:

 

  • What is causing this ? FME version change (e.g. upgraded python modules) or a platform change (from windows to linux)?
  • Is there documentation/articles that might help me spotting similar issues in advance?

 

Regards,

Richard.

1 Attachment
redgeographics
Rank
Userlevel 5
Badge +25

I'm wondering if it may be the Python code. If I understand correctly the requirement is simply to change the hexadecimal number to a decimal one, so I've tried that with a BaseConverter to convert from Base 16 to Base 10 and it yields 4294945280 on both Windows and Linux (FME Cloud)

david_r
Rank
Userlevel 4

Hi, 

Thanks for the link (and the swift reply). I will look into this a bit. 

I'm expecting a (signed) int both under windows and under linux, since this will be eventually be stored in Postgres (int4 datatype). However, under linux (fme server) the feature is silently dropped by the writer : "Value of attribute 'line_color' could not be converted to type 'int4'. Feature will be logged and skipped" . This results in an incomplete translation...

You can force the result to always be a 32-bit signed integer using the following technique in your PythonCaller:

>>> import ctypes
>>> color = 4278233855
>>> number = color & 0xFFFFFFFF
>>> print(ctypes.c_long(number).value)
-16733441

 

Reply


Community Stats

28,731
Posts
109,530
Replies
36,567
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.