-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.P
OSTED!not-for-mail
From: Marek S <p...@s...com>
Newsgroups: pl.rec.foto.cyfrowa
Subject: Re: Czy istnieje możliwość fotografowania rzeczywistości?
Date: Mon, 8 Apr 2019 19:38:21 +0200
Organization: ATMAN - ATM S.A.
Lines: 74
Message-ID: <q8g0uh$r1t$1@node2.news.atman.pl>
References: <q61ehc$lr2$1@node2.news.atman.pl>
<5c9e0f13$0$500$65785112@news.neostrada.pl>
<q7m7i9$6oo$1@node2.news.atman.pl>
<3...@4...net>
<q7o3p2$prf$1@node1.news.atman.pl>
<1...@4...net>
<q7qjoo$6jk$1@node2.news.atman.pl>
<1...@4...net>
<q7r3f0$l95$1@node2.news.atman.pl>
<1kh316fv8d7eg.11jnvlo4awlif$.dlg@40tude.net>
<q7r7ma$pc4$1@node2.news.atman.pl>
<1a6sq6byvqsz1.btyazkj1e5g9$.dlg@40tude.net>
<q7rddu$ujd$1@node2.news.atman.pl>
<5ca20e53$0$477$65785112@news.neostrada.pl>
<q7tss4$9dg$1@node2.news.atman.pl> <m...@p...waw.pl>
<q861pd$ap2$1@node1.news.atman.pl> <m...@p...waw.pl>
<q8apko$12d$1@node2.news.atman.pl> <m...@p...waw.pl>
<q8bdrt$kor$1@node2.news.atman.pl> <m...@p...waw.pl>
NNTP-Posting-Host: 89-70-94-204.dynamic.chello.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: node2.news.atman.pl 1554745105 27709 89.70.94.204 (8 Apr 2019 17:38:25 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Mon, 8 Apr 2019 17:38:25 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
Thunderbird/60.6.1
In-Reply-To: <m...@p...waw.pl>
Content-Language: pl
Xref: news-archive.icm.edu.pl pl.rec.foto.cyfrowa:910603
[ ukryj nagłówki ]W dniu 2019-04-08 o 00:40, Krzysztof Halasa pisze:
>
> Nie wiem jak miałoby to być możliwe bez kompresji dynamiki.
Czy to nie ja napisałem o kompresji do monitorowej i na co właśnie
odpowiadasz?
" to wyczyn. Ale daje się" :-D :-D
Trzeba sporo pracy włożyć, nie będzie to proces automatyczny, no ale
wyjścia nie ma.
> Jeśli źródło
> ma większą dynamikę niż monitor, to albo trzeba ją skompresować, albo
> poobcinać (albo jedno i drugie). Owszem, kompresja może być stała albo
> zależna od treści. Ale musi być.
Zgodnie z tym, co napisałem: nie wyobrażam sobie inaczej.
>> Usunie, bo matryce są wtedy więcej bitowe niż docierający 8-mio bitowy
>> sygnał. Zapoznaj się z monitorami np. EIZO, które posiadają 16-bitowy
>> LUT. Efekt skalibrowania monitora nie powoduje zniekształceń ciągłości
>> paska szarości jak to ma miejsce w monitorach bez LUT.
>
> No ale jakim cudem chcesz wyprodukować obraz o większej liczbie kolorów
> niż potrafi matryca?
Znów nie rozumiem skąd to pytanie. Nie da się!
> To nie jest możliwe i żaden LUT tego nie zmieni.
Ależ LUT bardzo to zmieni. Widzę, że nie masz z tym doświadczenia w
pracy. A dzieje się to następująco:
1. Karta daje kolor 3x8-bitowy (16777216kolorów)
2. Matryca daje 3x10-bitowy obraz (1073741824kolorów)
3. Różnica sięga więc miliarda kolorów. Ale to mało istotne.
4. Załóżmy, że wyświetlasz kolor szary (128,128,128). Mierzysz to
kalibratorem. 10cio bitowa matryca dostaje polecenie wyświetlenia
(512,512,512).
5. Zmieniasz odcień na (129,129,129). Matryca dostaje (516,516,516)).
Kalibrator wykrył nieliniowość pracy matrycy i dał odczyt (130,130,130).
6. Trzeba jakoś to naprawić a nie da się wysłać z karty odcienia (128.5,
128.5, 128.5).
7. I wtedy wkracza LUT, który potrafi tą różnicę podzielić nawet na 4
stopnie (10-8=2 bity). No i do tabeli konwersji dodaje wpis opisowo
"jeśli komputer przyśle (129,129,129), to skonwertuj to do coś pomiędzy
512 a 516 ... a to już się da zrobić! No i nasz kolor (129,129,129)
zyskuje nową reprezentację np. (514,514,514).
Oczywiście sam proces jest bardziej złożony - to jest tylko zobrazowanie.
> Tak jak napisałem, bandingu można się pozbyć ditheringiem, ale to jest
> przecież zwykłe (choć efektywne) oszukiwanie oczu.
Żadnego dihteringu nie ma.
>
> Tak naprawdę, wszystkie te korekcje tylko (zwykle nieznacznie)
> zmniejszają dynamikę matrycy LCD. LUT czy nie LUT.
Błąd - LUT nie modyfikuje niczego w okolicach czerni i bieli więc
dynamika jest zawsze taka sama. Zmienia się natomiast liniowość
poszczególnych składowych kolorów. W przypadku, gdy kalibracja jest na
karcie w kompie, lub matryca ma 8-bitów - otrzymujemy banding. Gdy
matryca jest więcej bitowa - gradient będzie gładki jak pupa niemowlaka.
Oczywiście banding będzie ograniczony do sygnału o dyskretnych
wartościach 0...255. Nie będzie natomiast przeskoków 128->130 jak przy 8
bitach. Tak więc LUT w monitorze z matrycą 8-bitową jest problematyczny.
--
Pozdrawiam,
Marek
Następne wpisy z tego wątku
- 08.04.19 19:44 Marek S
- 08.04.19 19:53 Marek S
- 08.04.19 19:58 Marek S
- 08.04.19 20:11 Marek S
- 08.04.19 22:03 Starzec z Gór
- 08.04.19 22:16 Starzec z Gór
- 08.04.19 23:23 Marek S
- 09.04.19 00:27 Starzec z Gór
- 09.04.19 16:48 Krzysztof Halasa
- 09.04.19 17:00 Krzysztof Halasa
- 09.04.19 17:40 Marek S
- 09.04.19 18:13 Marek S
- 09.04.19 18:39 Marek S
- 09.04.19 18:43 Starzec z Gór
- 09.04.19 20:14 Marek S
Najnowsze wątki z tej grupy
- Skanowanie: Canon MG2550S vs HP OfficeJet 6950
- czas exif a czas modyfikacji pliku
- karta SD po formacie odzyskiwanie zdjęć i filmów
- Chess
- Vitruvian Man - parts 7-11a
- Eltec nie zyje?
- Steve McCurry
- Light - lajkowe klasyki od Chinczykow
- Forum o Sony serii A (alfa)?
- obrobka RAW na konputerze
- Sklejanie bracketowanych JPGów
- silentpeakphoto
- Powerbank w ksztalcie raczki monopodu?
- Po jakiemu gada Nikon?
- Czy ktos z Was używa aparatu 360°?
Najnowsze wątki
- 2024-07-02 Realme 7 Na co zmienić?
- 2024-06-27 Prywatny parking? Pierwsze 10 minut bezplatnie
- 2024-07-02 znalazłem samochód ;)
- 2024-07-02 Pierwszeństwo łamane
- 2024-07-02 zamek
- 2024-07-02 Akumulatory VRLA
- 2024-07-03 Białystok => Inżynier DevOps Conexa First (Kontraktor) <=
- 2024-07-03 MĂźnchen => Test Development Engineer (m/w/d) <=
- 2024-07-03 Warszawa => Full Stack web developer (obszar .Net Core, Angular6+) <=
- 2024-07-03 Warszawa => Programista Full Stack (.Net Core) <=
- 2024-07-02 Kraków => Spedytor międzynarodowy <=
- 2024-07-02 Poznań => Senior React Native Developer <=
- 2024-07-02 Rzeszów => Frontend Developer (React) <=
- 2024-07-02 Warszawa => Fullastack (Java) Developer <=
- 2024-07-02 reparacje