utrata jakości przy obracaniu

[pietro.s]

Witam
przeglądając w windowsowym podglądzie zdjęć fotki chcąc obrócić z pionu w poziom wyskakuje komunikat ze jeżeli obrócę jakość zdjęcia sie pogorszy. czy tak jest w każdym programie? i na czym może polegać ta utrata jakości?

[Misiaque]

Nie w każdym, utrata jakości następuje gdy obraz jest dekompresowany, potem obracany i kompresowany z powrotem (w przypadku stratnych formatów jak JPEG). Każda modyfikacja takiego pliku i jego ponowna kompresja zmniejszy nieco jakość (zależy to od stopnia kompresji).

IrfanView z jedną ze wtyczek oferuje bezstratne operacje JPEG, w tym obracanie. Są też programy, które potrafią wycinać kawałki JPEGów bezstratnie (w google wpisz "jpeg lossless croping" lub "jpeg lossless crop")

Tego podglądu Windowsowego w ogóle bym nie używał, po tym jak przeczytałem jeden z komunikatów (zdjęcie za duże by je obrócić czy coś w tym rodzaju) stwierdziłem, że on sam nie wie co i jak robić :]

Zainstaluj IrfanView + wszystkie wtyczki i będziesz zadowolony.

[Diodak]

Dobre programy przy obracaniu zdjęć maja opcję "lossless" przy obracaniu i odbijaniu lustrzanym JPEG. Transformując układają nowy obraz jak klocki w innej kolejności bez utraty jakości (bez ponownego kompresowania).

W Windows po obrocie fotka jest ponownie kompresowana. Nie wiem jakie sa parametry kompresji ale zdjęcia mają mniejszy rozmiar niż wcześniej więc na pewno jest to silniejsza kompresja.

Edit:

Misiaque uprzedziłeś mnie ;) ... też polecam IrfanView bo prosty i darmowy.

[Elmarqo]

Dobre programy przy obracaniu zdjęć maja opcję "lossless" przy obracaniu i odbijaniu lustrzanym JPEG. ... też polecam IrfanView bo prosty i darmowy.

Fast Stone również bezstratnie obraca zdjęcia?

[Janusz Body]

Fast Stone również bezstratnie obraca zdjęcia?

Tak. "...as well as lossless JPEG transitions..."

http://www.faststone.org/FSViewerDetail.htm

Nie wiem czy Ifran już się dorobił CMSa - FastStone ma to od zawsze :)

[ewg]

Podgląd windowsowy również obraca bezstratnie jpegi... ale nie wszystkie! Jeśli oba boki fotki mają wymiary w pixelach podzielne całkowicie przez 8* (patrz: EDIT), to możliwy jest obrót bezstratny. Jak już ktoś wspomniał - "bloki" jpega nie są ruszane, a tylko modyfikowana jest informacja o ich orientacji. Nigdy tego dalej nie zgłębiałem, ale możliwe, że są różne jpegi i różne mogą mieć te bloki, np. wielokrotność 8, ale i tak wtedy będą podzielne przez 8, no nie? ;-)

Sądząc choćby po moim 400d rozmiar fotek 3888 x 2592 pixela nie jest wcale maksymalnym jaki jest w stanie wygenerować matryca, ale chyba właśnie ze względu na bezstratną obróbke jpegów został on tak znormalizowany/zaokrąglony, żeby można je było chociażby bezstratnie obracać.

Problem z podglądem windowsowym jest taki, że o ile wyskakuje komunikat o niebezpieczeństwie odwracania to pół biedy (bo od razu wiadomo, że rozmiar nie jest podzielny przez 8* ), ale jest tam opcja (do odfajkowania), żeby go więcej w przyszłosci nie wyświetlać! i to jest najgorsze co można tu zrobić, bo potem moża rzeczywiście nieświadomie odwrócić niewymiarowego jpega stratnie i później żyć w przekonaniu, że Windows psuje przy obracaniu wszystkie jpegi, choć tak nie jest.

Przywrócenie ostrzeżenia o stratnym odwracaniu jpega w Windowsie można osiągnąć przez zmodyfikowanie rejestru, ale musiałbym poszukć. Dopiszę jak znajdę! ;-)

EDIT: *Właściwie powinno być 16 a nie 8!

[Janusz Body]

....
Sądząc choćby po moim 400d rozmiar fotek 3888 x 2592 pixela nie jest wcale maksymalnym jaki jest w stanie wygenerować matryca, ale chyba właśnie ze względu na bezstratną obróbke jpegów został on tak znormalizowany/zaokrąglony, żeby można je było chociażby bezstratnie obracać.....

Mocne twierdzenie. Coś w tym jest ale ta "podzielność przez 8" to nie jest jedyny i najważniejszy powód rozmiaru/rozdzielczości matrycy/zdjęcia. W 400D jest:

Effective Pixels: Approx. 10.10 megapixels
Total Pixels: Approx. 10.50 megapixels

(http://www.robgalbraith.com/public_files/Canon_Rebel_XTi_White_Paper.pdf)

Piksele z obrzeża matrycy są wykorzystywane tylko do interpolacji (nie są, nie mogą być wyświetlane), tak aby skrajne rzędy na finalnym zdjęciu miały poprawne barwy. Aparat, nawet ustawiony na jpegi "wywołuje" je z RAWa - robi to komputer pokładowy Digi-cośtam i jemu są potrzebne te dodatkowe piksele. W 5D jest jeszcze śmieszniej bo piksele nie są kwadratowe i tu teoria i konstrukcji matrycy "pod jpega" już się zupełnie nie wyrabia.

[ewg]

Piksele z obrzeża matrycy są wykorzystywane tylko do interpolacji (nie są, nie mogą być wyświetlane), tak aby skrajne rzędy na finalnym zdjęciu miały poprawne barwy. Aparat, nawet ustawiony na jpegi "wywołuje" je z RAWa - robi to komputer pokładowy Digi-cośtam i jemu są potrzebne te dodatkowe piksele. W 5D jest jeszcze śmieszniej bo piksele nie są kwadratowe i tu teoria i konstrukcji matrycy "pod jpega" już się zupełnie nie wyrabia.

Brzmi logicznie tylko dlaczego taki RawShooter, chociaż "tylnymi drzwiami" ale wyświetla wszystkie (te ponad rozmiar podzielny przez 8 również) pixele pliku DNG i nie widać na obrzeżach braków kolorystycznych? :confused:

ps. RS oczywiście przerobiony, żeby otwierał DNG z 400D.

[Janusz Body]

....
ps. RS oczywiście przerobiony, żeby otwierał DNG z 400D.

Pytaj tego co przerabiał RSE :mrgreen:

Ten podział "na 8" to tak dodatkowo "dwie pieczenie przy jednym ogniu" ale główny powód to technika - matryca Bayera i interpolacje barw z nią związane. Musi być więcej pixeli dookoła, żeby było z czego interpolować/intepretować barwy.

Jak się bardzo uprzeć to można by było napisać programik wyświetlający wszystkie piksele z matrycy ale i tak "obwódka" będzie bezużyteczna bo brakuje informacji o barwach.

[ewg]

Pytaj tego co przerabiał RSE :mrgreen:

To musiałbym sam siebie spytać... ;-)

Jeszcze obiecany trick odblokowujący ostrzeżenie o obracaniu niewymiarowych jpegów w windowsowym podglądzie. Trzeba usunąć dwie "wartości" (czyli również "dane"!):

"ShellImageViewWarnOnLossyRotate"="no"
z [HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\DontShowMeThisDialogAgain]
oraz
"ShellImageViewWarnOnLossyRotate"=dword:00000006
z [HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\ShellImageView]

Ale jest też łatwiejszy sposób: Wystarczy trzymać klawisz CTRL podczas zamykania podglądu krzyżykiem w prawym górnym rogu okna i zgodzić się na przywrócenie ustawień domyślnych podglądu. ;-)

[muflon]

Jak się bardzo uprzeć to można by było napisać programik wyświetlający wszystkie piksele z matrycy ale i tak "obwódka" będzie bezużyteczna bo brakuje informacji o barwach.
Ja napisalem :-D W 10D bylo mniej wiecej tak, ze dookola tego co dostajemy z konwertera RAW (nawet dcraw) jest jeszcze czarna obwodka, o grubosci ok. kilkunastu pikseli (z wyjatkiem jednej strony, tam bylo chyba prawie setka). Tam sa normalne detektory, tylko swiatla brak :) Podejrzewam ze po prostu sensor jest robiony jakos "z zapasem".

[Janusz Body]

Ja napisalem :-D ....

Znaczy się "bardzo uparty" jesteś :)

[ewg]

W 5D jest jeszcze śmieszniej bo piksele nie są kwadratowe i tu teoria i konstrukcji matrycy "pod jpega" już się zupełnie nie wyrabia.

Wybacz ale dopiero teraz załapałem, że nie załapałem. :oops:

To jak to jest z tym 5d? Jeśli piksele nie są kwadratowe to jakie? Chętnie bym o tym poczytał bo pierwszy raz słyszę, żeby Canon kombinował z klasycznym Bayerem. Szukałem tylko na DPreview.com jak i w Canon_EOS_5D_White_Paper.pdf i nie ma wzmianki. Jak sobie podzieliłem rozmiar matrycy przez produkowane piksele to mi wyszło w zaokrągleniu 0,082mm na każdy bok piksela, czyli przynajmniej efekt jest taki jakby fotokomórki były logicznymi kwadratami... Chyba nie chodzi Ci o to wspomniane zaokrąglenie, które pewnie wynika z braku dokładnych danych o wymiarach samej matrycy (0,0819 x 0,0821mm - to już właściwie prostokąt).

Teraz załóżmy, że matryca jest jakaś z kosmosu, powiedzmy wielokąty, kółka, porozrzucane nieprostopadle po matrycy. Na razie nijak się to ma do znanych wszystkim prostokątnych komputerowych pikseli. Co musi zrobić inżynier projektujący taki sensor dla współczesnej cywilizacji cyfrowej? - Ano przerobić z niego sygnał na zwykłe kwadratowe piksele. Inżynier wie róznież, że większość ludzi na tym świecie pstyka dziś w jpegach. Znajac zasadę bloków po 8x8, bedzie sie starał tak projetować jego niesamowitą matrycę żeby i tak była zgodna z przyjętymi normami lub z minimalnym nadmiarem jeśli to konieczne. Dlatego sądzę, że kształt komórek sensora nie ma wiekszego wpływu na to czy zasada podzielności przez 8 może być rozstrzygajaca dla projektu matrycy lub nie.

Ale tak jak już napisałem - chętnie bym jeszcze coś doczytał jeśli się mylę. :rolleyes:

[Janusz Body]

.....
To jak to jest z tym 5d? Jeśli piksele nie są kwadratowe to jakie? Chętnie bym o tym poczytał bo pierwszy raz słyszę, żeby Canon kombinował z klasycznym Bayerem. Szukałem tylko na DPreview.com jak i w Canon_EOS_5D_White_Paper.pdf i nie ma wzmianki. Jak sobie podzieliłem rozmiar matrycy przez produkowane piksele to mi wyszło w zaokrągleniu 0,082mm na każdy bok piksela, czyli przynajmniej efekt jest taki jakby fotokomórki były logicznymi kwadratami... Chyba nie chodzi Ci o to wspomniane zaokrąglenie, które pewnie wynika z braku dokładnych danych o wymiarach samej matrycy (0,0819 x 0,0821mm - to już właściwie prostokąt).
......
Ale tak jak już napisałem - chętnie bym jeszcze coś doczytał jeśli się mylę. :rolleyes:


Hmmmm... czytałem o tym jakieś rok temu i już nie pamiętam gdzie. :( Z całkowitą pewnością ktoś pisał o tym, że poszczególne fotocele na matrycy 5D są prostokątne - prostokąty o dłuższym pionowym boku (w ułożeniu landscape). Jako rezultat tej "niekwadratowości" zalecał wołać RAWy w ACR z rozdzielczością "oczko wyżej" - tj 5120 x 3413 (w ACR na + czyli 17 Mpix).

Z tego co czytałem zapamiętałem tylko, o tej prostokątności i wołaniu RAWu "w górę". Teraz jakoś nie mogę tego wygooglać :)

To nie jest jedyny "dziwny" sposób ułożenia sensorów na matrycy bayerowskiej. Sony kombinuje z czwartym kolorem i (chyba) z ułożeniem "plaster miodu".

EDIT: Jeśli dobrze sobie przypominam rysunek to prostokąty nie są ułożone "wierszami" a zachodzą na siebie co nieco przypomina ten plaster miodu - ale tu pewności nie mam.

[Don Kacper]

A ja empirycznie postanowiłem sobie to wszystko sprawdzić. Po obróceniu o 90* (do pionu) przyrost wielkości 180* spadek i 360* spadek w stosunku do początkowej wartości. Ciekawy jest ten początkowy przyrost. Obracane foto z 400D.

Dziękuję za uwagę

[Misiaque]

To nie jest jedyny "dziwny" sposób ułożenia sensorów na matrycy bayerowskiej. Sony kombinuje z czwartym kolorem i (chyba) z ułożeniem "plaster miodu".
No a Fuji już wykombinowało...

[Misiaque]

Brzmi logicznie tylko dlaczego taki RawShooter, chociaż "tylnymi drzwiami" ale wyświetla wszystkie (te ponad rozmiar podzielny przez 8 również) pixele pliku DNG i nie widać na obrzeżach braków kolorystycznych? :confused:

ps. RS oczywiście przerobiony, żeby otwierał DNG z 400D.

Trochę nieświeży temat, ale zawsze warto wyjaśnić: z tego co czytałem wynika, że pomijanie brzegowych pikseli matrycy pozwala uprościć logikę przetwarzania informacji z nich czerpanych.

W algorytmach przetwarzania obrazów (np. filtrach splotowych, jakimi sa np. rozmycie, wyostrzenie) istnieje problem traktowania obszarów brzegowych, maska filtra (a więc obszar obrazu z którego informacji filtr korzysta dla obliczenia nowej wartości danego piksela) może wychodzić poza obraz. Problem ten w programach graficznych rozwiązuje sie na wiele sposób, np. powiela brzegowe piksele, dokleja się lustrzane odbicie krawędzi obrazu, zmienia dynamicznie rozmiar maski, etc.

Takie podejście, choć skuteczne, jest skomplikowane. W aparatach dla szybkości przetwarzania stosuje sie specjalizowane układy logiczne, które przetwarzanie obrazu realizują sprzętowo. Powierzchnia układu scalonego kosztuje, do tego im prostszy algorytm tym prostsza a zatem równiesz szybsza będzie jego realizacja sprzętowa. Z tego powodu problem krawędzi rozwiązuje się w najprostszy (w programach graficznych nie stosowany z oczywistych względów) sposób - pominięcie pikseli znajdujących się na krawędziach matrycy. Matryca ma zapas pikseli, te na krawędziach na ostateczny obraz same w sobie nie trafią, ale zagwarantują prawidłowe działanie algorytmu interpolacji. Ileż to upraszcza! Lecimy tymi samymi obliczeniami po wszystkich "efektywnych" pikselach, nie ma żadnych specjalnych przypadków przy krawędziach obrazu, żadnych alternatywnych wariantów i rozróżnień. Nigdy nie zdarzy się, że dla któregoś przetwarzanego piksela mamy dane tylko o jego otoczeniu z prawej dolnej strony, czy też tylko na prawo od niego.

Komputery nie muszą przerabiać materiału z matrycy w błyskawicznym tempie, a i procesor może robić wszystko, stąd twórcy wywoływaczy RAWów mogą sobie pozwolić na przetwarzanie danych z całej matrycy, a nie tylko dla "efektywnych" pikseli. Rozpatrywanie brzegów po prostu nie kosztuje tyle na komputerze, co w aparacie.

[Ciosna]

A co z obracaniem np w ZoomBrowser. Również jest bezstratne :?:

[ewg]

Misiaque, rozumiem jeden, dwa, ale po co tracić aż kilkanaście rzędów pixeli brzegowych, które w dodatku dają obraz takiej samej jakości jak wszystkie pozostałe pixele (aż po sam kraniec matrycy! - sprawdzałem). Konkretnie który z procesów obróbki sygnału potrzebuje aż takiego zapasu na krawędziach (bo na pewno nie bayerowska interpolacja)? No i dlaczego przypadkiem wymiary finalnego zdjęcia są zawsze całkowicie podzielne przez 8? - Mnie tu śmierdzi na kilometr zwykłym komputerowym bajtem. :rolleyes:

[Bahrd]

Na tyle, na ie potrafię: 8 pikseli to ukłon wobec wspomnianej przez Misiaqua prostoty kodera - w tym wypadku właśnie JPEG-owego, bo on dzieli każdy obrazek na bloczki 8x8.
Jeśli chodzi o zapas na brzegach - interpolacja potrzebuje tym więcej sąsiednich pikseli im jest wyższego rzędu - i taka sześcienna (najbardziej popularna) potrzebuje bodajże po cztery "z lewa i prawa". Wyższych rzędów - o ile się znam - nie stosuje w "normalnej" fotografii, bo ludzkie oko i tak nie widzi różnicy, a poza tym trudniej wówczas odtwarzać krawędzie. Ale w zastosowaniach "nienormalnych" (np. gdy obrazy analizuje się i przetwarza się maszynowo) być może takie interpolacje się stosuje.
Innym powodem może być obecność filtru AA, który z definicji rozmywa światło po pikselach, a zatem "ściemnia" te z brzegu.

[muflon]

Konkretnie który z procesów obróbki sygnału potrzebuje aż takiego zapasu na krawędziach (bo na pewno nie bayerowska interpolacja)?
Najprostsza nie - ale bardziej zaawansowane metody (VNG chociażby) "sięgają" trochę dalej niż jeden piksel obok :) Choć w sumie kilkanaście to też nie :)

A co do rozmiarów to już Bahrd napisał: JPEGa nie da się zapisać inaczej niż kwadracikami 8x8. Znaczy: można (chyba) sprawić, że on będzie "wyglądał" jak np. 543x321px, ale i tak w środku będzie zaokrąglony :)