Jedną z ciekawszych funkcji Apple Vision Pro jest możliwość połączenia go z naszym Makiem, celem stworzenia i skorzystania z wirtualnego ekranu zamiast fizycznego monitora. To rozwiązanie ma oczywiście wady i zalety, ale istotniejsze dla mnie jest to, jak to rzeczywiście wygląda, bo Apple podaje, że otrzymujemy ekran 4K, tylko co to właściwie oznacza?

Rozdzielczość / PPI / PPD

Rozdzielczość w świecie AR/VR to pojęcie zupełnie inne niż w przypadku liczenia pikseli na fizycznym ekranie. Weźmy na warsztat Apple Studio Display, którego niedawno miałem okazję testować. To ekran, który ma fizyczną rozdzielczość 5120×2880 px (pikseli), co przy jego wymiarach możemy przeliczyć na 218 PPI (points per inch, punktów na cal).

macOS jednak nie wyświetla (domyślnie) swojego UI w takiej rozdzielczości, tylko bierze każdą grupę 2×2 pikseli i wykorzystuje je jako jeden „punkt”. To oznacza, że użytkownik korzysta z desktopu o wymiarach 2560×1440 pt (pt to punkt; 1 punkt to 4 piksele w układzie 2×2). To rozumiemy jako Retina @2x, gdzie każdy punkt dzieli się idealnie na 4 piksele w układzie 2×2. Są oczywiście dostępne pośrednie rozdzielczości, ale przez to, że punkty nie dzielą się idealnie na piksele, to te są nieznacznie bardziej rozmyte (np. przy 32″ ekranach 3840×2160 px idealnie byłoby korzystać z 1920×1080 pt, ale wtedy wszystko jest zbyt duże dla naszych oczu na takiej przekątnej, więc lepiej przełączyć się na 2560×1440 pt, co jest mniej więcej mnożnikiem Retina @1.6x).

W przypadku headsetów VR/AR istotniejsze jest jednak korzystanie z PPD zamiast PPI, czyli points per degree lub punktów na stopień. PPD to miara, która odnosi się do rozdzielczości obrazu w kontekście widzenia ludzkiego i określa ona liczbę pikseli potrzebnych do reprezentacji jednego stopnia z całkowitego pola widzenia. Im wyższa wartość PPD, tym obraz będzie bardziej szczegółowy i bardziej zbliżony do tego, co ludzkie oko widzi naturalnie.

Dla przykładu, wspomniany Apple Studio Display z ekranem o przekątnej 27” i rozdzielczości 5120×2880 px ma PPD o wartości 80, gdy siedzimy w odległości 50 cm od ekranu (kąt widzenia wtedy wynosi 62°) lub 154 PPD, gdy siedzimy w odległości 100 cm (kąt widzenia 33°). Dla porównania, Apple Vision Pro ma 34 PPD, a Quest 3 ma 18 25 PPD.

Jako ciekawostkę podpowiem, że pikseloza staje się subiektywnie gorsza im dłużej korzystamy z Vision Pro, gdy oko się przyzwyczaja do tego, co widzi, a efekt „wow” przestaje robić aż takie wrażenie. Przynajmniej tak jest u mnie.

Wirtualny ekran Maca w Vision Pro

Gdy podłączamy Maca do Vision Pro to domyślnie uruchamiany jest desktop w rozdzielczości 2560×1440 pt (oznaczone powyżej jako default).

Możemy jednak zmienić go na odpowiednik 5120×2880 pt, co demonstruję powyżej. Popatrzcie na rozmiar okien – dostępna przestrzeń jest ogromna, ale wszystko jest maleńkie.

Domyślnie całość się prezentuje tak, jak powyżej – 2560×1440 pt.

Możemy jednak skusić się na odpowiednik 1920×1080 pt, na co sam się przełączyłem – wszystko jest wtedy większe i jest to lepszy układ do pisania (ten wpis powstaje właśnie w VR), ale do montażu preferuję domyślną rozdzielczość, bo więcej rzeczy mieszczę na ekranie (a AVP ogranicza Maca od jednego wirtualnego ekranu).

Jako ciekawostkę dorzuciłem jeszcze odpowiednik 1344×756 pt, gdy wszystko nadal było za małe.

Ale jak to 4K?

No więc dochodzimy do sedna sprawy – Apple Vision Pro ma ok. 3660×3200 px na oko, czyli 7320×3200 px na parę naszych oczu. Oczywiście lewe i prawe oko łączą te piksele, więc pi razy drzwi bierzemy tą pierwszą wartość. Apple podaje, że finalnie para oczu ma do dyspozycji 23 mln px, co zostało potwierdzone. PPI wynosi niesamowite 3386, ale jak pisałem powyżej, istotne jest PPD, a te wynosi jedyne wspomniane 34 przy kącie widzenia ok. 100° (Quest 3 ma około 108-110°).

Skąd ta różnica w PPI i PPD? Studio Display ma tylko 218 PPI, ale 80 PPD (w odległości 50 cm), a Vision Pro 3386 PPI, ale 34 PPD.

Odległość od ekranu ma tutaj zasadnicze znacznie. Gdy oko znajduje się daleko od np. naszego telewizora, to piksele na nim są maleńkie, a gdy zbliżymy do niego twarz tak, aby nosem go dotykać, to widzimy poszczególne piksele bez szkła powiększającego. Tak samo jest z Vision Pro, tylko całość jest bardzo blisko oka, więc PPI musi być bardzo wysokie, ale PPD finalnie nie jest super imponujące.

Ludzkie oko ma ok. 60 PPD

Szacuje się, że ludzkie oko ma ok. 60 PPD, więc droga do „Retiny” w VR/AR jest jeszcze długa i trzeba będzie podwoić rozdzielczość w pionie i poziomie, aby osiągnąć obraz zbliżony do możliwości naszych oczu.

Poza samą rozdzielczością istotna jest możliwość odwzorowania pełni kolorów, które widzimy. sRGB zawiera jedynie ok. 35-40% tego, co widzi ludzkie oko. DCI-P3 około 50%. A Vision Pro wyświetla jedynie 92% DCI-P3, więc szacujemy, że mniej niż 50% tego, co widzi przeciętny człowiek, wyposażony w trzy rodzaje czopków w swoich oczach.

Wiemy jednak o tetrachromatyźmie, który jest zjawiskiem występującym u osób posiadających cztery rodzaje czopków w siatkówce oka zamiast standardowych trzech. Czopki są receptorami światła odpowiedzialnymi za percepcję kolorów i dla większości ludzi trichromatycznych, trzy rodzaje czopków pozwalają na postrzeganie szerokiego spektrum kolorów. Jednak u tetrachromatów dodatkowy czwarty rodzaj czopka może rozszerzyć zakres percepcji kolorów, umożliwiając rozróżnienie subtelnych różnic kolorystycznych, których inni nie są w stanie dostrzec. Nie wiem co widzą tetrachromatycy, ale chciałbym to zobaczyć…

Ale co z tym wirtualnym monitorem 4K dla Maca?

Jak widać powyżej, wirtualny ekran dla Maca nie wykorzystuje całej dostępnej przestrzeni i pomimo iż mamy 3660×3200 px do wykorzystania, to nie będzie on miał rzeczywistych 4K. Raczej spodziewam się, że chodziło tutaj im o odpowiednik dostępnej przestrzeni dla użytkownika, która mniej więcej odpowiada fizycznemu ekranowi 4K, który ma między 27- a 32-calami. To jednak też nie do końca tak, bo mogę zmieniać rozmiar tego wirtualnego ekranu. Ten na screenie powyżej mniej więcej odpowiada mojemu 85-calowemu TV, ale mógłbym go zmniejszyć, aby miał wymiary ekranu w MacBooku Pro 14” – to kwestia szybkiego gestu.

Więc pozostańmy po prostu przy tym, że mamy wirtualny ekran o rozdzielczości, która mi wizualnie przypomina 27” monitor o rozdzielczości 2560×1440 px w „normalnej” odległości od twarzy. Piksele widać, nie denerwują, ale to nie jest taka Retina, do jakiej Apple nas przyzwyczaiło.

A fonty‽

rys. Smashing Magazine

Temat fontów oraz sposobów ich odwzorowania na ekranach komputerowych jest długi i poruszany od dawna. Mac i Windows zawsze do tematu podchodziło odmiennie, a Retina zmieniła wiele. Pamiętacie nadal, jak tekst na stronie internetowej wyglądał na ekranie iPhone’a 4?

Zaraz po kupieniu iPhone’a 4 w Londynie…

Szczękę miałem wtedy na podłodze…

Najistotniejsza kwestia to jednak fakt, że font względem siatki pikseli na ekranie (pomijam tutaj układy diamentowe, typu AMOLED) jest w monitorach czy na ekranach smartfonów stały. Pion to pion, a poziom to poziom. W przypadku headsetów AR/VR jest jednak inaczej – nasza głowa cały czasu pracuje, może ruszać się lewo / prawo, przekręcać się, a przecież treść zawsze jest zawieszona w tym samym miejscu i się nie porusza, co przy okazji oznacza, że jest non-stop renderowana i nie ma tutaj czegoś takiego, jak statyczny obraz. To przy okazji masakra dla fontów i pomimo, że Apple zrobiło kawał dobrej roboty, to widać gołym okiem, że nie wygląda to tak dobrze, jak wygląda na ich innych platformach.

Wymagania

Pamiętajmy jednak, że wyższa rozdzielczość (czterokrotnie wyższa najlepiej) oznacza, że możliwości CPU i GPU będą musiały bardzo mocno wzrosnąć bez zwiększania poboru prądu, co jest tak istotne w mobilnym urządzeniu na baterię.

Wstęp do Vision Pro

https://imagazine.pl/2024/02/21/rozdzielczosc-ekranu-maca-widzianego-w-apple-vision-pro-czyli-troche-matematyki-ppi-i-ppd/

Na koniec 2021 roku, jak przesiadałem się na swojego 14-calowego MacBooka Pro z M1 Pro, po razy pierwszy zrobiłem czystą przesiadkę, bez migracji danych, bez odtwarzania ich z poprzedniego komputera. Ręcznie przeniosłem to, co potrzebowałem.

Cały proces przenosi w sumie zajął mi wiele tygodni, bo przy okazji postanowiłem całkowicie przeorganizować strukturę swoich plików na dysku. Tak czy siak, pracuję tak bez zmian od listopada 2021 i wszystko spisuje się wzorowo, a pełną historię przenosin i komputera znajdziecie w archiwum, łącznie z czterema wpisami (część 1, część 2, część 3 i część 4) na temat moich aplikacji na macOS, z których korzystam na bieżąco.

Jednym z etapów przenosin była rezygnacja z aplikacji Karabiner Elements, nowszej i całkowicie przebudowanej wersji Karabinera, na rzecz wbudowaną możliwość przemapowania klawiatury w macOS za pomocą natywnych narzędzi.

Zmiana funkcja przypisanej do klawisza pod macOS za pomocą shell skryptu, bez Karabiner / Karabiner-Elements

Ta metoda pięknie działała pod macOS Monterey i Ventura, ale niestety przestała pod macOS Sonoma, a ja z braku czasu odkładałem rozwiązanie tego problemu, do dzisiaj.

Przypomnę, że korzystam z układu przypominającego HHKB na wszystkich swoich klawiaturach, nawet na tych, które mają klawisz CTRL w dolnym lewym rogu (HHKB tego klawisza nie ma, co widać na załączonym zdjęciu powyżej i ilustracji poniżej.

Jedyne, z czego nie korzystam, z ogromnym żalem, to przesunięcie klawisza Backspace o jeden rząd niżej, zaraz nad Enterem, co widać na ilustracji powyżej. Backspace to często naciskany klawisz i jego położenie w układzie HHKB jest zdecydowanie bardzo ergonomiczne. Niestety, pracuję również na MacBookach, więc nie mam fizycznie możliwości zmiany klawiszy na nim. Mogę jednak przemapować klawisze tak, aby sprawnie mi się pracowało na wszystkich swoich klawiaturach, dzięki czemu nie muszę się ich na nowo uczyć. To oznacza, że na każdej klawiaturze mam przemapowane następujące klawisze…

• Caps Lock → Lewy Control
• Prawy Command → Prawy Alt/Option
• Prawy Alt/Option → Prawy Command

W poprzedniej wersji tego przepisu korzystałem ze skryptu, który był wyzwalany za pomocą plista w LaunchAgents. To niestety przestało działać w macOS Sonoma, ale dzięki skryptowi Marcina Czachurskiego, przerobiłem swojego na taki, aby działał prawidłowo.

Plik plist nazwałem com.moridin.moridin_mac_keyboard_remap_v2.plist, a jego zawartość możecie sobie podejrzeć i pobrać stąd.

Jego struktura jest dosyć prosta i polega na wywołaniu komendy hidutil bezpośrednio z plista, zamiast wywoływać skrypt z tą komendą, jak to robiłem wcześniej. Najważniejsze będą tutaj pary usage id, które widzicie powyżej i oznaczają one następujące klawisze:

• 0x7000000e7 = Prawy Command
• 0x7000000e6 = Prawy Alt/Option
• 0x700000039 = Caps Lock
• 0x7000000e0 = Lewy Control

Same pary oznaczają, że zmieniam zachowanie klawiatury następująco:

• Prawy Command → Prawy Alt/Option
• Prawy Alt/Option → Prawy Command
• Caps Lock → Lewy Control

Finalnie prawe Command i Alt/Option są po prostu zamienione miejscami, aby łatwiej było mi wprowadzać polski znaki oraz dla spójności z Windows, gdzie prawy Alt znajduje się obok klawisza Spacji i służy jako modyfikator do dodawania naszych znaków diakrytycznych. Caps Lock całkowicie wywalam i zastępuję go klawiszem Lewy Control. Po tej zmianie z tego właściwego lewego Controla w ogóle przestaję korzystać – jak się okazało bardzo szybko po przesiadce na HHKB, ergonomia tego klawisza jest tak podła, że mięśnie błyskawicznie przyzwyczaiły się do nowego layoutu.

Tutaj znajdziecie ten sam skrypt, ale zamieniający tylko prawy Command z prawym Alt/Option, jeśli nie interesuje Was podmienianie Caps Locka.

Tabelę z usage id dla klawiatur USB znajdziecie albo tutaj w formie PDF-a, albo tutaj w dokumencie dla deweloperów macOS.

Miłego pisania!

https://imagazine.pl/2024/01/30/zmiana-mapowania-klawiatury-pod-macos-sonoma-za-pomoca-plist-bez-karabiner-elements/