I'd like to calculate 2592x1944 YUV422 one frame image size from camera.
I've already seen that https://en.wikipedia.org/wiki/YUV
But I'm not sure whether the below calculation is right or not.
and
YUV444 3 bytes per pixel (12 bytes per 4 pixels)
YUV422 4 bytes per 2 pixels ( 8 bytes per 4 pixels)
YUV411 6 bytes per 4 pixels
YUV420p 6 bytes per 4 pixels, reordered
with meaning of hsync length.
As I know, 2592x1944 YUV422 one frame image size which can be calculated such as
Total number of pixels in a frame = 2592*1944 = 5038848 Pixels
Total number of bytes in a frame = 5038848 *2=10077696 Bytes
Does it mean that 1 hsync real size(length)# YUV422 is 2592*2 and changeable by YUV444, YUV422, YUV411, YUV420 ?
Your calculation is right if we assume 8 bits color depth.
Y needs 2592x1944 x8bits = 5038848 bytes
U needs 2592x1944 /2 x8bits = 2519424 bytes
V needs 2592x1944 /2 x8bits = 2519424 bytes
TOTAL = 10077696 bytes for YUV422, 8bits color
I don't get the question regarding hsync.
A nice explanation of YUV422 https://www.youtube.com/watch?v=7JYZDnenaGc,
and color depth https://www.youtube.com/watch?v=bKjSox0uwnk.
Related
I remember when using intel ipp, the width of image has to be aligned with 16 byte boundary. which means if width % 16 != 0, need fill a few bytes at the end of each row.
Does opencv has this kind of requirement?
I'd like to calculate camera bandwith. Main question: "How can transmit GigE more than 1 Gbit/s data ?"
----- Camera specs --------
Resolution (HxV) :2590 px x 1942 px
Frame Rate : 14 fps
Mono/Color : Color
Interface : GigE
Pixel Bit Depth : 12 bits
---- Bandwith calculation ---
bit/s = Resolution x ChannelSize(Color) x fps x BitDepth
bit/s = 2590 x 1942 x 3 x 14 x 12
bit/s = 2.535.009.120
Gbit/s = 2.3609
Where am I wrong?
Thanks a lot
Either the data from the camera is compressed already or the pixels are laid out in a Bayer Pattern so there's only 12 bits per pixel, not 36.
can any one tell that ,how many number of pixels are present in RGB type of image is it height * width or height *width * channels.
I want to calculate bit per pixel(bpp) of an image so i need this information.
The number of pixels is simply:
height × width
It's indepenent of whether the color of each pixel is composed from a single channel or from several channels.
If your image has three channels, e.g. a separte one for red, green and blue, each using an 8 bit value for each pixel, then you have to add them to get the bits per pixel (bpp) value. In the example, it would be:
bpp = 3 × 8bit = 24bit
But it does not affect the number of pixels.
I am learning WebGL and I want to know the formula of calculating vram usage size from a image(jpg/png).
Thanks.
jpg or png make no difference. They are expanded to uncompressed data before being uploaded to WebGL. There is no perfect way to compute the vram usage because what the driver actually stores internally is unknown but you can estimate.
bytesPerPixel * width * height
Where bytesPerPixel is derived from the format/type you pass to gl.texImage2D as in
gl.texImage2D(level, internalFormat, width, height, 0, format, type, data)
or
gl.texImage2D(level, internalFormat, format, type, img/canvas/video)
In WebGL2 you'd compute from the interalFormat passed to the same function (see table here)
for WebGL1 common values are
format type bytesPerPixel
------------------------------------------------------
gl.RGBA gl.UNSIGNED_BYTE 4
gl.RGB gl.UNSIGNED_BYTE 3
gl.LUMIANCE gl.UNSIGNED_BYTE 1
gl.ALPHA gl.UNSIGNED_BYTE 1
gl.LUMIANCE_ALPHA gl.UNSIGNED_BYTE 2
gl.RGB gl.UNSIGNED_SHORT_5_6_5 2
gl.RGBA gl.UNSIGNED_SHORT_4_4_4_4 2
gl.RGBA gl.UNSIGNED_SHORT_5_5_5_1 2
gl.RGBA gl.FLOAT 16 (if enabled)
Then, if you upload a mipmap or generate one with gl.generateMipmap you need to multply by about 33%. Example, a 16x16 pixel texture will have
16x16 + 8x8 + 4x4 + 2x2 + 1x1 = 340
16x16 = 256
256 * 1.33 = 340.
But like I mentioned it's up to the driver. Some (most drivers?) will expand RGB to RGBA as one example. Some drivers will expand the various 2 byte per pixel RGB/RGBA formats to 4 bytes.
I am using libpng to convertraw image data (3 channel, 8 bit, no metadata) to PNG and store it in a buffer. I now have a problem to allocate the right amount of buffer space for writing the PNG data to it. It is clear to me, that the compressed data might be larger than the raw data (cf. the overhead for a 1x1 image)
Is there any general rule for an upper margin of the compressed data size with respect to the image size and the different filtering/compression options? If that is too generic, let's say we use PNG_COLOR_TYPE_RGB, PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT.
Thank you
PNG overhead is 8 (signature) + 25 (IHDR) +12 (first IDAT) + 12 (IEND) plus 1 byte per row (filter byte), plus 12 bytes per additional IDAT when the size exceeds the zlib buffer size which is typically 8192. Zlib overhead is 6 (2-byte header and 4-byte checksum). Deflate overhead is 5 bytes plus 5 bytes per additional 32k in size.
So figure (1.02 * (3*W+1) * H) + 68.
You can decrease the 1.02 factor if you use a larger Zlib buffer size or increase it if you use a smaller buffer size. For example, a 256x256 RGB PNG compressed with a 1000000-byte buffer size (1000000 bytes per IDAT chunk) will have only one IDAT chunk and the total overhead will be around 330 bytes, or less than .2 percent, while if you compress it with a very small buffer size, for example 100 bytes, then there will be around 2000 IDAT chunks and the overhead will be about twelve percent.
See RFC-1950, RFC-1951, and RFC-2083.
You can use compressBound() in zlib to determine an upper bound on the size of the compressed data given an uncompressed data length, assuming the default zlib settings. For a specific set of different zlib settings, you can use deflateBound() after deflateInit2() has been used to establish the settings.