Non square pixels?

[liamkennedy]

So it looks like the display is non-square pixels?

I'm using pygame to resize some images and any circles on it turn out to be slightly squashed vertically.

As per the specs it is 155 mm wide and 86mm high.

800/155 = 5.16
480/86 = 5.58

I can correct this in my code to account for this - but it just seemed odd and non-standard for it to be this way.

Am I doing something wrong? Is there some setting I have messed up in config.txt (which is default right now anyway)?

Thanks

[gadgetoid]

I drew a 200x200 pixel square in PyGame and found the same thing. Looks like you're correct- although as you demonstrate the dimension and resolution of the screen already agree with your findings.

I measured my square with calipers to approximately 38mm wide and 35mm tall. Although I can clearly see by eye that it's squashed.

[liamkennedy]

Well at least it's not my imagination then. Thanks for confirming.

I've been trying to compensate in code - but it seems I am getting a little lost with all the pygame stuff. I managed to unsquish the image based assets I am working with - but - it's a lot more complicated with drawing stuff - especially circles. To compensate for the non-square pixels I would have to switch to using the pygame ellipse function rather than the current circle - so it's a lot more work than I initially thought.

It's all a bit of a hack unfortunately and will mean my code will have to have to figure out if it is running on the Touchscreen - and if so - make the adjustments. Not the best idea at all.

[mbw]

Indeed, non-square pixels confirmed.
I’m curious what went wrong or why this was intentionally implemented.
We would also like a software solution for this problem.
At the moment we only found a mechanical solution.

[liamkennedy]

Indeed, non-square pixels confirmed.
I’m curious what went wrong or why this was intentionally implemented.
We would also like a software solution for this problem.
At the moment we only found a mechanical solution.

OK. That is pretty funny and truly made me chuckle a bit.

It would be neat to have some kind of a fix to this that doesn't involve compensating for it in code.

[tofflock]

I received my display, saw this post about the pixels being rectangular, and thought I'd try playing a video.
I used omxplayer. I tried a short (mp4) video with a native "screen" size of 1280x720. This size corresponds to a screen with a 16:9 aspect ratio - (1280/720 = 16/9 = 1.78 (close-ish)).
First I used omxplayer without any window parameters and, as would be expected (from a 800x480 pixel screen), I got blank bars at the top & bottom of the picture. The picture also looked squashed (vertically).
However, the physical dimensions of the display area are 155x86mm. Note: 155/86 = 1.80!
So I ran omxplayer again with window parameters so that the video would fill the screen - something like this:

Code: Select all

omxplayer --win '0 0 800 480' TestVideo.mp4

So I've now got a pretty good picture with the correct aspect ratio, and no bars on the screen. I haven't looked at the source of omxplayer, but my guess is that the different horizontal & vertical scaling factors are applied in the GPU. The video played fine using a Pi2 - absolutely no stuttering, despite all that math going on in real time! For those who want to know a bit more about the video, here's some technical info from mediainfo:

Code: Select all

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 2 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 11mn 5s
Bit rate mode                            : Variable
Bit rate                                 : 2 292 Kbps
Maximum bit rate                         : 3 500 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.099
Stream size                              : 182 MiB (96%)

So I guess the pixels could be squared up for python (and anything else that needs a more accurate display), with some asymmetric scaling in the GPU???

HTH

Peter

[liamkennedy]

So I guess the pixels could be squared up for python (and anything else that needs a more accurate display), with some asymmetric scaling in the GPU???

HTH

Peter

Indeed - that would be the solution. Any clue on how that could be accomplished though?

Any messing with the GPU on the Pi seems to be in the realm of a very custom hack. Indeed omxplayer is a Raspberry Pi only video player - which is how it gets to work so well with the GPU.

pygame is a generic set of code - so someone would have to branch the code and do some serious additional hacking to get it to work (maybe what goes on inside omxplayer could help guide that)

Unfortunately that level of work is way beyond my capabilities.

[liamkennedy]

Actually I just realized a sort of solution to this for pygame.

If you know pygame - everything is "written" to an in-memory image representation (called a pygame surface). What I need to do is at the last moment do an image scale/resize to compensate and display THAT to the screen instead. It's a lot more work for the processor - so I'll have to see what that does for my application - but really I only need to update every half second at most - so it'll probably be OK.

EDIT: Maybe this is the part that could be handled via a GPU hack.

I'm going to give that a try.

I am sure for others who are not really bothered by the non-square nature of the display it won't be an issue. For me - I feel it's enough of an oddity I want a solution that works.

[plugwash]

So I guess the pixels could be squared up for python (and anything else that needs a more accurate display), with some asymmetric scaling in the GPU???

Scaling works ok for videos because videos are always somewhat "blurry" to start with. Scaling stuff with thin lines (e.g. most UIs) after the fact without turning them into a blurry mess is much harder.

[liamkennedy]

Scaling works ok for videos because videos are always somewhat "blurry" to start with. Scaling stuff with thin lines (e.g. most UIs) after the fact without turning them into a blurry mess is much harder.

That's a very good point and one that I was going to watch out for. The stuff I am doing with PyGame are lines/circles a few pixels thick - so the scaling may have some artifacts.

[guilala]

I was so happy with my original Raspberry Pi 7" touchscreen display... till me to discovered the non square pixel aspect ratio problem that stretches everything horizontally. How come this hasn't been discovered before release?! The correct DPI has to be something like 133x142 dots per inch.

I've found three ways to set DPI, all three won't fix this aspect problem on a Raspberry Pi though:
- xrandr won't work on the Pi because: "Failed to get size of gamma for output default".
- ~/.Xresources Xft.dpi won't work because it accepts a single number assuming square pixels.
- Xorg.conf DisplaySize won't work on the Pi because using a xorg.conf is depreciated, and generating one with Xorg -configure failes.

Was anyone able to find a solution?!.

[mark-forrest]

That's a real shame, I have been writing a dashboard app on a full sized monitor and when I ran it on the touchscreen display the analog clock was squashed.

Have spent a bit of time trying to make sure there wasn't something I'd done wrong with the scaling in Cairo. Never mind will have to live with it.

Maybe I'll make the clock even more elliptical and turn it into a feature.

[jwatte]

Yes, this is terrible. I also didn't discover it until after I purchased the display.

How can someone, in this day and age, even build a display like that? Like, who, in what factory, thought this was a good idea?

[fsr]

How can someone, in this day and age, even build a display like that? Like, who, in what factory, thought this was a good idea?

It was probably designed to display video. PAL, NTSC, SDTV and many other formats of video use non-square pixels.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio

[tasagore]

Yes, this is terrible. I also didn't discover it until after I purchased the display.

How can someone, in this day and age, even build a display like that? Like, who, in what factory, thought this was a good idea?

I've read this post too late...this display is Unbelievable.

[mahjongg]

please stop using profanity on this forum, also stop making an elephant from a mosquito.

[W. H. Heydt]

please stop using profanity on this forum, also stop making an elephant from a mosquito.

"Float like a mosquito, sting like an elephant"? Just doesn't conjure up the right image. Mr. Clay must have had something else in mind.

[LennartH]

Hey guys,
I found a non-mechanical way to adjust the resolution of the pi.

Edit the config.txt...

Code: Select all

sudo nano /boot/config.txt

...and add the following lines:

Code: Select all

framebuffer_width=800
framebuffer_height=444
framebuffer_aspect=-1

Reboot and you are good to go.

I used the values mentioned in this thread above to calculate the scaled down height:

Code: Select all

800px /155mm = 5.16
480px /  86mm = 5.58

5.16 / 5.58 = 0.9247

480px * 0.9247 = 444px

I found the config settings in this thread started by grasshopper2:
https://github.com/raspberrypi/firmware/issues/638.
So thanks to him.

[lee_w]

Hello pi camera fellows,

I am trying to get an unstretched preview image on my touch display.
Its the official 7 inch touchscreen.
It has an non-square aspect ratio.

With the following entries at the /boot/config.txt

framebuffer_width=800
framebuffer_height=444
framebuffer_aspect=-1

The normal screen content looks good.


But the preview of the camera module seems to be directly written to the display.
The preview is always stretched.

My question is: Is it possible to stretch the preview of the camera module ?

I am using the python module: picamera

Perhaps somebody has a hint for me.

All the best,
Lee

[6by9]

Hello pi camera fellows,

I am trying to get an unstretched preview image on my touch display.
Its the official 7 inch touchscreen.
It has an non-square aspect ratio.

With the following entries at the /boot/config.txt

framebuffer_width=800
framebuffer_height=444
framebuffer_aspect=-1

The normal screen content looks good.


But the preview of the camera module seems to be directly written to the display.
The preview is always stretched.

My question is: Is it possible to stretch the preview of the camera module ?

I am using the python module: picamera

Perhaps somebody has a hint for me.

All the best,
Lee

Duplicate of request at viewtopic.php?f=43&t=192529
Please don't duplicate posts.

[VMark]

Hi folks,

Just for reference.
For me, the

Code: Select all

framebuffer_aspect=-1

did not work with a DVI mode TV,
BUT

Code: Select all

sdtv_aspect=1

did the trick - with the proper framebuffer_width and framebuffer_height.