-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.onet.pl!.POSTED!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: Sun, 10 Jul 2011 14:40:10 +0200
Organization: http://onet.pl
Lines: 123
Message-ID: <ivc6j4$ipv$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>
<iv93d3$uc1$1@news.onet.pl>
<7...@n...googlegroups.com>
<f...@w...googlegroups.com>
<ivaiu8$p3k$2@news.onet.pl>
<3...@1...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 1310301604 19263 85.89.170.68 (10 Jul 2011 12:40:04 GMT)
X-Complaints-To: n...@o...pl
NNTP-Posting-Date: Sun, 10 Jul 2011 12:40:04 +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: <3...@1...googlegroups.com>
X-Antivirus: avast! (VPS 110710-0, 2011-07-10), Outbound message
X-Antivirus-Status: Clean
Xref: news-archive.icm.edu.pl pl.rec.foto.cyfrowa:879947
[ ukryj nagłówki ]W dniu 2011-07-10 08:58, XX YY pisze:
>>
>> Podaj jeszcze metodę sprawdzania, czy pliki z różnych aparatów są
>> jednakowo skompresowane - bo bez takiego sprawdzenia porównywanie ich
>> proponowaną przez Ciebie metodą nie ma sensu.
>>
>[...]
>
> Podchodzisz blednie , bez zrozumienia do problemu.
>
Naprawdę? Chyba o sobie piszesz.
> 1. o wyniku ostatecznym swiadczy wielkosc pliku.
> ten plik ktory jest wiekszy ten zawiera wiecej informacji.
Bzdura. W przypadku pliku skompresowanego jego wielkość zależy zarówno
od zawartości informacji jak i zastosowanego algorytmu kompresji. I może
być tak, że z dwóch plików jpg ten mniejszy bedzie zawierał więcej
informacji.
> Jezeli skomprymujesz plik na 80% jakosci inny na 100% jakosci i ten na
> 80% jakosci bedzie wiekszy to mimo wiekszego stopnia kompresji bedzie
> on zawieral wiecej informacji - a wiec lepszy obraz To tylko uwaga
> marginalna.
Może i marginalna, ale nieprawdziwa. Większy plik _może_ zawiarać wiecej
informacji, ale wcale nie musi.
> moznaby powiedziec ze stopien kompresji jest bez znaczenia , decyduje
> wielkosc pliku.
Nieprawda. Stopień kompresji _też_ ma znaczenie.
Prosty eksperyment - wziąłem plik tiff i zrobiłem z niego za pomocą
ptego samego programu Photoimpact dwa pliki jpg. Pierwszy - poprzez
zapis zapis pliku jpg z jakością kompresji 70%. Efekt - plik o rozmiarze
43154 bajty - do pobrania pod adresem
http://www.toya.net.pl/~wyszomir/rozne/bokochod08463
h.jpg
Drugi - najpierw wykonałem silne rozmycie oryginalnego pliku za pomiocą
funkcji 'gaussian blur' a nastepnie zapisałem jako jpg z jakością
kompresji 95%. Efekt - plik o rozmiarze 64630 bajtów - do pobrania pod
adresem http://www.toya.net.pl/~wyszomir/rozne/bokochodblur.
jpg
Proponuję obejrzeć i ocenić, który z nich zawiera więcej informacji.
> Oczywistym jest ze w celach porownawczych mozliwosci sprzetu nalezy
> stosowac znormalizowane warunki - a wiec ten sam najlepszy stopien
> kompresji.
>
Przede wszystkim _jednakowy_ stopień kompresji. Fakt, że warto, aby był
też pzry okazji możliwie najlepszy. A sęk w tym, ze dla różnych aparatów
będziemy mieli z zapewnieniem tej jednakowości problem.
> 2. Pisalem o tym aby porownac miedzy soba rozne aparaty to musi byc
> fotografowany dokladnie ten sam motyw - powiedzmy ta sama tablicy
> testowa.
Z tym się zgadzam.
> Nalezaloby tak przetworzyc pliki raw w jpeg aby uzyskac
> najwieksza mozliwa wielkosc pliku. I wowczas mozna porownywac. Nic
> nie stoi na przeszkodzeie aby pliki RAW z roznych aparatow wywolac ta
> sama wolarka do raw ow i dokonac w niej zawsze w tym samym stopniu
> kompresji do jpeg. Gdzie tu problem ? To jest tak oczywiste , ze dziwi
> mnie , ze w ogole o tym wspominasz.
>
Zacytuję zatem fragment Twojego wczorajszego listu:
'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.'
Otóż cały czas wykazuję, ze porównywanie plików jpg z puszki może
prowadzić do błędnych wniosków. A i co do wyciągania wniosków z plików
wytworzonych tym samym algorytmem z plików RAW też byłbym ostrożny -
niektórzy producenci stosują wstępne odejmowanie wartosci 'bias' z
sygnału matrycy oraz odszumianie plików RAW co też moze wpływać na
wielkosć uzyskiwanego pliku jpg.
> [...]
> A w skrocie jak to mozna szybko porownac np wlasny aparat w warunkach
> domowych z roznymi obiektywami i na roznych czulosciach?:
>
> zwyczajnie kolorowy plakat zawieszony na scianie fotografowalbym lampa
> blyskowa , zmieniajac czulosc , ogniskowe , przyslony.
> porownalbym wielkosci plikow jpeg - to da praktycznie uzyteczna metode
> poznania mozliwosci wlasnego sprzetu .
> Mozna wrecz natychmiast uzyskac odpowiedz np na pytanie : na jakich
> przyslonach i ogniskowych moj zoom pracuje najlepiej ?
>
Dla jednego typu aparatu i identycznych ustawień wpływajacych na sposób
wyliczania plików jpg - zgoda.
> Oczywiscie ze w ten sposob nie da sie dokladnie pomierzyc wszystkich
> bledow optycznych obiektywu.
>
> Ale obraz majacy np 21 MB musi byc lepszy ob obrazu 14 MB.
>
Przy założeniu jednakowej kompresji. Jeśli to założenie nie jest
spełnione - nie musi.
> W zasadzie dostaniesz w ten sposob najobiektywniejsza odpowiedz na
> pytanie : ktory aparat daje lepsza jakosc obrazu.
>[...]
Na podobnej zasadzie można by próbować na podstawie mocy silnika
wyrabiać sobie zdanie, który samochód będzie miał lepsze przyspieszenie.
I pewne wnioski można faktycznie wyciagnąć - bo jeśli samochód ma silnik
o mocy 40KM to bez większego ryzyka można powiedzieć, ze będzie
przyspieszał dość ślamazarnie. Ale już kategorycznego twierdzenia, ze
ten, który ma silnik 200KM będzie przyspieszał lepiej od takiego z
silnikiem 130KM bym nie ryzykował - bo może się okazać, ze ten pierwszy
to ciężka limuzyna ważąca 2.5 tony, a ten drugi - lekki dwuosobowy
samochód sportowy...
--
Pozdrawiam!
Marek Wyszomirski (w...@t...net.pl)
Następne wpisy z tego wątku
- 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
- 10.07.11 14:32 XX YY
- 10.07.11 15:07 Paweł W.
- 10.07.11 15:28 Andrzej Libiszewski
- 10.07.11 15:50 XX YY
- 10.07.11 16:09 Marek Wyszomirski
- 10.07.11 16:12 Marek Wyszomirski
- 10.07.11 16:21 Marek Wyszomirski
- 10.07.11 17:30 XX YY
- 10.07.11 17:28 XX YY
Najnowsze wątki z tej grupy
- Trochę NTG - Vegas Pro
- 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
Najnowsze wątki
- 2025-03-11 Warszawa => Kierownik ds. kluczowych Klientów <=
- 2025-03-11 Łódź => System Administrator (Linux, Active Directory) <=
- 2025-03-10 roaming
- 2025-03-10 wodor
- 2025-03-10 Ostrów Wielkopolski => NodeJS Developer <=
- 2025-03-10 Białystok => System Architect (background deweloperski w Java) <=
- 2025-03-10 Częstochowa => Backend Developer (Node + Java) <=
- 2025-03-10 Poznań => Konsultant wdrożeniowy Comarch XL (Logistyka, WMS, Produkc
- 2025-03-10 Bydgoszcz => Specjalista ds. Sprzedaży (transport drogowy) <=
- 2025-03-10 China-Kraków => Senior PHP Symfony Developer <=
- 2025-03-10 Chiny-Kraków => Senior PHP Symfony Developer <=
- 2025-03-10 Szczecin => Key Account Manager IT <=
- 2025-03-10 Warszawa => Node.js / Fullstack Developer <=
- 2025-03-10 Warszawa => Data Engineer (Tech Leader) <=
- 2025-03-10 Gliwice => Business Development Manager - Network and Network Security