Deprecate encoding of images using IFC (IfcPixelTexture)

[pipauwel]

I don't think that it is a role for IFC to encode images in a list of hexBinary digits. Is this used?

ENTITY IfcPixelTexture
 SUBTYPE OF (IfcSurfaceTexture);
	Width : IfcInteger;
	Height : IfcInteger;
	ColourComponents : IfcInteger;
	Pixel : LIST [1:?] OF IfcBinary;

It leads to this: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/annex/annex-e/tessellation-with-pixel-texture.ifc

#57= IFCPIXELTEXTURE(.T.,.T.,'TEXTURE',#58,$,256,256,4,("0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000","0FF000000", ...

This looks quite similar in XML and JSON. Any Graph-oriented scheme (RDF, LPG), this should not result in a List of hexBinary elements in any case (which it is in the OWL version of IFC); yet it should be stringified - or link to be made to a binary file (JPEG).

I suggest finding a means to reference a JPEG file or similar, which has such encoding embedded.

[TLiebich]

agree - today there are three ways to add an image, IfcPixelTexture, IfcBlobTexture and IfcImageTexture. In my view, it would be sufficient to restrict it to IfcImageTexture.

As a separate and related issue - one of the official exchange formats is *.ifcZIP. But there is no standard directory structure published, how to use it. Many other mainstream formats, like docx, are zip files with a directory structure.

So agreeing on (for file based exchange) a structure, like /img where are textures are stored (if not linked by a valid URL) should be the most common option to exchange a texture associated with the IFC file.

[janbrouwer]

So agreeing on (for file based exchange) a structure, like /img where are textures are stored (if not linked by a valid URL) should be the most common option to exchange a texture associated with the IFC file.

Interesting, a similar approach could also be used for external geometry

[jwouellette]

@TLiebich we should probably get verification from vendors that IfcImageTexture is sufficient and that IfcBlobTexture is not needed. Even checking beyond the usual suspects and include Hypar, Pix3D and others.

[berlotti]

Easier to parse/import. Meets the requirements of https://github.com/buildingSMART/NextGen-IFC/wiki/Ten-principles-for-a-future-IFC

Decision: Restrict it to IfcImageTexture. Allow to add pictures to an ifcZIP file. Create agreement/standard to structure the zip file. Look at BCF(zip) as well to make sure we have the same structure.