-
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.PO
STED!not-for-mail
From: Marek Wyszomirski <w...@t...net.pl>
Newsgroups: pl.rec.foto.cyfrowa
Subject: Re: 60D vs D7000 pytanie dla userów i fanów tabelek ;-)
Date: Sat, 09 Jul 2011 10:27:21 +0200
Organization: http://onet.pl
Lines: 154
Message-ID: <iv93d3$uc1$1@news.onet.pl>
References: <iv28tt$1gp$1@inews.gazeta.pl> <iv2ans$28m$1@news.task.gda.pl>
<iv2c3l$432$1@news.task.gda.pl> <iv6rkc$ph8$1@news.onet.pl>
<iv6vup$dna$1@news.task.gda.pl>
<d...@c...googlegroups.com>
<iv7gtt$k67$1@news.onet.pl>
<d...@d...googlegroups.com>
<iv7np4$l43$1@news.onet.pl>
<6...@h...googlegroups.com>
NNTP-Posting-Host: staticline12607.toya.net.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.onet.pl 1310200035 31105 85.89.170.68 (9 Jul 2011 08:27:15 GMT)
X-Complaints-To: n...@o...pl
NNTP-Posting-Date: Sat, 9 Jul 2011 08:27:15 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.18) Gecko/20110616
Thunderbird/3.1.11
In-Reply-To: <6...@h...googlegroups.com>
X-Antivirus: avast! (VPS 110708-1, 2011-07-08), Outbound message
X-Antivirus-Status: Clean
Xref: news-archive.icm.edu.pl pl.rec.foto.cyfrowa:879914
[ ukryj nagłówki ]W dniu 2011-07-09 08:38, XX YY pisze:
>>
>>> [...]
>>> kompresja jpeg jest kompresja znormalizowana.
>>
>> Jesteś pewien, ze z pliki z dwóch aparatów różnych producentów przy
>> nastawieniu np. na najsłabszą kompresję będą skompresowane w tym samym
>> stopniu? Bo ja mam co do tego dość poważne wątpliwości.
>>
>
> niczego nie jestem pewien.
> laboratoria tak porownuja.
> cudow nie ma. nie da sie w mniejszym pliku obrazowym tak samo
> komprymowanym zawrzec wiecej informacji.
Ano właśnie. Kluczowe są słowa 'tak samo komprynowanym'. Jęsli założenie
identycznej kompresji nie jest spełnione - wnioskowanie o rozdzielczości
na podstawie wiolekosci pliku może prowadzić do błędnych wniosków. A
producenci informacje o stopniu kompresji podają bardzo różnie (i
zazwyczaj mało precyzyjnie) - np. Pentax dla K-5 podaje do wyboru 4
stopnie kompresji - 'premium', 'best', 'better', 'good', Canon dla EOS-a
60D 2 stopnie - 'fine' i 'normal', Nikon dla D7000 3 stopnie - 'fine
1:4', 'normal 1:8' i 'basic 1:16'. Nawet jeśli przyjąć, że podawane
przez Nikona wartości to faktycznie jednoznaczne określenie stoipnia
kompresji a nie marketingowe przyblizenia, to jak porównać 'fine 1:4'
Nikona z 'fine' Canona, i czy bardziej odpowiada to 'best' czy tez
'premium' Pentaxa?
Do tego na algorytm wyliczania przez aparat pliku jpg wpływają dodatkowe
ustawienia - użytkownik ma wpływ na jasność, kontrast, nasycenie
kolorów, stopień wyostrzania. Ustawienie tych parametrów ma wpływ na
wielkosć uzyskanego pliku - a w różnych aparatach zarówno ustawienia
defaultowe jak i zakresy regulacji tych parametrów poprzez funkcje
użytkownika potrafią się znacząco różnić.
Nawet i sam balans bieli może mieć znaczny wpływ na wielkosć pliku jpg -
wyobraź sobie np. motyw który składa sie z dwóch części - niebieskiej i
czerwonej - i ma dużo szczegółów o małym kontraście w części
niebieskiej. W zależności od ustawienia balansu bieli jeden z tych
kolorów może być podbijany - i w efekcie wielkość pliku wyjściowego (i
ilość szczegółów w nim widocznych) będzie się różnić - mimo identycznej
rozdzielczości rejestrowanej przez matrycę (identyczny plik RAW).
> Uzywa sie troche moze niezrecznie pojecia rozdzielczosc .
> Byc moze zgrabniej by bylo nazwac te ceche "informatycznosc" lub
> zawartosc informatyczna.
> wszystko jedno .
> wielkosc pliku brutto zalezy od liczby pixeli,. w komprsji jpeg czyli
> 24b ( 3 B) np dla 12 mpx wielkosc pliku brutto bedzie ok 36 MB.
> Wielkosc pliku netto bedzie mniejsza i wynikac z tego jak obraz
> zostanie zapisany .
> Uzywa sie terminu "sprawnosc" czyli stosunek wielkosci pliku netto do
> brutto .
> fotografujac w celach porownawczych tablice testowa mozna wnosic o
> "informatycznosci" czyli jakosci odwzorowania.
> widac to b. dobrze robiac zdjecia tej samej tablicy testowej zoomem
> na roznych ogniskowach ( zawsze w tej samej skali odwzorowania ) .
> Pliki beda sie roznic sie od siebie wielkoscia w zaleznosci od tego
> jak ze zmiana ogniskowej zmienia sie rozdzielczosc obiektywu.
> Mozna ogolnie powiedziec i nikt chyba temui nie zaprzeczy , ze
> fotografujac ten sam obraz i zapisujac plik w ten sam sposob w jpeg ,
> plik wiekszy bedzie zawieral wiecej informacji ( czyli bedzie
> odwzorowanie bardziej subtelne).
Będzie zawierał więcej informacji, ale... nie tylko o zarejestrowanych
szczegółach obrazu ale i o szumach matrycy...
> Przy czym to nie jest jakas zaleznosc prostoliniowa - dwa razy wiekszy
> plik nie oznacza tym samym dwa razy wieksza rozdzielczosc obrazu w
> sensie lini /mm.
>
>
> Nie wnikalem w to jak ktore laboratorium traktuje pliki - czy licza
> je sami z RAW w ten sam sposob , czy biora je z puszki. W zasadzie
> poniewaz kompresja jpeg jest kompresja znormalizowana przypuszczam ze
> mozna rowniez porownywac pliki prosto z puszki . Aby wnosic o
> potencjale jakosciowym aparatu trzebaby porownywac pliki najwyzszej
> jakosci.
>
I nie ma żadnej gwarancji, zę ta najwyższa jakość oznacza identyczna
kompresję. Nie wiemy jak się ma 'premium' Pentaxa do 'fine' Canona czy
'fine 1:4' Nikona. Również w przypadku wyliczania jpg bezpośrednio z RAW
nie miałbym pewności - z jednej strony niektórzy producenci stosują
wstępne odszumianie plików RAW, z drugiej strony - wiadomo, ze te same
programy do obróbki RAW daja różne rezultaty w jakości obrazu w
pzrypadku RAW-ów różnych producentów. Natomiast w przypadku oceny plików
z tego samego typu aparatu z identycznie ustawiona czułością, balansem
bieli, stopniem kompresji i funkcjami użytkownika wpływającymi na sposób
wyznaczania pliku jpg wnioskowanie o rozdzielczości rejestrowanego
obrazu na podstawie wielkości pliku jpg jest jak najbardziej uzasadnione.
>
>
>
>>
>> Właśnie taka. Algorytm kompresji nie wie, czy zróżnicowanie sygnałów z
>> poszczególnych pikseli matrycy wynika z zarejestrowanych szczegółów
>> obrazu, czy z szumów.
>
> nie wiem . sadze ze ludzie ktorzy to robia zawodowo biora to pod
> uwage.
> trzebaby wprost zapytac laboratorium.
> ja przytoczylem wielkosc plikow jpeg dla tych dwoch aparatow jako
> wynik publikowany przez laboratorium.
>
> z tego co widze dla zdecydowanej wiekszosci aparatow ze wzrostem
> czulosci ( a wiec i szumow) wielkosc pliku spada - a wiec jednak jest
> to jakos uwzglednianie.
> Szumy mierzone sa oddzielnie.
>
Stosowane w aparatach algorytmy odszumiania jako skutek uboczny często
zjadają również szczegóły. Co do samego wpływu szumów na wielkość pliku
jpg - zrób sobie prosty eksperyment - weź jakiegoś zaszumionego tiff-a,
skompresuj w komputerze do jpg, a następnie wykonaj odszumianie tiffa
(tiffa a nie jpg-a) i po odszumieniu skompresuj do jpg jeszcze raz - i
porównaj wielkości uzyskanych plików jpg.
>>
>> Często na spadek rozmiarów pliku jpg przy dużych ISO wpływa agresywne
>> odszumianie stosowane przez niektórych producentów. Fakt, ze takie
>> odszumianie skutecznie 'zjada' też szczegóły obrazu.
>>
>
> wielkosc pliku jpeg z pewnoscia nie jest jedynym parametrem
> stanowiacym o jakosci obrazu . jest to jeden z aspektow.
> Ale b wygodnie w ten sposob porownuje sie np kompakty miedzy soba.
Jeśli kompresują obraz w podobny sposób - co może być spełnione, ale nie
musi. Na pewno ze zbyt małej wielkosci pliku jpg mozna wyciągnąć
wniosek, że obraz będzie kiepski - bo albo będzie mało szczegółów, albo
bardzo silne artefakty kompresji. Ale twierdzenie, że z dwóch aparatów
ktore dają pliki jpg o rozmiarach 3 i 4MB lepszy obraz bedzie z tego 4MB
jest już dość ryzykowne.
>
> Nie probowalem nigdy , ale moznaby sprobowac samem sfotografowac np
> strone gazety raz ostro , raz mniej i porownac wielkosci plikow jpeg
> czy sie beda roznic?.
A dlaczego maja się nie różnić? Przy gorszej ostrości ilość
rejestrowanej informacji bedzie mniejsza - pzrecież nikt rozsądny nie
neguje, zę ma to wpływ na rozmiar pliku jpg. Tyle, ze jest to tylko
jeden z czynników wpływajacych na ten rozmiar - i pzry różnych
ustawienaich aparatów albo co gorsza aparatach różnych producentów te
inne czynniki potrafią skutecznie zmienić wynik.
>
> Dla celow testowych uzywaja dosyc skomplikowanej tablicy.
Wiele z tych tablic jest dostępnych w sieci - można sobie ściągnać i
wydrukować. Może się tylko okazać, ze trzeba drukować w kawałkach i
sklejać dużą tablicę - jest to pewne utrudnienie, ale możliwe do pokonania.
--
Pozdrawiam!
Marek Wyszomirski (w...@t...net.pl)
Następne wpisy z tego wątku
- 09.07.11 09:47 XX YY
- 09.07.11 11:37 XX YY
- 09.07.11 14:21 JA
- 09.07.11 16:25 XX YY
- 09.07.11 21:56 Marek Wyszomirski
- 09.07.11 21:58 Marek Wyszomirski
- 10.07.11 06:58 XX YY
- 10.07.11 11:25 XX YY
- 10.07.11 12:40 Marek Wyszomirski
- 10.07.11 13:01 XX YY
- 10.07.11 13:47 Marek Wyszomirski
- 10.07.11 13:58 XX YY
- 10.07.11 14:08 Marek Wyszomirski
- 10.07.11 14:19 XX YY
- 10.07.11 14:19 Marek Wyszomirski
Najnowsze wątki z tej grupy
- Nikon D5500 i wyzwalanie migawki
- Canon 550D
- EOS 600D i balans bieli w filmach
- EOS 90D i sentymenty
- 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
Najnowsze wątki
- 2024-11-02 piszę list do św Mikołaja
- 2024-11-01 karta SIM nie działa w konkretnym smartfonie.
- 2024-11-01 Mamy WZROST! O 50% wzrosła ilość kredytów gotówkowych
- 2024-11-01 Warszawa => Expert Recruiter 360 <=
- 2024-11-01 Warszawa => Technical Leader (Java Background) <=
- 2024-11-01 Warszawa => Account Manager - Usługi rekrutacyjne <=
- 2024-11-01 Warszawa => Head of International Freight Forwarding Department <=
- 2024-11-01 Warszawa => Programista Dynamics 365 CRM <=
- 2024-11-01 Warszawa => Dynamics 365 CRM Developer <=
- 2024-11-01 Warszawa => Junior Rekruter <=
- 2024-11-01 Chrzanów => Specjalista ds. PR Produktowego <=
- 2024-11-01 Białystok => Full Stack web developer (obszar .Net Core, Angular6+) <
- 2024-11-01 Łódź => Frontend Engineer (Three.js) <=
- 2024-11-01 Warszawa => Junior Rekruter <=
- 2024-11-01 Gdańsk => Programista Full Stack .Net <=