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

Issues when viewing photos full screen in IPadOS Photos app #256

Open
laolux opened this issue Jul 28, 2021 · 4 comments
Open

Issues when viewing photos full screen in IPadOS Photos app #256

laolux opened this issue Jul 28, 2021 · 4 comments

Comments

@laolux
Copy link

laolux commented Jul 28, 2021

Trying to view photos fullscreen on the ipad in the photos app works fine, but does not properly get displayed on my computer by rpiplay.
The picture I try to view is 1392x972 pixel in size and is a blue/red checker board with a one pixel grid. Click on the picture to see it for real, the preview in github is a bit strange.
offendingimage
This is how everything looks like when viewing on the ipad (screenshot done on ipad):
ipadscreenshot
This is how it looks like when viewing on my computer via rpiplay:
screenshot_computer
Clearly something is broken here. When I switch back to the picture overview, then everything is displayed correctly again in rpiplay.

@FD-
Copy link
Owner

FD- commented Jul 28, 2021

What exactly is clearly broken here? The photos app directly renders to the second (AirPlay) screen, so don’t expect a direct copy of what you see on the iPad screen. What does a real AppleTV display here?

@laolux
Copy link
Author

laolux commented Jul 29, 2021

First I need to correct myself. The issue appears with pretty much any picture, not just the example above.

What looks broken to me are the black borders around the picture. Top/bottom I can understand, as the size of the picture does not match the size of the display, but left/right? Also, when I open a screenshot from my ipad (which automatically has the correct size), then I get huge black borders everywhere, see attached picture below. And those borders do not appear when I open the overview of all my pictures.

Unfortunately I cannot compare with a real AppleTV, as I do not own one. Maybe I can find a friend who has one, so I could check if those huge black borders are there as well and thus expected.

screenshot_of_screenshot

@fduncanh
Copy link

fduncanh commented Aug 7, 2021

are you using an added feature to set the display size?
This isnt yet part of "official" RPiPlay.

If you want it on RPiPlay, it is also in my pull request #257
or (for gstreamer users only), UxPlay 1.3 at https://github.com/FHD2/UxPlay.git

From what I see, usually the image uses as much of the display area that its aspect ratio allows, but sometimes is smaller, leaving black areas on both top and bottom and right and left, as in your sample image. The settings (default 1920x1080) are (I think) used as a starting point for negotiation with the iPad client. By adjusting the wxh aspect ratio, I could get Photos images to fill the display window with a tiny black edge, on a standard iPad (I think you are using a pro). Maybe if you experiment with the -x -y setting on PR #191 or the -s wxh setting on #257 or UxPlay 1.3 you can find one that is good for iPad pro.

@laolux
Copy link
Author

laolux commented Aug 11, 2021

No, this happens when using the latest "official" version, without trying to set the resolution by hand.

I just tried zooming into the picture -> I can make the black border left and right disappear, but not top/bottom. This works regardless whether I am using portrait or landscape mode. I also noticed that the pictures always seem to be shown in landscape mode, even when being displayed in portrait mode on my ipad.

Furthermore, I just tried with an iphone. Result is the same is with ipadPro.

Thanks for the link to a new repo for UxPlay, I will check it out. (link has a typo, FHD2 instead of FDH2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants