Article View: pl.rec.foto.cyfrowa
Article #911151Re: ewentualne straty w konwersji 24bpp --> 8 bpp (obraz cz-b)
From: Marek S
Date: Sun, 25 Feb 2018 16:27
Date: Sun, 25 Feb 2018 16:27
51 lines
3758 bytes
3758 bytes
W dniu 2018-01-29 o 19:37, 1634Racine pisze: > Czy NIC sie nie straci, jesli przed tymi korekcjami przekonwertuje sie > obrazy/klatki do: skala szarosci, gl. kolorow 256, 8 bpp? Odpowiem lekko nie na temat. Sądzę, że nawet nie o to chodzi czy 8, czy 24 bity bo dla idealnej szarości (bez barwnych dominant) nie powinno to mieć znaczenia. Można sporo stracić pracując ogólnie w 256 odcieniach szarości - nie ważne czy 8, czy 24 bity. Wiele zależy od środowiska w jakim pracujesz w sensie sprzętu i operacji graficznych. Łatwo to zaobserwować przy przejściach tonalnych - bardzo często powstaje zjawisko color bandingu, nie wiem jak to po polsku się nazywa (posteryzacja?). Granica między odcieniami może mieć widoczne granice. Co ciekawe - najmniej będzie to widoczne na zwykłych monitorach sRGB i nieskalibrowanym systemie. Po dokonaniu kalibracji mogą pojawić się widoczne "prążki" wyolbrzymione po graficznych korekcjach obrazu. Zastosujesz monitor aRGB - zjawisko jeszcze bardziej będzie widoczne. Przy profesjonalnych, więcej niż 8-bitowych monitorach aRGB z hardware'ową korektą kolorów (LUT) powstanie masakra. Przy obrazach kolorowych jeszcze jakoś to się rozmywa - bo są odcienie barw, kanały koloru wzajemnie maskują swoje ograniczenia. Ale przy obrazie mono trzeba zadbać o jakość obróbki. Wyobraź sobie sytuację kiedy stosujesz jakieś krzywe luminancji przy obróbce. Mam na myśli krzywą gamma lub np. krzywą typu S (zwaną kontrastem). Wtedy sztucznie zwiększasz odległość między kolejnymi odcieniami szarości. Przykładowo miałeś szary na poziomie 200 i 201, które po korekcie staną się 195 i 205. Granica między nimi będzie doskonale widoczna. Z uwagi na powyższe NIGDY nie pracuj na 8 bitach nawet jeśli zeskanowany obraz był 8-bitowy. Plik 8-bitowy powinien być jedynie produktem końcowym gdy zamierzasz go pokazać w internecie, przesłać komuś mailem itp. Pracuj zawsze na 16 bitach. Nie zgadzam się z Sylwestrem, że byłoby najlepiej pracować na 32-bitach. Teoretycznie byłoby to uzasadnione (i idealne rozwiązanie) ale powstaje problem praktyczny - poza specjalistycznymi monitorami/kartami HDR (i to też z ograniczeniami) nie da się w miarę poprawnie zobrazować efektów pracy. Trzeba sobie póki co wyobrażać jak będzie wyglądał mniej bitowy efekt końcowy. W dodatku np. w Photoshopie niewiele, nawet spośród podstawowych filtrów działa w tym trybie. Jest jeszcze jedna rzecz: sposób obróbki zdjęć. Jeśli proces obróbki będzie miał wiele etapów to staraj się pracować możliwie bezstratnie. Np. stosuj filtry typu live, trzymaj obraz wielowarstwowy, gdzie dolna warstwa jest nietknięta (kopia bezpieczeństwa). -- Pozdrawiam, Marek
Technical Details
Message-ID:
<p6uo5i$175$1@node1.news.atman.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mailReferences:
<5a6f69e5$0$679$65785112@news.neostrada.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail From: Marek S <precz@spamowi.com> Newsgroups: pl.rec.foto.cyfrowa Subject: Re: ewentualne straty w konwersji 24bpp --> 8 bpp (obraz cz-b) Date: Sun, 25 Feb 2018 17:27:25 +0100 Organization: ATMAN - ATM S.A. Lines: 51 Message-ID: <p6uo5i$175$1@node1.news.atman.pl> References: <5a6f69e5$0$679$65785112@news.neostrada.pl> NNTP-Posting-Host: 89-69-207-111.dynamic.chello.pl Mime-Version: 1.0 X-Trace: node1.news.atman.pl 1519576050 1253 89.69.207.111 (25 Feb 2018 16:27:30 GMT) X-Complaints-To: usenet@atman.pl NNTP-Posting-Date: Sun, 25 Feb 2018 16:27:30 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-Reply-To: <5a6f69e5$0$679$65785112@news.neostrada.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit