node->Info().Screen().color returns wrong RGB String

[thalesl]

Hi community. Thanks for your attention!

I am reporting a minor problem when I recover the background color (RGB string) of the nodes ("interior color" property).
I can read the interior color, but SMILE returns a different color, both on Windows as Linux.

Fortunatelly, I could trace the problem (I think!), so I wrote an example.

The first code window contains the xml data for the variable (only the relevant stuff).
The second contains the code.

Code: Select all

          <node id="Animals">
                  <name>Animals</name>
                  <interior color="6789ab" />
          </node>

Code: Select all

#include "smile.h"
#include <iostream>
int main() {
    using namespace std;
    DSL_network net;

    const char *file = "/home/thalesl/projetos/CTEEP/gestin/unix/example.xdsl";
    net.ReadFile(file, DSL_XDSL_FORMAT);

    int nodeId = net.FindNode("Animals");
    DSL_node *node = net.GetNode(nodeId);

    cout << "Returned color (hex): " << hex << node->Info().Screen().color << endl;
    cout << "Expected color (hex): " << "6789ab" << endl;

    return 0;
}
/*
Returned color (hex): ab8967
Expected color (hex): 6789ab
*/

All the variables tested showed the following symptom: the bytes corresponding to the red and blue color are inverted.

Did someone face this problem too?

Best Regards,
Thales Lange.

[Martijn]

Hi Thales,

I'm looking into the problem.
Just to double check, if you load the network in GeNIe, are the colors then as you expect?

Best,

Martijn

[thalesl]

Hi Martijn. Thanks for your reply.

About the color problem, I prefer to attach some images to describe the problem.

The first picture shows the Bayesian Network in Genie, which contains three subgraphs.
Sorry about the name of the variables, they are written in Portuguese.

genie.png (184.45 KiB) Viewed 7521 times

The second picture shows the same Bayesian Network (the same file) in my own software.
As you can notice, the colors are different in two subgraphs and the drawings are a little different too.

wrong_color.png (30.32 KiB) Viewed 7521 times

The third picture shows again my software, but in this case I inverted the bytes of the red and blue colors.

correct_color.png (35.09 KiB) Viewed 7521 times

After the pictures comparison, you can notice that the variables of the PVI subgraph are correct in all pictures.
The reason is the chosen color (green) and their RGB String (#ccffcc).
This RGB string has the same bytes for red and blue colors (#cc). Then, their inversion doesn't change the color.

Best Regards,
Thales Lange.

[jonnie]

So what you mean is, they're swapped. Inverted would mean their single bits are all flipped. #cc would result in #33.
I guess that's simply the way Smile stores its color values into an integer variable. Simply write a function or class for conversion

[Martijn]

Thales,

I have tried it myself and have seen the same result.
I can't say yet if this is by design or a bug, the person that is most familiar with this code is still on holiday.
I have added a ticket to our internal bug tracking system and once I know more I'll report back here in this thread.

Best,

Martijn

[thalesl]

Jonnie, thanks for correct me. The sentence "they're swapped" is correct.

Martijn, thanks for your reply.

Best Regards,
Thales Lange.

[marek [BayesFusion]]

We've added this to the Issue Tracker and will have a look at this in the near future. Because it is not a critical issue, please do have some patience with us here.
Cheers,

Marek

[shooltz[BayesFusion]]

Just to clarify: the color (RGB) stored by C++ SMILE is a Windows COLORREF value, which has the red component at least significant byte. We don't make any guarantees on how this value will look when converted to a string.

SMILE's Java and .Net wrappers use the data types specific to the environment - java.awt.Color and System.Drawing.Color, respectively. In that case we perform the conversion from integer.