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.
Related
I want to figure out exactly what is happening when I create a 640x480 pixel image from the OV5647 Pi camera v1.
This is what I think so far:
We start with the full FoV 2592x1944 pixel resolution with aspect ratio 4:3.
Now 640x480 resolution image is also 4:3 aspect and based on full FoV.
We start by binning:
| Width | Height |
|----|----|
|2592|1944|
|1296|972|
|648|486|
e.g. 2592/2 = 1296; 1296/2 = 648
1944/2 = 972; 972/2=486
So after binning we get resolution of 648 x 486 but we want the output to be 640 x 480 so we have to deal with the extra 8 pixels horizontally and the extra 6 vertical pixels on the binned image.
My question is what actually happens to create an output image frame for the following cases:
640 x 480 resolution video is recorded with raspivid e.g. console command:
raspivid -o myvid.h264 -w 640 -h 480 -t 60000
If possible could someone explain the slight variation I see with 640 x 480 images create with raspivid and with OpenCV 4.0.0. The content of the images seems somewhat different e.g. slightly displaced but I am not sure if this is simple displacement e.g. taking from slightly different FoV or is one of the outputs actually performing a scale operation on the 648x486 binned image to generate the 640x480 result e.g. I have assumed that only binning and FoV clipping is done but actual scaling is possibility too especially for opencv.
Code for camera image is captured with OpenCV 4.0.0:
cv::VideoCapture* video_capture_cap_;
video_capture_cap_ = new cv::VideoCapture();
video_capture_cap_->open(0);
if (video_capture_cap_->isOpened()) {
video_capture_cap_->set(
cv::CAP_PROP_FRAME_WIDTH,
640);
video_capture_cap_->set(
cv::CAP_PROP_FRAME_HEIGHT,
480);
video_capture_cap_->set(
cv::CAP_PROP_FPS,
49);
It would seem the answer is the following:
raspivid -o myvid.h264 -w 640 -h 480 -t 60000
produces a video file of the .h264 format.
Frames of the video are produced by 4x4 binning followed by scale.
As output is 640 x 480 frames, the following is done.
2592/2 = 1296; 1296/2 = 648
1944/2 = 972; 972/2=486
then scale 648 x 486 to 640 x 480 using a scale factor of (640.0/648.0).
I am not sure if this concurs with the raspivid documentation which seems to suggest the contrary e.g. from documentation I was expecting cropping to the correct image size not scaling. However, inspecting video output suggests the that scaling takes place rather than cropping.
Method was to take video as above of camera calibration checkerboard. Extract frames from video and compare size of and position checkerbaord squares with corresponding image taken via cv::VideoCapture.
Image from cv::VideoCapture was formulated as described by Christoph Rackwitz e.g.
do binning as above to get 648 x 486 image then crop to the desired 640 x 480 image size. Cropping appears to take the central 640 x 480 image regione.g. it drops the first 3 rows and the last 3 rows of the 648 x 486 image and drops the first and last 4 columns in each row.
Say if I have an image size of 250 x 250 and I've downscaled it by a factor of 3 using PIL library like this:
from PIL import Image
width, height = original_img.size
downscaled_img = original_img.resize((width // 3, height // 3), Image.BICUBIC)
print(downscaled_img.size) // should be 83 x 83 or something like that
So, now if I want to scale it back by a factor 3 I'd get an image size of 249 x 249, which is different from its orginal copy. In this case, I wonder how can I calculate the PSNR between these two images? Should I remove 1 pixel from all borders from the original image to make it 249 x 249 and then calculate PSNR?
Thanks a lot,
JZ
I am using OpenCV to generate images with depth of 1 bit to cut in a laser cutter (Github repo here). I save them with:
cv2.imwrite(filepath, img, [cv2.IMWRITE_PNG_BILEVEL, 1])
Each pixel corresponds to 0.05mm (called "scan gap" in the laser cutter). A sample image has 300 x 306 pixels and appears in the laser cutter software (LaserCut Pro 5) with size 30 mm x 30 mm. This corresponds to a resolution of 254 pixels per inch and the uncommon value could be from the software. I want a size of 15 mm x 15.3 mm and want to set a higher resolution to achieve that. I could resize by hand, but if I make a mistake, the pixels are no longer exactly aligned with the scan gap of the laser, resulting in inaccuracies in the engraving.
Does OpenCV have a way to set the resolution or final size of the image?
The image sensor of a particular digital camera contains
2016 × 3024 pixels. The geometry of this sensor is identical to
that of a traditional 35mm camera (with an image size of 24 × 36
mm) except that it is 1.6 times smaller. Compute the resolution of
this digital sensor in dpi
this looks like pure math question how it is related to programing?
DPI is dot per inch, inch is 2.54mm so you divide resolution in dots (pixels) by size of chip in inches.
chip size is:
(24 × 36)/1.6 mm
(24 × 36)/(1.6*2.54) inch
(24 × 36)/(4.064) inch
The DPI is then
(2016 × 3024) / [(24 × 36)/(4.064)]
(2016/24 × 3024/36) * (4.064)
(84 × 84) * (4.064)
(341.376 x 341.376) DPI
So the camera pixel density is 341.376 DPI
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.