READ_IMAGEF2D(3clc)
π READ_IMAGEF (2D) π
okay bestie, welcome to the read_imagef page from the OpenCL manual (that's the 3clc manual section, iykyk) π«Ά this is the 2D girlie edition and she is serving.
β¨ NAME β¨
read_imagef_(2D) β do an element lookup in the 2D image object, and get floating-point values back. that's it. that's the whole vibe. π
float4 read_imagef(image2d_t image, sampler_t sampler, int2 coord);
float4 read_imagef(image2d_t image, sampler_t sampler, float2 coord);
float4 read_imagef(image2d_t image, int2 coord);
float4 read_imagef(image2d_array_t image, int4 coord);
float4 read_imagef(image2d_array_t image, sampler_t sampler,
int4 coord);
float4 read_imagef(image2d_array_t image, sampler_t sampler,
float4 coord);
πΈ DESCRIPTION πΈ
so for the forms that take an image2d_t, you use the coordinate (coord.x, coord.y) to do an element lookup in the 2D image object that image is pointing at. slay. β¨
for the forms that take an image2d_array_t, you use coord.xy to do an element lookup in the 2D image identified by coord.z, inside the 2D image array specified by image. yes bestie, coord.z is literally the "which slice of the array" girlie. π
the samplerless read image functions behave exactly like the corresponding read image functions that take integer coordinates and a sampler with filter mode set to CLK_FILTER_NEAREST, normalized coordinates set to CLK_NORMALIZED_COORDS_FALSE, and addressing mode set to CLK_ADDRESS_NONE. no cap, that's the whole deal.
now the returns, because this is the part everyone asks about:
read_imagefreturns floating-point values in the range[0.0... 1.0]for image objects created withimage_channel_data_typeset to one of the predefined packed formats, orCL_UNORM_INT8orCL_UNORM_INT16. πread_imagefreturns floating-point values in the range[-1.0... 1.0]for image objects created withimage_channel_data_typeset toCL_SNORM_INT8, orCL_SNORM_INT16.read_imagefreturns floating-point values for image objects created withimage_channel_data_typeset toCL_HALF_FLOATorCL_FLOAT.
π¨ okay important one. theread_imagefcalls that take integer coordinates must use a sampler with filter mode set toCLK_FILTER_NEAREST, normalized coordinates set toCLK_NORMALIZED_COORDS_FALSE, and addressing mode set toCLK_ADDRESS_CLAMP_TO_EDGE,CLK_ADDRESS_CLAMPorCLK_ADDRESS_NONEβ otherwise the values returned are undefined. undefined behaviour is NOT the moment, bestie. π
π¨ also: values returned byread_imageffor image objects withimage_channel_data_typevalues not specified in the description above are undefined. don't do it. π
π NOTES π
general info about the read_image* functions, coming right up π§
the built-in functions defined in this section can only be used with image memory objects. an image memory object can be accessed by specific function calls that read from and/or write to specific locations in the image. iconic behaviour honestly.
image memory objects that are being read by a kernel should be declared with the accessQualifiers(3clc) qualifier. write_image calls to image memory objects declared with the accessQualifiers(3clc) qualifier will generate a compilation error. image memory objects that are being written to by a kernel should be declared with the accessQualifiers(3clc) qualifier. read_image calls to image memory objects declared with the accessQualifiers(3clc) qualifier will generate a compilation error. and read_image and write_image calls to the same image memory object in a kernel are not supported. pick a lane girlie π
the read_image calls return a four component floating-point, integer or unsigned integer color value. the color values returned by read_image are identified as x, y, z, w, where x refers to the red component, y refers to the green component, z refers to the blue component and w refers to the alpha component. π
the channel mapping table (as a list, because tables said no π )
so here's how the number of channels of an image element maps to the components in the float4, int4 or uint4 vector data type, for the color values returned by read_image{f|i|ui} or supplied to write_image{f|i|ui}. the unmapped components will be set to 0.0 for red, green and blue channels, and will be set to 1.0 for the alpha channel.
- channel order
CL_R,CL_Rxβ components(r, 0.0, 0.0, 1.0) - channel order
CL_Aβ components(0.0, 0.0, 0.0, a) - channel order
CL_RG,CL_RGxβ components(r, g, 0.0, 1.0) - channel order
CL_RAβ components(r, 0.0, 0.0, a) - channel order
CL_RGB,CL_RGBxβ components(r, g, b, 1.0) - channel order
CL_RGBA,CL_BGRA,CL_ARGBβ components(r, g, b, a) - channel order
CL_INTENSITYβ components(I, I, I, I) - channel order
CL_LUMINANCEβ components(L, L, L, 1.0)
a kernel that uses a sampler with the CL_ADDRESS_CLAMP addressing mode with multiple images may result in additional samplers being used internally by an implementation. if the same sampler is used with multiple images called via read_image{f|i|ui}, then it is possible that an implementation may need to allocate an additional sampler to handle the different border color values that may be needed, depending on the image formats being used. π΅βπ« these implementation allocated samplers will count against the maximum sampler values supported by the device, given by CL_DEVICE_MAX_SAMPLERS. enqueuing a kernel that requires more samplers than the implementation can support will result in a CL_OUT_OF_RESOURCES error being returned. the math is mathing and the samplers are sampler-ing. π
π SPECIFICATION π
OpenCL Specification[1]
π SEE ALSO π
π AUTHORS π
The Khronos Group
Β©οΈ COPYRIGHT Β©οΈ
Copyright Β© 2007-2011 The Khronos Group Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Materials.
π NOTES (yes, again, the footnote one) π
OpenCL Specificationpage 292, section 6.12.14 - Image Read and Write Functions
and that's the whole page, bestie!! π₯³ this was brought to you by The Khronos Group, dated 01/14/2021, living under the header READ_IMAGEF (2D)(3clc) β go read your images, but only with the right sampler, fr fr πβ¨
π¦ where this page comes from
- ubuntu jammy: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- ubuntu noble: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms