Zdjęcia z iPhone’a w WordPressie bez konwertowania? Testujemy HEIC

Krótka odpowiedź brzmi: WordPress 7.1 ma już mechanizm, który powinien to umożliwiać. Nasz test pokazał jednak, że na Windowsie nadal można trafić na sytuację, w której HEIC nie zostanie poprawnie rozpoznany i przesyłanie zatrzyma się na etapie przetwarzania.

Zdjęcie HEIC z iPhone’a – materiał do naszego testu

Do testu wykorzystałem zwykłe zdjęcie wykonane iPhone’em 11. Na fotografii znajdują się materiały reklamowe naszej agencji – smycz, identyfikator i teczka S 90. Nie zmieniałem wcześniej rozdzielczości, nie otwierałem obrazu w Photoshopie i nie zapisywałem go ponownie jako JPEG.

Telefon zapisał fotografię w formacie HEIC. Plik ma rozdzielczość 4032 × 3024 piksele, czyli 12 megapikseli, a jego wielkość wynosi około 2,5 MB. Podczas późniejszej kontroli w przeglądarce otrzymaliśmy dokładną wartość 2 489 699 bajtów.

To dobry przykład pliku, z jakim może spotkać się właściciel strony. Podobne fotografie trafiają później do galerii realizacji, wpisów blogowych, opisów produktów albo portfolio. Najważniejsze pytanie brzmi więc nie tyle „czym jest HEIC?”, lecz po prostu: czy mogę przeciągnąć zdjęcie z telefonu do WordPressa i nie martwić się jego formatem?

Co właściwie miał zrobić WordPress 7.1?

Nowością w WordPressie 7.1 jest przetwarzanie części multimediów bezpośrednio w przeglądarce użytkownika. Do tej pory zdjęcie było przede wszystkim wysyłane na serwer, a hosting korzystający z PHP, GD lub Imagick odpowiadał za jego skalowanie, generowanie miniaturek i inne operacje.

Teraz część tej pracy może zostać wykonana wcześniej. WordPress wykorzystuje między innymi WebAssembly i bibliotekę libvips, dzięki czemu kompatybilna przeglądarka może przygotować obraz na komputerze użytkownika, zanim poszczególne pliki trafią na hosting.

W przypadku HEIC mechanizm jest szczególnie interesujący. WordPress ma odczytać zdjęcie w przeglądarce, przygotować jego wersję JPEG i wysłać do biblioteki mediów obraz nadający się do normalnego wykorzystania na stronie. Oryginalny plik HEIC może zostać zachowany jako plik źródłowy.

To ważne, ponieważ serwer nie musi wtedy sam posiadać pełnej obsługi HEIC. Przynajmniej w teorii wystarczy, że odpowiednie możliwości ma komputer i przeglądarka osoby przesyłającej zdjęcie.

Właśnie tutaj znajduje się największa korzyść dla właściciela strony: zamiast otwierać konwerter HEIC → JPG przed każdym przesłaniem zdjęcia, możemy pozwolić WordPressowi wykonać tę operację automatycznie.

Przesyłamy nasze zdjęcie HEIC do WordPressa

Test przeprowadziłem w edytorze blokowym. Utworzyłem nowy wpis, dodałem standardowy blok „Obraz”, wybrałem opcję „Wyślij na serwer” i wskazałem oryginalny plik IMG_0227.HEIC.

WordPress zaakceptował wybór pliku i rozpoczął jego obsługę. Zamiast gotowego zdjęcia w bloku pojawił się jednak symbol przetwarzania. Początkowo wszystko wyglądało normalnie – przy większym obrazie można przecież spodziewać się kilku sekund oczekiwania.

Tyle że tym razem oczekiwanie się nie kończyło.

Spinner pozostawał aktywny, a fotografia nie pojawiała się w edytorze. To był pierwszy sygnał, że zamiast demonstracji bezproblemowej obsługi HEIC otrzymaliśmy znacznie ciekawszy test diagnostyczny.

Czy winny był Edge albo brak obsługi HEVC?

HEIC nie jest całkowicie samodzielnym problemem WordPressa. Na Windowsie możliwość jego odczytania przez przeglądarkę jest związana między innymi z dostępnością dekodowania HEVC. Dlatego zanim uznałem, że mamy błąd WordPressa, sprawdziłem środowisko testowe.

Pierwsza kontrola wykazała, że Edge działał w trybie renderowania programowego. Mimo włączonej opcji akceleracji sprzętowej przeglądarka korzystała z Microsoft Basic Render Driver, a dekodowanie oraz kodowanie wideo odbywało się programowo.

Po zresetowaniu ustawień Edge sytuacja się zmieniła. Przeglądarka zaczęła prawidłowo korzystać z GPU, a raport pokazał między innymi sprzętowe przyspieszenie Canvas, WebGL, WebGPU oraz Video Decode. Edge wykrywał również obsługę HEVC Main, HEVC Main 10 i HEVC Main Still Picture.

Na tym etapie wykonaliśmy dodatkowy test przez WebCodecs. Zapytanie VideoDecoder.isConfigSupported() dla HEVC zwróciło:

supported: true

To ważny wynik. Oznaczał, że po stronie przeglądarki nie mieliśmy już wcześniejszego problemu z całkowicie wyłączoną akceleracją i brakiem obsługi dekodowania HEVC.

HEVC działa, więc dlaczego HEIC nadal się nie wczytuje?

Po poprawieniu konfiguracji Edge ponownie przesłałem dokładnie ten sam plik. Efekt był jednak taki sam. WordPress nadal zatrzymywał się na spinnerze, a zdjęcie nie pojawiało się prawidłowo w bloku.

To wykluczyło najprostszą odpowiedź. Nie wystarczyło już powiedzieć, że komputer „nie obsługuje HEIC” albo że „Edge nie ma HEVC”. Trzeba było sprawdzić, co przeglądarka przekazuje WordPressowi w momencie wyboru pliku.

Przygotowałem więc prosty test odczytujący właściwości pliku bez udziału mechanizmu przesyłania WordPressa. Dla naszego zdjęcia otrzymaliśmy następujący rezultat:

nazwa: IMG_0227.HEIC
rozmiar: 2 489 699 bajtów
typ MIME: pusty

Najważniejsza jest ostatnia pozycja. Przeglądarka znała nazwę oraz wielkość pliku, ale właściwość File.type miała wartość pustego ciągu znaków.

I właśnie tutaj znaleźliśmy właściwy problem

W obecnej implementacji WordPressa 7.1 typ pliku ma znaczenie podczas kwalifikowania obrazu do odpowiedniej ścieżki przetwarzania. Jeżeli przeglądarka zwraca prawidłowe image/heic albo image/heif, WordPress może rozpoznać plik jako HEIC i rozpocząć odpowiednią procedurę.

Na naszym Windowsie otrzymaliśmy jednak File.type === "". Rozszerzenie pliku nadal było prawidłowe i wynosiło .HEIC, ale informacja MIME przekazywana przez przeglądarkę była pusta.

Co ciekawe, nie jest to wyłącznie nasza obserwacja. W repozytorium Gutenberga znajduje się zgłoszenie dotyczące zawieszającego się przesyłania plików HEIC. Podczas jego analizy na Windowsie potwierdzono również sytuację, z którą spotkaliśmy się w naszym teście — dla prawidłowego pliku HEIC wartość File.type może pozostać pusta.

Trwają już prace nad poprawką tego mechanizmu. Jedna z wprowadzonych zmian pozwala WordPressowi nie polegać wyłącznie na typie MIME zgłaszanym przez system lub przeglądarkę. Gdy File.type jest pusty, system może sprawdzić początkowe bajty pliku i na podstawie nagłówka ftyp rozpoznać kontener HEIC lub HEIF.

To bardzo dobry przykład różnicy pomiędzy deklaracją „WordPress obsługuje HEIC” a rzeczywistym działaniem na tysiącach różnych konfiguracji komputerów. Funkcja istnieje, ale jeden nietypowy element środowiska może sprawić, że właściwa ścieżka przetwarzania w ogóle nie zostanie uruchomiona.

Co stało się z naszym plikiem?

W naszym przypadku plik mógł trafić na serwer jako oryginalny HEIC, ale WordPress nie przygotował prawidłowej wersji przeznaczonej do wykorzystania w edytorze. W szczegółach załącznika nadal widoczny był plik z rozszerzeniem .heic, natomiast brakowało normalnego podglądu obrazu, którego spodziewalibyśmy się po zakończonej konwersji.

Nie podaję więc w tym teście rozmiaru „JPEG-a po automatycznej kompresji”, ponieważ taki plik po prostu nie został u nas prawidłowo wygenerowany. Podawanie szacunkowej wartości sugerowałoby, że mierzyliśmy coś, czego w rzeczywistości nie udało się otrzymać.

I właśnie ten element warto podkreślić. Test zakończony błędem również jest wartościowym testem, jeśli jesteśmy w stanie ustalić jego przyczynę.

A co z automatyczną kompresją WordPressa 7.1?

Przetwarzanie HEIC jest tylko jednym z elementów większej zmiany. WordPress 7.1 potrafi przenieść do przeglądarki również zmianę rozmiaru, tworzenie miniaturek, obrót zgodny z EXIF-em oraz kompresowanie obsługiwanych obrazów.

Oficjalne materiały WordPressa wskazują również na zastosowanie libvips i bardziej wydajne kodowanie JPEG. W praktyce może to oznaczać mniejsze pliki niż przy tradycyjnym generowaniu ich przez GD lub Imagick na serwerze.

W naszym konkretnym teście HEIC nie doszliśmy jednak do etapu, na którym można uczciwie porównać wielkość obrazu przed i po konwersji. Problem pojawił się wcześniej – podczas identyfikacji i uruchamiania właściwej ścieżki obsługi pliku.

Dla JPEG-a, WebP czy AVIF nowy mechanizm nadal pozostaje interesującym rozwiązaniem. W tym artykule świadomie nie rozszerzam jednak testu na wszystkie formaty. Punktem wyjścia było realne zdjęcie z iPhone’a i właśnie na nim skupiamy się do końca.

Czy problem wystąpi u każdego użytkownika iPhone’a?

Nie. Wynik zależy od sposobu przesyłania zdjęcia, systemu operacyjnego, przeglądarki, dostępnych kodeków oraz aktualnej wersji WordPressa. Na innym komputerze dokładnie ten sam HEIC może zostać rozpoznany prawidłowo i automatycznie zamieniony na JPEG.

WordPress 7.1 wykorzystuje nowe przetwarzanie przede wszystkim w kompatybilnych przeglądarkach Chromium, między innymi w aktualnym Chrome i Edge. Jeżeli wymagania dla pełnego mechanizmu nie są spełnione, system powinien przejść do tradycyjnej ścieżki serwerowej. Właśnie obsługa sytuacji nietypowych jest jednak jednym z obszarów, w których wciąż pojawiają się błędy.

W chwili przeprowadzania naszego testu problem z zawieszającymi się plikami HEIC był zgłoszony w projekcie Gutenberg, a poprawka znajdowała się nadal w fazie prac i weryfikacji. Jeżeli czytacie ten artykuł po kolejnej aktualizacji WordPressa, warto więc wykonać ponowny test – zachowanie może być już inne.

Jak mimo wszystko dodać zdjęcie HEIC z iPhone’a?

Na szczęście błąd nie oznacza, że zdjęcie jest bezużyteczne. Jeżeli HEIC zawiesza się podczas przesyłania z komputera z Windowsem, mamy kilka prostych sposobów obejścia problemu.

• Prześlij zdjęcie bezpośrednio z iPhone’a. To najciekawsza alternatywa. Podczas wybierania fotografii do wysłania iOS może przekazać ją jako JPEG, dlatego WordPress otrzymuje już kompatybilny obraz i problem z pustym typem MIME pliku HEIC na Windowsie zostaje pominięty.
• Zapisz kopię jako JPEG na komputerze. Jeżeli Windows potrafi otworzyć zdjęcie HEIC, można zapisać jego kopię w bardziej uniwersalnym formacie i dopiero ten plik przesłać do WordPressa. Jest to rozwiązanie mniej wygodne, ale pewne i nie wymaga zmian po stronie strony internetowej.
• Dla przyszłych zdjęć można zmienić format zapisu w iPhonie. Ustawienie aparatu na format „Najbardziej zgodny” powoduje zapisywanie nowych fotografii w bardziej uniwersalnym formacie. Tracimy wtedy część korzyści wynikających z HEIC, ale unikamy problemów z kompatybilnością podczas dalszej pracy z plikami.

Jeżeli zależy nam przede wszystkim na wygodzie, pierwszą opcję przetestowałbym jako następną. Co ciekawe, w oficjalnych instrukcjach testowania WordPressa autorzy zwracają uwagę, że przesyłanie HEIC bezpośrednio z iPhone’a nie jest dobrym testem nowego mechanizmu przeglądarkowego właśnie dlatego, że telefon może wcześniej przekazać obraz jako JPEG.

Dla osoby, która chce przetestować technologię WordPressa, automatyczna konwersja wykonywana przez iPhone’a przeszkadza. Dla zwykłego użytkownika, który chce po prostu opublikować zdjęcie, jest natomiast bardzo wygodnym obejściem problemu.

Czy warto instalować dodatkową wtyczkę do HEIC?

Nie robiłbym tego od razu. WordPress 7.1 ma już własny mechanizm obsługi HEIC i obecny problem wygląda bardziej jak błąd konkretnej ścieżki rozpoznawania pliku niż całkowity brak tej funkcji.

Instalowanie dodatkowego rozszerzenia tylko po to, żeby obejść błąd, który może zostać poprawiony w kolejnej aktualizacji WordPressa, oznacza dokładanie następnego elementu do strony. Wtyczka może później ingerować w generowanie miniaturek, optymalizację albo pracę innych narzędzi do mediów.

Podobną zasadę warto stosować przy optymalizacji zdjęć. Najpierw sprawdzamy możliwości WordPressa, motywu i hostingu, a dopiero później dokładamy kolejne rozwiązania. Więcej na ten temat opisywaliśmy w artykule o szybkości ładowania strony i jej wpływie na SEO.

Jeżeli natomiast korzystacie z narzędzi ingerujących w obrazy, na przykład dodających znak wodny, po aktualizacji WordPressa warto również upewnić się, że działają poprawnie z nową ścieżką przetwarzania. Wcześniej przygotowaliśmy osobny test dotyczący dodawania znaków wodnych w WordPressie.

Podsumowanie naszego testu HEIC

Założenie było bardzo proste: bierzemy zdjęcie wykonane iPhone’em 11, zapisane jako HEIC, i przesyłamy je do WordPressa 7.1 bez wcześniejszej konwersji. Fotografia miała 4032 × 3024 piksele i około 2,5 MB, więc nie był to żaden specjalnie przygotowany plik laboratoryjny.

WordPress rozpoczął przesyłanie, ale operacja zatrzymała się na spinnerze. Początkowo podejrzenie padło na Windowsa, HEVC i wyłączoną akcelerację sprzętową Edge. Po przywróceniu poprawnego działania GPU potwierdziliśmy jednak sprzętowe dekodowanie HEVC, a test WebCodecs zwrócił supported: true.

Mimo tego zdjęcie nadal się nie przetwarzało.

Dopiero bezpośrednia kontrola pliku ujawniła kluczowy szczegół: Edge zwracał dla IMG_0227.HEIC pustą wartość File.type. To pokrywa się z problemem analizowanym obecnie przez twórców Gutenberga. WordPress może w takiej sytuacji nie skierować zdjęcia do właściwego mechanizmu HEIC, mimo że samo rozszerzenie pliku jest prawidłowe.

Dlatego odpowiedź na pytanie z tytułu brzmi dzisiaj: tak, WordPress 7.1 został zaprojektowany tak, aby zdjęcia HEIC z iPhone’a mogły być dodawane bez ręcznego konwertowania, ale w praktyce na niektórych konfiguracjach Windowsa nadal można natrafić na błąd.

Dobrą wiadomością jest to, że znamy już zarówno przyczynę naszego przypadku, jak i proste obejście. Jeżeli przesyłanie HEIC z komputera się zawiesza, możemy wysłać fotografię bezpośrednio z iPhone’a albo przygotować jej kopię JPEG. Warto też ponowić test po kolejnych poprawkach WordPressa, bo obsługa tego konkretnego przypadku jest już rozwijana.

I właśnie dlatego warto testować nowe funkcje na prawdziwych plikach. Dokumentacja mówi nam, jak mechanizm powinien działać. Dopiero zwykłe zdjęcie z telefonu pokazuje, jak działa naprawdę.

Jeżeli macie inne pytania odnośnie tworzenia stron internetowych, administracji stron internetowych lub pozycjonowania stron, śmiało piszcie do nas.