Roate Preview 90 degrees
Closed this issue · 18 comments
Is it possible to rotate the preview image 90 degrees.
Not at present. Why do you need to ?
out of all attempts to get any and i do say ANY camera functions yours is the only one that works sorta...
the problem i have is identical to this https://forums.raspberrypi.com/viewtopic.php?t=273094. this is of no help and any attempt to find the answer to any of the camera questions turns into a maze of ill fated wording for an rookie of pi, python, or any programing of any sort. i have stumbled through your code and without any success.
even the process over at the pi foundation yields a "command not found"!!!...
id did the bookworm for about 2.2 seconds. and was for a far attempt to do a camera shot some how had the preview, jpeg, and display in the correct orientation (ie 90 degrees rotated) with out any "programing". i have had to since move back to bullseye because all hat are for the bullseye OS and i am not in the know how of reprogramming each and every hat to make work with the new OS.
So simple answer is your software GUI dose what i am looking for just that it is 90 degrees off.
Ok. I'll look at adding the option, maybe next week before l can do it
So is the preview image rotated or the whole display ?
Sounds like a display issue not a camera issue ?
If it's the whole display have you tried the screen configuration editor in RaspOS GUI ?
here is more info for the setup i have. https://forums.raspberrypi.com/viewtopic.php?t=338966
the setup is defined by the case. (See Last 3 Images). In in order to correct this "preview rotation" any software that is used in this setup has to be rotated 90 degrees. Its interesting to see that before bullseye this was very simple to do and could even be done at the start up of the pi itself via a config.txt. but since bullseye this has been next to impossible to define.
did find the libcamera --help showed that it's possable to rotate 180 degrees. when i did the libcamera -- rotation 180 i got this data.
user@raspberrypi:~ $ libcamera-hello --rotation 180
Made X/EGL preview window
[1:42:25.760437277] [1925] INFO Camera camera_manager.cpp:297 libcamera v0.0.5+83-bde9b04f
[1:42:25.805579324] [1926] WARN RPI vc4.cpp:383 Mismatch between Unicam and CamHelper for embedded data usage!
[1:42:25.806571053] [1926] INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/imx219@10 to Unicam device /dev/media3 and ISP device /dev/media0
[1:42:25.806689292] [1926] INFO RPI pipeline_base.cpp:1101 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
[1:42:25.807625077] [1925] INFO Camera camera.cpp:1033 configuring streams: (0) 1640x1232-YUV420
[1:42:25.808156292] [1926] INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected sensor format: 1640x1232-SRGGB10_1X10 - Selected unicam format: 1640x1232-pRAA
here is a photo of the desktop... the preview area is what i was inquiring about. I changed several areas in your file to see if this was possible but it looks like it only hits the overall GUI box and not the individual boxes. i guessing you have 3 areas for the gui. an overall box the is set to the screen setup ie full or min, an area or box that contains all your "controls", and an area for the preview of the image being viewed. (this is the area that would be the area of interest to rotate..
SmartiPI Touch 2 case with a Raspberry PI 4B, Pi Camera Module 2 image of setup
Try v4.55. Set rotate in parameter settings. Some options will be disabled but let me know if it works in principle
yes it worked.
few issues if not aware....
- 90 and 270 are inverted. (at least on my view)..
- no frame when in any rotation other then 0
- all images taken are vertical ie not set to the screen preview
- preview image is on far left of screen as apposed to center.
- (in my setup) the gui lost connection with the camera after 3 clicks on the image (this found as i was clicking on the preview thinking the frame would show up)
in principle it work great.
- 90 and 270 are inverted. (at least on my view)..
That's how pygame works unfortunately - no frame when in any rotation other then 0
Partially added for v2 camera, more may come... - all images taken are vertical ie not set to the screen preview
You asked for the preview rotated, libcamera can't do rotate only 0 and 180 degs. - preview image is on far left of screen as apposed to center.
Fixed in v4.56 - (in my setup) the gui lost connection with the camera after 3 clicks on the image (this found as i was clicking on the preview thinking the frame would show up)
Did you right click ? That would try to switch to a 2nd camera, which I assume you don't have. Fixed in v4.57.
- 90 and 270 are inverted. (at least on my view)..
That's how pygame works unfortunately
^thank you for that info. it was just worth noting....
2. no frame when in any rotation other then 0
Partially added for v2 camera, more may come...
Will look foward to seeing that the green inter box on the preview was/is nice to have
3. all images taken are vertical ie not set to the screen preview You asked for the preview rotated, libcamera can't do rotate only 0 and 180 degs.
that seem to changed when they felled to use the rotate.ccp and was just uninterested in this as it is still part of the ilbcamera folder.. wish i know enough about programing to use that CCP..
^will have to do that in post processing. just something worth noting..
4. preview image is on far left of screen as apposed to center. Fixed in v4.56
^nice thank you..
5. (in my setup) the gui lost connection with the camera after 3 clicks on the image (this found as i was clicking on the preview thinking the frame would show up) Did you right click ? That would try to switch to a 2nd camera, which I assume you don't have. Fixed in v4.57.
^ very nice. as of right now i don't have the second camera.. is that a hat or a usb?
as a open source your program is very useful. thanks for all the updates...
just one thing i did notice that the images was tripled up. (at least in the 4.55 version. will check in the updated version)
For a second, or third and fourth, camera ,l believe you can use a Arducam Multiplexer but l have never tried one. I have added this option for a user, l await feedback if it works OK. It may also work on a pi5 with 2 cameras.
I see what you mean about tripling !. I didn't realise that happened l thought it just deleted old versions, which you used to be able to do manually. I live and learn.
What is your camera ?
current working with a v2? have a few CAM002 with ir but don't know what ill do with at this time.
so this new version 4.58? i did still shot expected to see the old and the test image but the old is not there now did you remove this ability? as for the triple the "timestamped image" is in the picture folder. and is much grainier then the "test.jpg" and about 1.999 sec behind the test.jpg is that by design?
a few new files also showed up. libcams.txt, Pilibtext.txt. by design? they have some good info in them...
libcams.txt
PiLibtext.txt
Nothing has changed regards oldtest.jpg or any other camera settings.
Yes the libcams.txt file is used to allow camera switching.
PiLibtext.txt is the metadata and is used to display it.
v4.60 re-enables the histogram option, but you can't move the measured point if using rotate,
and will save a rotated version of any stills captured, with r added to the name
Test.jpg just uses simple settings not the camera settings , it's only to find the size of the image and thus the camera in use. I am not sure where you get the 1.999sec from. Test.jpg is only taken once at the start of the code, or when you switch cameras.
Thank you for this. the test.jpg is not the "updated" still image taken? Then where is the still image stored once taken?
v4.60 re-enables the histogram option, but you can't move the measured point if using rotate,
and will save a rotated version of any stills captured, with r added to the name.
this is the case of "be careful what you wish for"
This dose a rotate, crop then saves the reduction. cause from the libcamer's programmers horrible inability to rotate without zooming. i would leave the image as un-rotated if i have the option. i can always do the rotation in a different program to maintain the original size..
windowSurfaceObj.blit(image, (int((preview_width/2) - ((preview_height * (igwr/ighr)))/2),0)) why is everyone using the /2 when doing the rotate or saveimage rotate. this statement above is counterproductive. it dose the rotate and crop correct?
It doesn't save a reduction, it only uses the reduction for showing on screen, the saved rotation is full sized.
The calculation you quote decides where to place the rotated image on the preview screen.
I'll remove the rotation save if you want.
Taken pictures are saved in /home/(username)/Pictures, videos in /home/(username)/Videos
that rotation save is of value. as for the saved rotation value. it acutely1/2 the size of the non rotated version. that is noting you can do about that is's cause from the libcamera poor design and use of the raw data from the sensor... and it something they refuse to look at or even ack. buster os was handling this correct and when they desired to move to a "better" os they failed to keep this in the programing. this is why your software is the best (and working gui) at handling the on screen preview.
in the attempt to build a now 4 camera DSLR (thank you for the info on the multiplexer)
ill be flashing the sd today and reinstalling and document what steps i take.
I agree the saved rotation file size is smaller than the original, this is down to pygame, there are no options to change this l can find. Maybe a combination of rotating and saving. Its not a crop or a Resize.
I think l've done all l can for now so will close this issue
Closed
thank you very much for your help and a great program.. thank you