BINARY data is not optimal

[I-Sokolov]

I am working with user request to support texture and was surprised (if I understood correct) EXPRESS ISO 10303-11-2000 and SDAI ISO 10303-24-2001 define to store BINARY data as text string like "%0101001100" - character per bit

136 binary_literal = '% ' bit { bit } . 119 bit = '0' | '1'

Is it really good way to store textures? -:)

Can we change to base 64 like we have for GUIDs?

[I-Sokolov]

I have looked into IFC4 example and confused. IFCBLOBTEXTURE(.T.,.T.,'TEXTURE',#58,$,'PNG',"089504E470D0.,,

According EXPRESS ISO 10303-11-2000 this is a text string in Universal Multiple-Octet Coded Character Set (UCS) and can not be interpreted as binary data

https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/annex/annex-e/tessellation-with-blob-texture.ifc

[aothms]

The p21 representation of binary as as follows:

HEX               = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                    "8" | "9" | "A" | "B" | "C" | "D" | "E" | "F" .
BINARY            = """" ( "0" | "1" | "2" | "3" ) { HEX } """" .

So it's a quoted (double quotes) hexadecimal string prefixed with [0-4] to store the remainder of integer division of the number of bits divided by four. That allows to differentiate between 0 -> 30 and 0000 -> 00.

So it's not as bad as the definition of literals in p11 (the schema) but in p21 (the model exchange) it's still a little bit worse than hexadecimal.

To me base64 does make a lot of sense for this.

My proposal would be to deprecate blob texture (because there is no way we can backwards-compatibility make these changes) but rather why not use IfcImageTexture for this purpose in the same way as glTF (and most modern web-based standards) with "data" URIs.

Something like the following:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAACAsAAAxpCAYAAACR81JGAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAuIwAALiMBeKU/dgAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAACAASURBVHic7N17sGRXdef5tfNWlUpC6AFCBoFBCHCAxNPltkegxy2pEBbiafv6hYUbDGqgDTJgI4Mb9zWPadu48aPb0ePu8LTd4Q7b6vHY3bYZ81SDRFEIGTUzwUzE+I+ZjomZmB5oZGwDUtW9ueePfJ3MPI+1Tu59zjr3fj8RlLiZv1x3V+rcqz/27+wMAgAAgME68acvv+DRo/2L9kQuiiIXhbh/iYSt4xLH58sonC9jOS4hnC8xTv4Z4nGJk3/GGC4IQc6TKBdEkfOCjC+IEs4TEQkyeazkW14oIkdLHn+0iBwRERmNxyfufflHv5jvbw0AAAAAAAAA2NSRvhcAAABwmN3y0Vsetbd35LL90fhyieGycYiPHU03/iWGS6LIRUHkIpn+L07+ebGIXDJ5bO/IvoiE6f8kjEQkTr6KIjHI5OvZP+Pin2H+9fTp6Z/TBAAAAAAAAADgAKMsAAAAkMjO3TtbX3nUNx4XtvYfK+PRZRLHl43D6HKR8WUSw2USwmUi8TKReLlIuExELntkPxyXECXG6XZ9DEsb9WHle8y+btzMnwZDVOat8wEAAAAAAAAAg0ZZAAAAQOG6P7vt0qNH9q6IIk8I49EVUeQJMcQrRiJPiCJXRJEnfEX+9skS5U...

In my view this is a completely backwards compatible usage of IfcImageTexture that's more efficient and inline with other modern graphic exchange formats.

[I-Sokolov]

@aothms, Thanks for clarification. It means I've looked into old standard.

[I-Sokolov]

Yes, proposal for base64 still actual

[I-Sokolov]

My proposal would be to deprecate blob texture (because there is no way we can backwards-compatibility make these changes)

Generally, we can recognize is this hex-string by double-quotes like "07BF" or single-quoted string with other encoding 'data:image/png;base64,iVBORw'

However I do not know how to specify it in EXPRESS:) Something like select but should not use type path when serialize.

[aothms]

or single-quoted string with other encoding 'data:image/png;base64,iVBORw'

However I do not know how to specify it in EXPRESS:)

I think that's the "beauty" of using the existing IfcImageTexture with IfcURIReference. Currently it states that IfcURIReference is based on RFC 3986, it seems to me that we should just make a documentation change to also include RFC 2397 https://datatracker.ietf.org/doc/html/rfc2397 So there isn't anything needed on the schema level.