Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ROI Cropped images are same size as original #86

Closed
dmopalmer opened this issue Sep 16, 2013 · 11 comments
Closed

ROI Cropped images are same size as original #86

dmopalmer opened this issue Sep 16, 2013 · 11 comments
Assignees

Comments

@dmopalmer
Copy link
Contributor

@dmopalmer dmopalmer commented Sep 16, 2013

When the --roi option is used, the resulting pictures are of the correct region of the full frame, however, they are zoomed to the full frame size of 2592x1944

This makes them blocky, uses up a lot more resources than it should. If the ROI doesn't have the same fractional height and width (e.g. --roi 0.1,0.4,0.8,0.1) gives a distorted image as the result is stretched to the original aspect ratio.

Also, without ROI specified, the actions of --width and --height are inconsistent: sometimes they crop to the center, sometimes they scale the image.

@ghost ghost assigned JamesH65 Sep 16, 2013
@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Sep 18, 2013

Not sure what you mean in the last sentence. We've not had any issues with those before, so have you particular circumstances that show the problem?

With regard to roi, I could specify the width and height to be that as calculated from the roi region, and allow it to be overridden by the --width/--height options. However, --roi is intended as a sort of zoom where you would expect the current behaviour. If you specify width and height, does that do what you want?

@dmopalmer

This comment has been minimized.

Copy link
Contributor Author

@dmopalmer dmopalmer commented Sep 19, 2013

I would expect that --roi would produce an image that is a cropped version of the image at same per-pixel scale as the original. (Not the only justifiable design choice, but I think this gives least astonishment.)

Manually setting the --width and --height by multiplying the full-frame pixel size by the crop width and height factors works to give me what I want, but only if those factors are the same. If they are different, then the image gets distorted.

--roi 0.4,0.4,0.1,0.1 --width 259 --height 200
this gives undistorted 10% x 10% ~central region of image

--roi 0.4,0.4,0.1,0.2 --width 259 --height 400
this gives distorted 5% x 20% ~central region of image stretched to 10% x 20% of the frame image pixels
What I wanted is the the 10%x20% region in 10% x 20% of the pixels wiht no scaling and no distortion.

This distortion probably has to be fixed in the firmware, unless there are appropriate exposed control calls.

I have made the changes to automatically change the height and width in a branch of my fork:
https://github.com/dmopalmer/userland/tree/roi_imagesize
but it shows this distortion when the crop is not equal in both dimensions. Also, I had to guess about the final size: my choices for rounding, whether you crop on bayer-unit boundaries etc. may be different from yours, so the scaling (even when it works) may not be 1:1 across the entire image.

Should I put in a pull request anyway?

Also, I have a web-server camera interface now:
https://github.com/dmopalmer/picamserver
which lets you serve images to your browser, including the arguments in the URL:
http://192.168.0.45:8001/camera?width=259&height=400&roi=0.5,0.5,0.1,0.2
so that's a convenient way to test these things out.

(I now understand the --width and --height in the non-ROI case: If the width x height has the same aspect ratio as the raw detector, then it does straight scaling. If the aspect ratio is not the same, then it scales the image according to one dimension and crops in the other so there is no distortion and maximum zoom with no letterbox or pillarbox black bands. That's a reasonable thing to do.)

@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Sep 23, 2013

I'm not convinced a change is necessary here. The roi stuff is really for zooming in, where the current behaviour is as you might expect. Using width and height options you can easily change the output size to what you need (as you say, mutiply the max width/ height by the roi width/height figures), so it seems unnecessary to change anything.

@dmopalmer

This comment has been minimized.

Copy link
Contributor Author

@dmopalmer dmopalmer commented Sep 23, 2013

But the width and height options don't work properly in conjunction with ROI.

For the two images below, the second 'distorted.jpeg' image should be the same scale as the first image, but twice as high covering twice the field of view vertically. But the distorted image is stretched out so it only covers half as much horizontal FOV.
palmer@pi ~ $ raspistill -t 1000 -o /tmp/undistorted.jpg --roi 0.45,0.5,0.1,0.1 --width 259 --height 200
palmer@pi ~ $ raspistill -t 1000 -o /tmp/distorted.jpg --roi 0.45,0.5,0.1,0.2 --width 259 --height 400

undistorted
distorted

@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Sep 23, 2013

That's a bug...something is calculating the aspect ratio incorrectly somewhere. I'll need to look in to that.

@tomekziel

This comment has been minimized.

Copy link
Contributor

@tomekziel tomekziel commented Dec 30, 2013

My observation mentioned in thread http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=64635

I'm using following code to capture intentionally distorted image (I'm using 0.75 of sensor height to make proportions right on PAL display widened to 16:9):

raspistill -vf -w 1296 -h 1944 -o out.jpg -fp -p 0,0,720,576 -v -vf -roi '0,0.125,0.99,0.75'

When ROI width is 1 (like -roi '0,0.125,1,0.75'), ROI height spec is ignored and image is undistorted. When ROI width is slightly decreased (-roi '0,0.125,0.99,0.75'), all parameters are honored.

I don't know what is the relation between matrix crop and width/height options or if there is any hardware restriction involved. However, when -roi switch is present, it should override such relation completely so in such case -w / -h switches will ONLY affect output image size.

@tomekziel

This comment has been minimized.

Copy link
Contributor

@tomekziel tomekziel commented Dec 30, 2013

Maybe I simplify my issue related to this ticket - is it possible to do a full-frame photo with valid preview but output image scaled down?

@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Jan 2, 2014

To answer tomekziels post, the difference between 0.99 and 1.0 is actually quite large with regard to the number of pixels involved. If you use 0.99999 you get a result almost the same as 1.0.

However, I have a feeling there are certainly some underlying issues here, so am investigating.

@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Jan 2, 2014

Huzzah. After much digging I've found a bug in the camera code whereby it was stopping the zoom if the correct width was reached, irrespective of whether the correct height was reached. So only showed up when different factors for width and height zoom were required, and even then only if the height factor exceeded the width.

A fix should be in the next firmware release. I'd be interested if it fixes all the ROI issues described here.

popcornmix pushed a commit to raspberrypi/firmware that referenced this issue Jan 2, 2014
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p479046

kernel: Fix for oops in snd-bcm2835
See: raspberrypi/linux#478

firmware: Fix for camera failing to init due to unused vlls

firmware: MJPEG Encoder: Allocate conv image from reloc heap
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p478922

firmware: camera: Fix for early finishing of zooming - code was only checking that width destination was being reached, not height destination. Only causes a problem if more zooming was required for height than width (i.e. different zoom factors).
See: raspberrypi/userland#86

raspicam: Added -sn flag to set initial segment number.
See: raspberrypi/userland#125

raspicam: colfx options not working correctly
See: raspberrypi/userland#130
popcornmix pushed a commit to Hexxeh/rpi-firmware that referenced this issue Jan 2, 2014
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p479046

kernel: Fix for oops in snd-bcm2835
See: raspberrypi/linux#478

firmware: Fix for camera failing to init due to unused vlls

firmware: MJPEG Encoder: Allocate conv image from reloc heap
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p478922

firmware: camera: Fix for early finishing of zooming - code was only checking that width destination was being reached, not height destination. Only causes a problem if more zooming was required for height than width (i.e. different zoom factors).
See: raspberrypi/userland#86

raspicam: Added -sn flag to set initial segment number.
See: raspberrypi/userland#125

raspicam: colfx options not working correctly
See: raspberrypi/userland#130
@JamesH65

This comment has been minimized.

Copy link
Collaborator

@JamesH65 JamesH65 commented Jan 3, 2014

Fixed in latest firmware.

@JamesH65 JamesH65 closed this Jan 3, 2014
@tomekziel

This comment has been minimized.

Copy link
Contributor

@tomekziel tomekziel commented Jan 3, 2014

@JamesH65 confirmed, -roi problem I encountered is now gone. Thanks a lot for your work!

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p479046

kernel: Fix for oops in snd-bcm2835
See: raspberrypi/linux#478

firmware: Fix for camera failing to init due to unused vlls

firmware: MJPEG Encoder: Allocate conv image from reloc heap
See: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=62364&start=125#p478922

firmware: camera: Fix for early finishing of zooming - code was only checking that width destination was being reached, not height destination. Only causes a problem if more zooming was required for height than width (i.e. different zoom factors).
See: raspberrypi/userland#86

raspicam: Added -sn flag to set initial segment number.
See: raspberrypi/userland#125

raspicam: colfx options not working correctly
See: raspberrypi/userland#130
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.