W dniu 2013-04-07 14:43, Krzysztof Halasa pisze:
> No pewnie że tak. Dokładnie tak jak napisałem. To dlaczego w Twoim
> obrazku, którego używasz jako dowodu na brak odpowiedniego pogorszenia
> jakości (realnego obrazka, nie testowych faktur), tak _NIE_ _JEST_?

Bo ulegasz złudzeniu jak wszyscy - na tym polega fenomen kodowania
obrazów z zaniżaniem rozdzielczości chrominancji. A dwukrotny spadek
rozdzielczości chromy zachodzi właśnie tak, jak napisałem; poprzednie
przykłady przeszły tę samą procedurę, co przykłady z szachownicami.
Problem w tym tylko, że nie potrafisz syntetycznie przeanalizować
przykładów, które dostarczyłem i upierasz się, że widzisz coś, co jest
złudzeniem, a nie rzeczywistością.

Reszta to bełkot gościa, który uwierzył w brzozę smoleńską, a zapadka w
głowie uniemożliwia mu wycofanie się z twarzą.
Ogłaszam koniec dyskusji.

A tak na marginesie - kawały z ''kamerunem'' w roli głównej nie wzięły
się znikąd...

--
pozdrawia Adam
różne takie tam: http://as.elte-s.com www.facebook.com/smialekadam
/zamiast telewizora oglądam pralkę - program ten sam, a jeszcze pierze/

do góry

Janko Muzykant <j...@w...pl> writes:

> Bo ulegasz złudzeniu jak wszyscy - na tym polega fenomen kodowania
> obrazów z zaniżaniem rozdzielczości chrominancji.

Nie żartuj, nie ma żadnego złudzenia ani w obrazku z grami, ani
w przykładach sztucznych. Nie ulegam złudzeniu ani ja, ani np. ffmpeg
(http://en.wikipedia.org/wiki/FFmpeg), którego użyłem do potwierdzenia
testu.
--
Krzysztof Halasa

do góry

W dniu 2013-04-07 16:03, Krzysztof Halasa pisze:
> Nie żartuj, nie ma żadnego złudzenia ani w obrazku z grami, ani
> w przykładach sztucznych.

Skoro na szachownicach wyszło, na pozostałych przykładach nie, a
procedura identyczna, to myli się albo komputer, albo obserwator.
Po prostu zrób sobie testy, narzędzia są darmowe i wróć tu z wnioskami.

--
pozdrawia Adam
różne takie tam: http://as.elte-s.com www.facebook.com/smialekadam
/uśmiechnij się - jutro też będą wojny, powodzie i trzęsienia ziemi.../

do góry

Janko Muzykant <j...@w...pl> writes:

>> Nie żartuj, nie ma żadnego złudzenia ani w obrazku z grami, ani
>> w przykładach sztucznych.
>
> Skoro na szachownicach wyszło, na pozostałych przykładach nie, a
> procedura identyczna, to myli się albo komputer, albo obserwator.
> Po prostu zrób sobie testy, narzędzia są darmowe i wróć tu z wnioskami.

No przecież zrobiłem. Szczerze mówiąc najpierw na tym zielonym, tam było
mało koloru, i różnice nie były takie duże (ale powyżej błędu
zaokrągleń). Wadliwość kolorowego zdjęcia jest jednak oczywista.

Ponieważ mały obrazek dostajesz poprawny (akurat tego nie sprawdzałem
ffmpegiem, ale wygląda dobrze), to przypuszczam że po prostu nie
wiedziałeś, że konwersja RGB->YUV420 zmniejsza rozdzielczość
chrominancji, i zrobiłeś ją w dużej rozdzielczości (aparatu),
a następnie, jak na wannabe fotografa przystało, zmniejszyłeś
rozdzielczość całego obrazka i umieściłeś w sieci (pokazanie szczegółów
technicznych wymaga, zamiast zmniejszania, cropa). Niestety zmniejszone
zdjęcie traci właściwości YUV420, to tak jakbyś zmniejszył rozdzielczość
i argumentował, że Bayer jest zupełnie niewykrywalny.

Zaprzeczysz?

Być może porównywałeś obrazki RGB i YUV w dużej rozdzielczości,
a plik z różnicami tak samo zmniejszyłeś (nie sprawdzałem czy plik
z różnicami się zgadza, bo wejściowy obrazek był już wadliwy).

Gdyby ta konwersja tylko zmieniała samą przestrzeń kolorów (tak jak
RGB888->YUV444), to to byłaby sensowna procedura. Ale zmienia się także
rozdzielczość barwna i dlatego te działania były bez sensu.

Zauważ, że film ma "od razu" rozdzielczość np. 1920x1080. To nie jest
tak, że dostajesz materiał YUV 7000x5000 i następnie go sobie
konwertujesz do RGB i zmniejszasz. Tu na początku masz rozdzielczość
Y 1920x1080, a rozdzielczość koloru - 960x540. Twój obrazek (rzekomy
YV12) ma jednak cały czas pełną rozdzielczość koloru 1920x1080.

Oczywiście to tylko spekulacja, wynikająca z tego, że Twoje
doświadczenie nie daje się powtórzyć, i że nie chcesz zdradzić
szczegółów procedury.

Narzędzia są rzeczywiście darmowe, np. można zrobić:

ffmpeg -i rgb.png -s 1920x1200 -pix_fmt yuv420p img.yuv
ffmpeg -pix_fmt yuv420p -s 1920x1200 -i img.yuv rgb-yuv420.png

Zauważ że tu nie ma żadnej stratnej kompresji innej niż wynikająca
z samej konwersji do YUV420.

Różnice między rgb-yuv420.png i tym:

http://as.elte-s.com/temp/video/yv12_420.png

widoczne są gołym okiem, nie trzeba używać narzędzia.


Swoją drogą, myślę że osobom czytającym tę grupę należałoby się jednak
- w wersji minimum - jakieś wyjaśnienie gdzie dokładnie popełniłeś błąd,
żeby same go nie powtarzały. Ale może to za duże wymagania.
--
Krzysztof Halasa

do góry

W dniu 2013-04-07 17:32, Krzysztof Halasa pisze:
> Ponieważ mały obrazek dostajesz poprawny (akurat tego nie sprawdzałem
> ffmpegiem, ale wygląda dobrze), to przypuszczam że po prostu nie
> wiedziałeś, że konwersja RGB->YUV420 zmniejsza rozdzielczość

Jezuuuuu... Ja tego uczę, za pieniądze, od nastu lat, ludzi którzy
tworzą prezentacje batoników po hipermarketach, właśnie po to, żeby im
nie zżerało kolorów, nie pojawiały się ''grzebienie'' od przeplotu, nie
skakała im konwersja 30>25 i nie robili podobnych kardynalnych błędów.

> chrominancji, i zrobiłeś ją w dużej rozdzielczości (aparatu),
> a następnie, jak na wannabe fotografa przystało, zmniejszyłeś
> rozdzielczość całego obrazka i umieściłeś w sieci (pokazanie szczegółów
> technicznych wymaga, zamiast zmniejszania, cropa). Niestety zmniejszone
> zdjęcie traci właściwości YUV420, to tak jakbyś zmniejszył rozdzielczość
> i argumentował, że Bayer jest zupełnie niewykrywalny.
>
> Zaprzeczysz?

Oczywiście! Jak można przeprowadzać w ten sposób doświadczenie? Po
wybraniu obiektu w rgb o jakiejkolwiek zmianie rozdzielczości nie ma mowy!
A może po prostu przeglądarka Ci skaluje obrazek? Albo nie pracujesz w
natywnej rozdzielczości lcd? A może w ogóle używasz nadal monitora
kineskopowego? :) Zaczynam podejrzewać, że takie mogą być przyczyny
Twoich śmiesznych wniosków.

> Oczywiście to tylko spekulacja, wynikająca z tego, że Twoje
> doświadczenie nie daje się powtórzyć, i że nie chcesz zdradzić
> szczegółów procedury.

Jest opisane trzykrotnie wyżej:
1) wybieram obrazek w przestrzeni RGB, w internecie masz takich bilion,
2) zapisuję kopię w png,
3) przeprowadzam konwersję virtualdubem do przestrzeni YV12 (4:2:0),
(virtualdub jest tym dla zawodowych filmowców, co totalcommander dla
ludzi zawodowo używających komputerów),
4) zrzucam klatkę z przekonwertowanej tak przestrzeni do png w
przestrzeni RGB,
5) mam oryginał i kopię do porównań.

Możesz to samo zrobić ffmpegem i setką innych programów. Zawsze wynik
będzie ten sam.

> Swoją drogą, myślę że osobom czytającym tę grupę należałoby się jednak
> - w wersji minimum - jakieś wyjaśnienie gdzie dokładnie popełniłeś błąd,
> żeby same go nie powtarzały. Ale może to za duże wymagania.

No to gdzie ten błąd? :)

--
pozdrawia Adam
różne takie tam: http://as.elte-s.com www.facebook.com/smialekadam
/dojrzałość następuje z chwilą, gdy kończy się chemia, a zaczyna fizyka/

do góry

Janko Muzykant <j...@w...pl> writes:

G 1) wybieram obrazek w przestrzeni RGB, w internecie masz takich bilion,
> 2) zapisuję kopię w png,
> 3) przeprowadzam konwersję virtualdubem do przestrzeni YV12 (4:2:0),
> (virtualdub jest tym dla zawodowych filmowców, co totalcommander dla
> ludzi zawodowo używających komputerów),

Nie jestem pewien czym jest ten "totalcommander", więc porównanie do
mnie średnio trafia. Pewnie nie używam zawodowo komputerów :-)

> 4) zrzucam klatkę z przekonwertowanej tak przestrzeni do png w
> przestrzeni RGB,
> 5) mam oryginał i kopię do porównań.

To proponuję jeszcze punkt 3a, zrzuć klatkę w YV12 i pokaż, i dopiero
z niej zrób konwersję do RGB (jeśli potrzebujesz, mi wystarczy YV12).

> Możesz to samo zrobić ffmpegem i setką innych programów. Zawsze wynik
> będzie ten sam.

Przecież każdy może sprawdzić że właśnie tak nie będzie - ffmpeg da
prawidłowe wyniki. Zresztą łatwo zweryfikować, można np. wyświetlić
plik YUV.
--
Krzysztof Halasa

do góry

W dniu 2013-04-07 21:47, Krzysztof Halasa pisze:
> Nie jestem pewien czym jest ten "totalcommander", więc porównanie do
> mnie średnio trafia. Pewnie nie używam zawodowo komputerów :-)

Zacznijmy od tego, że jeśli nie wiesz, co to jest virtualdub, to się nie
wypowiadaj w tym wątku z punktu widzenia autorytetu. Jest to mniej
więcej ms word dla przeciętnej sekretarki.
Ale niech będzie...

>> 4) zrzucam klatkę z przekonwertowanej tak przestrzeni do png w
>> przestrzeni RGB,
>> 5) mam oryginał i kopię do porównań.
>
> To proponuję jeszcze punkt 3a, zrzuć klatkę w YV12 i pokaż, i dopiero
> z niej zrób konwersję do RGB (jeśli potrzebujesz, mi wystarczy YV12).

A nie możesz sobie zrobić sam? Ale dobrze, skoro chcesz koniecznie
zrobić z siebie upartą mendę...
http://as.elte-s.com/temp/video/pack.zip

To jest para filmów składający się z jednej klatki, nieskompresowane,
żeby wykluczyć zniekształcenia pochodzące z innych czynników; nie mam
gigabajtów na udowadnianie rzeczy oczywistych. W nagłówku masz opisane
przestrzenie. Tylko, błagam, nie pytaj jak go odczytać i czy go nie
sfałszowałem albo że Ci film się nie wyświetla, albo że za krótko :)

> Przecież każdy może sprawdzić że właśnie tak nie będzie - ffmpeg da
> prawidłowe wyniki. Zresztą łatwo zweryfikować, można np. wyświetlić
> plik YUV.

Może byś zatem dostarczył choć jednego jedynego przykładu?

--
pozdrawia Adam
różne takie tam: http://as.elte-s.com www.facebook.com/smialekadam
/przyszła drożyzna i nie wiem, czy kupywać Fakt, czy Super Express/

do góry

Świetny przykład potwierdzający to, o czym mówiłem; porównanie topowej
lustrzanki pracującej w trybie filmowym z obrazem kamery pracującej na
pełnych parametrach matrycy:
http://vimeo.com/49875510#
Tylko niech nikt nie myśli, że jedynym problemem jest węższa
rozdzielczość chrominancji, poniżej udowodniłem, że ma to znaczenie
symboliczne.

--
pozdrawia Adam
różne takie tam: http://as.elte-s.com www.facebook.com/smialekadam
/gdy już grzeszysz, to przynajmniej się z tego ciesz/

do góry

W dniu 2013-04-09 23:37, Janko Muzykant pisze:
> Świetny przykład potwierdzający to, o czym mówiłem; porównanie topowej
> lustrzanki pracującej w trybie filmowym z obrazem kamery pracującej na
> pełnych parametrach matrycy:
> http://vimeo.com/49875510#
> Tylko niech nikt nie myśli, że jedynym problemem jest węższa
> rozdzielczość chrominancji, poniżej udowodniłem, że ma to znaczenie
> symboliczne.

Dokładnie, a to "gówienko" w cenie poniżej 1 tys. $:
http://www.blackmagicdesign.com/products/blackmagicp
ocketcinemacamera/
pewnie położy na łopatki wszystkie filmujące aparaty.


--
marcin

do góry

Janko Muzykant napisał:
> Świetny przykład potwierdzający to, o czym mówiłem; porównanie topowej
> lustrzanki pracującej w trybie filmowym z obrazem kamery pracującej na
> pełnych parametrach matrycy:
> http://vimeo.com/49875510#
> Tylko niech nikt nie myśli, że jedynym problemem jest węższa
> rozdzielczość chrominancji, poniżej udowodniłem, że ma to znaczenie
> symboliczne.

Problemem nie jest 'rozdzielczość chrominancji', ale kompresja.
W lustrzankach producenci forsują kompresję z różnych powodów (problemy
z zapisem, kanibalizowanie innego segmentu rynku), w BMCC z przykładu
masz zapis RAW z matrycy. Porównując do zdjęć masz podobną sytuację RAW
vs JPG.

Co można wyciągnąć z aparatu używanego w roli kamery ładnie pokazali
ludzie hackujący Panasoniki z serii GH. Znosząc kolejne ograniczenia
dotyczące kompresji bardzo wyraźnie podnosili jakość obrazu video.

W tym filmiku masz porównanie między innymi BMCC i shackowanego GH2:

http://vimeo.com/56465475

Biorąc to pod uwagę na 99% jestem pewien, że Canon szykując grunt pod
C100 (i następców) umyślnie spaskudził ustawienia jakości filmowania na
5DIII - i mogą się na tym nieźle przejechać.

m.

do góry