GenICam Standard Features Naming Convention (SFNC) 2.8 was released as part of the GenICam Package 2026.07 published by the European Machine Vision Association (EMVA), alongside GenApi 3.5.1, GenTL 1.6, PFNC 2.4, GenTL SFNC 1.2, GenCP 1.3.1, GenDC 1.2, CLProtocol 1.2 and FWUpdate 1.0.1 [S2].
SFNC itself standardizes the name, type, meaning and use of more than 300 camera and application features, and the same feature names and GenApi XML model are reused across GigE Vision, USB3 Vision, CoaXPress, Camera Link and Camera Link HS transports [S3][S5]. EMVA distributes the standard free of charge and labels SFNC the part of GenICam that most end users actually see in their software UI [S7].
Where SFNC sits inside the GenICam stack
SFNC is one module inside a layered standard: GenApi defines the XML schema and the C++ reference implementation that turns a camera description file into a register read/write, SFNC dictates which feature names, types and value ranges appear in that XML, and GenTL/GenCP/CLProtocol carry the resulting commands to the hardware [S4][S5]. A practical example from the standard: a user setting Gain=42 lets generic software read the description file, map Gain to register 0x0815, and emit TransportLayer.WriteRegister(0x0815, 0x2A, 2) [S5].
SFNC also defines a minimum mandatory feature set for each transport: a camera that cannot expose the SFNC-mandated features at the lowest level will not be certified as GigE Vision, USB3 Vision or CoaXPress compliant [S5]. PFNC, the sibling standard, is layered on top of the same camera model to encode the pixel stream side of the pipeline [S10]. A compact summary of the family shipped in 2026.07: GenApi 3.5.1, GenTL 1.6, SFNC 2.8, PFNC 2.4, GenTL SFNC 1.2, GenCP 1.3.1, GenDC 1.2, CLProtocol 1.2, FWUpdate 1.0.1, with package SHA256 e74b8d982c3e7697399b03c254b6e8c596eddf0279959eba7de18734e279b64f [S2].
Feature categories defined by SFNC 2.8
SFNC groups features into named categories, and the table of contents in the SFNC 2.7 reference document lists: Device Control, Image Format Control, Acquisition Control, Analog Control, LUT Control, Color Transformation Control, Digital I/O Control, Counter and Timer Control, Encoder Control, Logic Block Control, Software Signal Control, Action Control, Event Control, User Set Control, Sequencer Control, File Access Control, and Source Control [S1].
Version 2.4 of the standard added a Lighting Control feature set, an early example of EMVA extending the naming surface beyond the camera body to peripheral hardware [S6]. The naming convention, not the underlying transport, is what allows an application to address, for example, a Digital I/O Control line on a GigE Vision camera and on a CoaXPress frame grabber using identical property names [S4][S5].
How SFNC drives driver compatibility in practice
Driver compatibility is the practical reason SFNC exists: a frame grabber vendor such as Active Silicon ships a GenTL Producer that exposes the grabber to any GenICam-compliant application, so a Camera Link or CoaXPress board presents the same property tree as a GigE Vision or USB3 Vision camera [S4]. EMVA states explicitly that "Software that complies with the standard and frame grabbers and cameras that also comply with the standard will always be compatible" [S4].
Hardware compatibility is achieved by supporting the standardized feature names, types and behaviours, not by porting SDK code per transport [S8]. The Common Vision Blox documentation repeats the same rule: "SFNC: The Standard Features Naming Convention defines the name, type and behaviour of the device settings. Hardware compatibility is accomplished by supporting the [SFNC] standard" [S8]. Practical consequence: a HALCON, Common Vision Blox or ActiveCapture application written against SFNC feature names will run against any compliant grabber with no source change beyond swapping the GenTL Producer [S4].
What SFNC 2.8 changes for integrators on 2026-10-04
SFNC 2.8 is the version to anchor a current driver compatibility review, because the 2026.07 package is the active public release EMVA lists on its downloads page [S2]. The previous public SFNC PDF is 2.7.1, dated 2022-02-01 and running 597 pages, which is still useful for historical feature names but should not be cited as the current revision [S1].
EMVA's 2.4 release demonstrated the review cadence: each new SFNC version adds feature sets (Lighting Control in 2.4 is the documented example) and revises existing categories, so integrators should diff their camera description XML against the current SFNC reference when qualifying a new vendor [S6][S9]. For industrial PC and embedded vision platforms, the rule is simple: pin the GenICam runtime to a single 2026.07-era package, refuse mixed GenApi/SFNC pairings from different package dates, and verify each camera's XML against the SFNC 2.8 feature tree before sign-off [S2][S8].
Comparison: SFNC behaviour across the main transports
SFNC rides on top of each transport's own compliance rules, and the table below lines the four most common cases up against the decision criteria an integrator actually checks: whether SFNC is mandatory, what carries the feature tree, and how a GenTL Producer factors in. [S4]
Per the EMVA and vendor sources reviewed: GigE Vision mandates SFNC, with the feature tree carried by the camera's GenApi XML [S5]; USB3 Vision mandates SFNC for the same reason, with The Imaging Source noting the same GenApi feature model and SFNC naming conventions are used regardless of Ethernet or USB transport [S3]; CoaXPress mandates GenICam compliance, so a CoaXPress frame grabber is exposed through a GenTL Producer and the SFNC feature tree [S4]; Camera Link is not SFNC-mandated at the protocol level, but a GenICam-compliant frame grabber with a GenTL Producer makes the SFNC surface available to the application [S4].
Across all four cases, the application reads and writes the same property names, so porting a vision application between transports is a matter of swapping the underlying GenTL Producer and the transport-specific driver package, not rewriting feature access code [S4][S5].
Limits, gotchas and what SFNC does not cover
SFNC is purely a naming and semantics layer: it standardizes what a feature is called and what its values mean, not how the data flows on the wire [S4][S5]. GenApi is the module that defines the XML schema, the C++ reference implementation and the mechanism for mapping properties to registers; the actual register read/write calls live in GenTL, GenCP or CLProtocol [S4][S5].
SFNC also has a hard lower bound: a camera that does not implement the mandatory minimum feature set for its declared transport (GigE Vision, USB3 Vision or CoaXPress) will fail compliance, and no application-level SFNC mapping can rescue it [S5]. PFNC, not SFNC, is the standard that encodes the pixel stream; conflating the two when reading an SFNC feature list is a common integration mistake [S10]. Finally, EMVA distributes the GenApi C++ reference implementation, but SFNC itself is just the naming document; vendors are free to ship their own GenApi implementation, so behavior on edge-case features should always be validated against the camera's XML rather than assumed from the SFNC PDF alone [S4][S5].
Sourcing, standards and traceability
The primary documents for an SFNC 2.8 review are: the EMVA SFNC 2.8 PDF, the EMVA GenApi 2.1.1 PDF, the EMVA GenTL 1.6 PDF, the EMVA GenCP 1.3.1 PDF, the EMVA CLProtocol 1.2 PDF and the PFNC 2.4 PDF, all bundled in the GenICam Package 2026.07 (SHA256 e74b8d982c3e7697399b03c254b6e8c596eddf0279959eba7de18734e279b64f) [S2]. EMVA hosts the standard at emva.org/standards-technology/genicam and provides an archive of previous releases for diffing [S2].
For a layered machine-vision line, integrators typically cross-reference SFNC feature names against the GenICam reference flyer distributed by EMVA and against the transport-specific compliance documents published by the AIA (GigE Vision, USB3 Vision) and the JIIA (CoaXPress) [S5]. The Imaging Source and Common Vision Blox both publish plain-language explanations of the same GenApi/SFNC/GenTL split that this article uses, which makes them useful sanity checks when qualifying a new vendor's XML [S3][S8]. Two trackable signals for the next review cycle: any new SFNC minor version EMVA posts to its downloads page, and any new transport compliance revision from AIA or JIIA that re-defines the SFNC mandatory minimum feature set [S2][S5].
Detailed specification references: pile driver, checking and testing apparatus, and construction machinery and equipment.
For related coverage, see PRV Sizing Chart Logic: Flow, Cv, Velocity and Pressure Drop.