search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Deprecate encoding of images using IFC (IfcPixelTexture) #24

Open pipauwel opened 4 years ago

pipauwel commented 4 years ago

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 commented 4 years ago

agree - today there are three ways to add an image, IfcPixelTexture, IfcBlobTextureand 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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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.