Temporary InCanvas Graphics Image Colors

[3dimdev]

Hello all!

I was creating a video on the awesome new Temporary InCanvas Graphics API and had a question on the image colors.  As you can see, they are...off.  What are the rules the images, and colors, we can use in this feature?  Thanks!

[jeremy_tammik]

Great video, and nice mini-tutorial on using the new feature, and we all love Einstein anyway, don't we, so great marketing gag as well. I don't understand your exact question, though. Can you spell it out more precisely, please, so I can pass it on to the development team, if needed? Thank you!

[3dimdev]

Hello @jeremy_tammik,

Thank you for the kind words.  A little encouragement when starting a new venture is very appreciated!

When the image displays in a Revit view, the colors do not match those of the image on file.  It appears the tool may have a limited number of colors it can display.  Do we know what those colors are, so we can design our graphics accordingly?  I feel like there's a name for that, color palette, or color space, but I'm not familiar enough with image files to know for sure.

Thank you!

[RPTHOMAS108]

There is a sample in the SDK where this new feature is used:

...\RevitSDK\2022\Samples\InCanvasControlAPI\CS

It contains a bitmap image which suggests 'RGB 8 bits/channel'. The image is also quite small to represent a button icon (although they appear to have no limit on size according to your results).

Not tried the feature but was imagining these things are a bit like the clutter of icons you get in google earth when you zoom right out i.e. zoom scale unaware.

[3dimdev]

Hi @RPTHOMAS108,

I didn't think to look at the sample images, brilliant idea.  The original image is 24 bit, I saved it down to both 16 and 8 bit, but got similar results. 

At the 40 second mark of the video I mentioned you can see the sdk sample in action, a small part of it at least.  The images stay at their original size, independent of zoom level.

[RPTHOMAS108]

Very odd here is the results of a simple comparison:

Red 255,59,189 compare with (255,0,0)

Green 0,255,189 compare with (0,255,0)

Blue 0,59,255 compare with (0,0,255)

Black 0,59,189 compare with (0,0,0)

From above seems the 59 is being added to green and 189 to blue.

0011 1011 = 59
1011 1101 = 189

Seems to be something simple we are not doing or an error with this feature, only time and an explanation/clarification will tell.

[jeremy_tammik]

Thank you for your research. I passed on the question to the development team and hope they can clarify.

[jeremy_tammik]

OK... the answer may be elusive and tricky... response so far:

The creators of this feature can correct me, but I believe that this is just what legacy bitmap handling code does. It is quite difficult to explain from looking at the code and I am not aware of any documentation existing. This is not an error; there is quite a lot of code that intentionally does what it does.

[RPTHOMAS108]

Hello Jeremy

I don't recall any legacy of red being magenta and I go all the way back to Windows 3.1. Even 16 colours were the right 16 colours.

I was looking at this quite helpful description of the bmp file structure:
https://en.wikipedia.org/wiki/BMP_file_format

I found in summary that bitmaps are either:
Indexed in which each pixel location refers to a colour in a table
Non-indexed where each pixel location has a number of bytes that fully represent the RGB value individually

Tried both of those forms with the various associated colour depths (even tried run length encoded). I think 'no error' implies someone knows what format should be used or perhaps they can settle for the term 'known limitation'. It's a good feature so having it is better than not (even as is).

When all is said and done I open those various bmp file forms using Windows viewers/editors and the colours are consistent. I don't personally use Decals in Revit but I assume others find they have the right colours when they are used? 

[jeremy_tammik]

Yup, seems weird to me too... I'm continuing the internal discussion, hoping for further (colourful) illumination...

[tamas.deri]

Might be some conspiracy going on here, but 0-59-189 is the default RGB code for Selection Blue, in the graphic settings under the options. So it seems the images always have an overlay showing it as "selected". But why? 😄

 

[3dimdev]

I don't know about a conspiracy, but that is certainly intriguing! What's the saying, 'where there's smoke, there's fire.' And you and Richard have uncovered some blue smoke 🙂

[RPTHOMAS108]

@tamas.deri good observation however I find that the following settings do not correct the colourisation issue.

So still one for the x-files.

[jeremy_tammik]

Further feedback on this topic from the development team that may help understand the situation:

Working on some related code, I come across some oddities, which may explain the reported behavior. Our team's current project is performance enhancement for handling of bitmaps. This includes loading and drawing them. I find many processing cases in the legacy code and am struggling to understand the design. For example, "built-in" bitmap controls can come in 4, 8, 24, and 32 bpp (color). Some of them are meant to be greyscale and colorized, others are meant to use a reduced color palette with a special transparent color. These categories are not mutually exclusive! The 32-bit ones are especially strange, since the legacy code had no way of properly handling an 8-bit alpha channel. When in-canvas controls load external bitmaps, it is possible that an inappropriate handling case can be chosen. Some of my current efforts include an attempt to refactor and clean up the legacy internal code, but I am not sure that it will make sense to extend that work to the in-canvas control API, an area which is unfamiliar to me.

I am not sure if this has been mentioned, but 0,59,189 (decimal) is the default prehilite color.

[RPTHOMAS108]

Jeremy thanks for the update.

From my research at the time the bmp's you get from 'Paint' program are 24 bit only. The older 1, 4 and 8 were for indexed monochrome, 16 and 256 pallet. Greyscale is either 16 or 256  or perhaps 24 bit (non-indexed). 

My understanding was that indexing for fewer colours was reasonable due to the likely repetition of the colours in the image, so two or more pixel positions can refer to same index using less bytes in file overall. However when you get to a 24 bit image the likelihood is that the palette of indexed colours would be almost as large as the image grid size, in terms of colour variations and numbers of pixels i.e. no benefit of indexing.

The inclusion of alpha channel in 32 bit bmp is supported by the bmp format and can be displayed in Windows but largely is ignored it seems. This 32 bit format doesn't appear in Revit in-canvas control when you save in that format via System.Drawing.Imaging.PixelFormat.

e.g.:  PixelFormat.Format32bpp... formats.

There is slightly more work involved to create an indexed bitmap via System.Drawing so I just relied on imaging programs to save as those for testing (I checked 'Bit depth' under 'Details' of file properties in file explorer).

There is a section in the bmp file header that identifies the form of bitmap anyway, so should be no confusion.

There is also the notion of 'Color quantization' that occurs when converting to 8-bit colour display from 24 bit. The hypothesis being that since less bytes were reserved for blue they would be over populated. I think I was just clutching at straws at that point though since 0,59,189 is not random. I did try changing selection colours in Revit as noted above i.e. to see if selection colour was being added to colour but that had no effect on result.

The situation is very low priority for me however it would have consequences if a developer wanted to implement red, amber, green icon system etc.

[jeremy_tammik]

Thank you for your detailed research results! I passed them on back to the devteam and hope they find them useful as well.

[jeremy_tammik]

They reply:

This all parallels my own findings. Unfortunately, I don't believe that it is feasible to work around issues with in-canvas control API to display the bitmaps as expected in all cases. Fixing this situation may require commitment to a real project. For example, there is a regression test for the functionality and it does not seem to produce the correct colours.

[stefanome]

I tried exporting a bitmap to the 8 formats managed by Gimp: they all produced a bitmap with the same resolution, but fewer colors, with the exception of r8 which crashed and a8 which worked, but we only see the background.

They seem to be converted to some standard palette with a small number of colors.

Here is the original bitmap. The black part is transparent in the formats that allow it:

This is what I see in Revit. The first bitmap looks different from the others because it's highlighted because I was hovering the mouse over it when I got the snapshot. Without mouse hovering it would look identical to x1 and x8:

These are the formats in Gimp:

This is the code I used:

foreach (var item in new[] {("r5", 1), ("a1", 2), ("x1", 3), ("r8", 4), ("a8", 5), ("x8", 6)})
{
    var point = XYZ.BasisX * item.Item2;
    try
    {
        var data = new InCanvasControlData($"color {item.Item1}.bmp", point);
        mgr.AddControl(data, doc.ActiveView.Id);
    }
    catch
    {
        Debug.Print(item.Item1);
    }

    Utils.CreateTextNote(item.Item1, point + XYZ.BasisZ, doc);
}

[RPTHOMAS108]

I believe this issue is now resolved in 2023, not sure if it was resolved in a previous version between but I just tried an image in 2023 and the colours were correct.

[Ramoon_Bandeira]

Any Updates from this?
I created an image with the size of 32x32, with the background of (0,128,128), saved it as a bmp as stated in the documentation. 
But when i add it to revit, it is invisible.