🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.rec.foto.cyfrowa
Article #911151

Re: ewentualne straty w konwersji 24bpp --> 8 bpp (obraz cz-b)

#911151
From: Marek S
Date: Sun, 25 Feb 2018 16:27
51 lines
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-mail
References: <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