--- title: "Bayer vs RGB Camera Output: Samples, Components and Input Requirements" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/industrial-vision-bayer-samples-derived-rgb-components" last-updated: "2026-10-21" --- # Bayer vs RGB Camera Output: Samples, Components and Input Requirements Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. For a camera path using a Bayer color-filter array, three RGB components at an output position do not establish three directly sampled colors at that sensor position. Debayering estimates missing color components from the filtered samples. Compare raw Bayer and derived RGB offers against the representation the receiving application accepts, with the sample layout and processing scope declared. ## Follow the filtered sample into the RGB output A Bayer color-filter array places different color filters over different sensor positions. Basler's historical white paper How Machine Vision Cameras Help Medicine, sections 2.1 and 2.2 on printed page 4, describes a pattern with half green-filtered positions, one-quarter red-filtered positions and one-quarter blue-filtered positions. Debayering, also called demosaicing, interpolates missing color values to produce RGB information. At a red-filtered position, the source supplies a red-filtered sample rather than a directly measured red, green and blue triplet at that location. An RGB return fills the other component positions through reconstruction. This explanation concerns a Bayer acquisition path; an RGB output label alone does not identify a sensor architecture. Filter labels here do not assert ideal single-wavelength responses. The Linux video-format documentation makes the storage distinction concrete. Its four 8-bit Bayer formats store one sample per byte and distinguish arrangements including RGGB and BGGR. Its RGB24 format stores red, green and blue components in three consecutive bytes. Those definitions describe representations, rather than a particular camera's supported modes. References: [B1](https://assets-ctf.baslerweb.com/dg51pdwahxgw/4rZt23DYjn7fZbbicGgawR/efb7c0ece6b3494d9e546317c25adf13/BAS1611_WP_How_MV_Cameras_Help_Medicine.pdf), [K1](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-srggb8.html), [K2](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-rgb.html) ## CFA-47: 16 sampled values and 48 output components Consider original fictional case CFA-47. Stipulate a 4 x 4 Bayer array with the RGGB 2 x 2 pattern repeated across both dimensions. Rows one and three each read red, green, red, green. Rows two and four each read green, blue, green, blue. Every position supplies one 8-bit filtered value. The grid therefore contains 4 red-filtered values, 8 green-filtered values and 4 blue-filtered values: 16 sampled values in total. At one byte per stipulated sample, its sample payload is 16 bytes. Now stipulate a derived RGB8 return on the same 4 x 4 grid. Here RGB8 expressly means three 8-bit components per position, in red, green, blue order, with no alpha or per-pixel padding. There is no crop or resize. The return contains 16 x 3 = 48 component values and 48 bytes of component payload. Relative to the one sampled filter channel at each original position, the output needs two further color components: 16 x 2 = 32 additional component slots. Reconstruction supplies those slots; expanding the array has not collected 32 additional direct color measurements. Later processing may also change components corresponding to the originally sampled channels, so this is not a promise that the final RGB array contains 16 unchanged raw numbers beside 32 estimates. CFA-47 specifies no interpolation algorithm, boundary treatment or numeric pixel values. It is a counting example, not a capture, demosaicing test or image-quality result. All byte totals exclude row padding, packing, headers, compression and transport overhead. ## Derived RGB can be exactly the required input Reconstruction has a useful purpose: it provides color components at each output position for a consumer expecting an RGB image. An application designed for a declared derived RGB representation can correctly require that output. The word derived does not make the return false or unsuitable. The useful distinction is what the offered numbers represent. In CFA-47, a red component at a green-filtered position belongs to the reconstructed representation. Treating that component as a separate direct red-filtered observation at the same position would give it a provenance the source array does not supply. Neither representation wins simply by having more stored values. A consumer that needs the original filtered samples and their layout has a different input requirement from one that needs a processed RGB array. Raw sample count, RGB component count and evidence of fitness for an inspection task answer different questions. ## Compare two offers at the receiving application's input Suppose fictional offer A supplies CFA-47's 16 filtered values with their 4 x 4 dimensions, 8-bit sample description and correct RGGB layout. Offer B supplies the stipulated 48-component RGB return and identifies it as derived from that Bayer source. Both can be useful offers, but they stop at different representations. For a consumer specified to accept raw RGGB samples, A addresses the requested representation on paper. Its layout information matters: the same one-byte-per-position array does not explain which positions are red-, green- or blue-filtered without that correspondence. B's RGB delivery alone does not establish that the requested raw mosaic has also been supplied. For a consumer specified to accept the declared RGB8 return, B addresses the requested representation on paper. A leaves a conversion between its output and the consumer's input. The comparison needs to identify who supplies that conversion and what RGB representation results. Supplying raw data does not automatically mean that the downstream application's required input is complete. A third offer might supply both the raw mosaic and the derived RGB return with their correspondence documented. That broader delivery can serve both needs when required, but a buyer should identify which return the application actually consumes. Two filenames or a preview do not substitute for the sample layout and processing description. The application owner must connect the named output to its accepted input. These descriptions are proposals, not observed deliveries. References: [K1](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-srggb8.html), [K2](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-rgb.html) ## Make the layout and transformation scope explicit For a raw offer, ask the provider to identify the delivered sample type, bit depth, storage layout and color-filter arrangement at the delivered image origin. If the offered path changes the image geometry, its description needs to preserve the correspondence between the returned positions and the filter layout. The word raw alone should not stand in for a declaration of any processing already applied. For an RGB offer, identify the component order, bit depth, layout and color encoding required by the receiving application. The Linux documentation distinguishes RGB24 from BGR24 and from four-byte formats with alpha or padding. A general RGB label is less precise than the actual delivered format. Ask where Bayer-to-RGB conversion occurs and which processing implementation or revision defines the proposed return. Have the provider declare any further applicable transformations. Basler's paper discusses color calibration and gamma correction after interpolation; a debayered intermediate and a later corrected output need not describe the same numeric stage. That observation explains why provenance needs a processing scope, rather than prescribing camera settings or a calibration procedure. For CFA-47, the buyer request can be specific: identify whether the price covers the 16-sample raw RGGB array, the 48-component RGB8 array, or both. State each delivered layout and its color encoding where applicable, the processing implementation and revision, who performs any conversion, and whether the priced handoff occurs before or after it. A response that leaves a stage unnamed leaves part of the comparison unresolved. References: [B1](https://assets-ctf.baslerweb.com/dg51pdwahxgw/4rZt23DYjn7fZbbicGgawR/efb7c0ece6b3494d9e546317c25adf13/BAS1611_WP_How_MV_Cameras_Help_Medicine.pdf), [K1](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-srggb8.html), [K2](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-rgb.html) ## Use the byte comparison at its stated boundary CFA-47's 48 / 16 = 3 ratio compares only the two stipulated sample/component payloads. It does not establish three times the transfer time, processing cost, working memory or inspection accuracy. An offer that transfers raw samples and converts them later has a different delivery path from one that transfers derived RGB. Identify which representation crosses the boundary being priced before using either payload figure. Keep later representations separate as well. The related vision-transformer guide starts with supplied image channels and explains how a model creates patch embeddings and sequence positions. Here the earlier question is how the image channels were obtained. DICOM retrieval and OME-TIFF plane mapping address other input questions: which pixels were supplied and which image plane they identify. ## Scope a separate physical installation when needed If the selected vision-computing equipment also needs receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service is a route to discuss that physical package. Use the related service and project inquiry with a nonconfidential equipment, site, connection and physical handoff outline to establish scope and availability. Camera processing, image interpretation and application acceptance remain with the appointed imaging and software providers. References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment) ## Primary sources - [B1 — Basler BAS1611: How Machine Vision Cameras Help Medicine - color sampling and RGB calculation](https://assets-ctf.baslerweb.com/dg51pdwahxgw/4rZt23DYjn7fZbbicGgawR/efb7c0ece6b3494d9e546317c25adf13/BAS1611_WP_How_MV_Cameras_Help_Medicine.pdf). Checked 2026-10-20. Historical explanation on printed page 4, sections 2.1-2.2: Bayer filter proportions, interpolation from 8-bit samples to 24-bit RGB, and subsequent color-processing stages. Used for the mechanism, not current camera compatibility, spectral specifications, medical suitability or measured performance. - [K1 — Linux kernel documentation: 8-bit Bayer formats - RGGB, GRBG, GBRG and BGGR](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-srggb8.html). Checked 2026-10-20. Defines one-byte filtered samples and distinct Bayer arrangements. Its displayed byte-order example is BGGR; CFA-47 explicitly stipulates RGGB and supplies its own arithmetic. No camera-mode support is inferred. - [K2 — Linux kernel documentation: RGB formats - 8 bits per component and RGB24 byte order](https://docs.kernel.org/userspace-api/media/v4l/pixfmt-rgb.html). Checked 2026-10-20. Introduction and section 2.5.2 distinguish component order, bit depth, alpha/padding and three-byte RGB24. CFA-47's RGB8 definition is explicit; other RGB formats need their own payload accounting. - [L1 — Leviathan Systems: Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Describes equipment receiving, rack integration, onsite deployment and cabling within an agreed physical package, with subsequent system responsibilities separately assigned. ## Related Leviathan resources - [How supplied image channels become vision-transformer patches](/articles/vision-transformer-patch-grid-input-sequence) - [DICOM discovery, retrieval and the required pixel input](/articles/healthcare-ai-dicom-metadata-versus-pixel-input) - [OME-TIFF plane identity across channel, Z and time axes](/articles/microscopy-ai-ome-tiff-plane-axis-mapping) - [Complete Physical Deployment](/services/turnkey-gpu-deployment) - [Discuss a separate vision-computing equipment installation](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Findustrial-vision-bayer-samples-derived-rgb-components) ## Does the selected computing equipment need physical installation? Share a nonconfidential equipment, site, IT connection and physical handoff outline to discuss installation scope, requirements and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/industrial-vision-bayer-samples-derived-rgb-components)