Gimp, PSE, kompresja jpg i czerwona elipsa - podsumowanie
W moim poprzednim wpisie opisałem jak na własnej skórze przekonałem się, że migracja desktopu z Windows 7 do Linuksa jest krokiem do tyłu. Wpis wywołał lawinową ilość komentarzy a niektórzy z komentujących sugerowali mi konieczność kontrolnych wizyt u lekarzy specjalizujących się w urologii, okulistyce i psychologii. W końcu jednak obyło się bez takich konsultacji bo diagnoza jest w zasadzie prosta: ten system, w wydaniu desktopowym - nie jest dla mnie. Podkreślę - problemem nie jest system - tylko ja - jego użytkownik.
Jednym z przykładów jakim się w poprzednim wpisie posłużyłem, dla mnie zupełnie pobocznym ale jak się potem okazało - dla niektórych - kluczowym okazał się ten obrazek:
Tu muszę odszczekać co tam napisałem a i przy okazji sprostuję też często powtarzaną lecz całkowicie błędną opinię, o tym, że Gimp ma gorsze algorytmy kompresji jpg od programów Adobe. Bo jak się okazało:
Algorytm kompresji jpg jest standaryzowany i co za tym idzie, w każdym programie jest taki sam
Powyższe warto zapamiętać! Więcej informacji na ten temat jest tutaj.
Skoro więc algorytm kompresji jpg jest standaryzowany i co za tym idzie, w każdym programie jest taki sam - skąd się wzięła widoczna wyżej różnica? Wynika ona z odmiennych filozofii zapisu plików w formacie jpg w programach Photoshop Elements i Gimp. W tym pierwszym aby uzyskać dobrej jakości obrazek o małym rozmiarze wystarczy przesuwać suwak kompresji. Takie samo zachowanie w Gimpie prowadzi jednak na manowce bo w Gimpie trzeba kombinować i samodzielnie poustawiać opcje zaawansowane (ale owszem - w końcu się da - różnica w wielkości pliku zależy od tego czy razem z obrazkiem zapiszemy profil koloru a artefakty kompresji ukryć można poprzez ręczne i eksperymentalne ustawienie odpowiednich wartości parametrów Subsampling oraz DCT Method - więcej tutaj ).
Co ciekawe – niektóre z tych opcji są tak zaawansowane, że ich opis w dokumentacji Gimpa jest tylko zgrubszy a dodatkowo możemy wyczytać tam, że:
The JPEG algorithm is quite complex, and involves a bewildering number of options, whose meaning is beyond the scope of this documentation. Unless you are a JPEG expert, the Quality parameter is probably the only one you will need to adjust
Co w wolnym tłumaczeniu (po polsku nie znalazłem) znaczy: Algorytm JPEG jest dość skomplikowany i wiąże się z dużą liczbą opcji, których opis wykracza poza zakres tej dokumentacji. Jeśli nie jesteś ekspertem od JPEG, suwak „jakość” jest prawdopodobnie jedyną opcją jaką potrzebujesz zastosować.
Co mam więc na swoją obronę? Ano to, że zachowałem się przy zapisie pliku tak jak to opisano tutaj w dokumentacji programu. Cóż, najwyraźniej nie wiedziałem, że w tej logice to ja służę programowi a nie on mnie.