Zobacz pełną wersję : NEF 12 czy 14-bitowy.
Jak w tytule, teorii w sieci multum, a jak jest naprawdę ?
Pzdrawiam
http://www.earthboundlight.com/phototips/nikon-d300-d3-14-bit-versus-12-bit.html
A link był też tu: http://forum.nikon.org.pl/showpost.php?p=1077683&postcount=33
Naprawdę jest tak, że jeśli fotki dobrze naświetlasz i mało obrabiasz w programie graficznym, to różnicy praktycznej nie zauważysz.
siedemczwartych
27-02-2009, 17:19
niestety jestem ignorantem językowym... przynajmniej na takim poziomie. :)
Moze jest po naszemu gdzies? A moze znajdzie sie ochotnik i przetłumaczy?
BlackRoger
27-02-2009, 19:39
http://74.125.39.132/translate_c?hl=pl&sl=en&tl=pl&u=http://www.earthboundlight.com/phototips/nikon-d300-d3-14-bit-versus-12-bit.html&prev=_t&usg=ALkJrhgoJ7w-uTPSH7czjra7imNhBEDnxw
Roznica w liczbach jest kolosalna:
12-bitowy RAW to 4 096 poziomów jasności;
14-bitowy RAW to 16 384 poziomy jasności...
a zwykly 8 bitowy JPG to tylko 256 poziomow (oko nie rozroznia nawet polowy tej wartosci).
Ale przy takim eksperymencie wiecej bitow pewnie dobrze robi:)
http://www.youtube.com/watch?v=2-z-9te6y4k&feature=related
Kali zrozumiec prawie cala prafda, hi
Dzieki
Roznica w liczbach jest kolosalna:
12-bitowy RAW to 4 096 poziomów jasności;
14-bitowy RAW to 16 384 poziomy jasności...
Gwoli ścisłości, chodzi o poziomy każdej z 3 barw RGB, czyli każda barwa składowa jest opisana na 12 lub 14 bitach, czyli
- przy 12 bitowym kolorze 4096^3 = 67 369 460 509,
- przy 14 bitowym kolorze 16384^3 = 4 398 046 511 104
łącznie wszystkich kolorów.
a zwykly 8 bitowy JPG to tylko 256 poziomow (oko nie rozroznia nawet polowy tej wartosci).
Ale przy takim eksperymencie wiecej bitow pewnie dobrze robi:)
Różnice widać na silnie kontrastowych zdjęciach, im więcej bitów, tym więcej szczegółow w światłach i cieniach.
Tyle, że katowanie się rozmiarami 14 bitowych RAWów ma sens tylko i wyłącznie tam, gdzie ma sens. I nigdzie poza tym. Ich obróbka... cóż. Wymaga sporej mocy komputera. I dużo miejsca na dysku ;)
A jak to jest z ob obróbką takich plików w innych programach niż NX? Ma to znaczenie, poza oczywistymi różnicami?
Tyle, że katowanie się rozmiarami 14 bitowych RAWów ma sens tylko i wyłącznie tam, gdzie ma sens. I nigdzie poza tym. Ich obróbka... cóż. Wymaga sporej mocy komputera. I dużo miejsca na dysku ;)
No bez przesady, roznice miedzy obrobka 12bit a 14bit nie sa jakies gigantyczne (w kontekscie szybkosci/miejsca na dysku).
Ja robię 14 bitowe, wolę mieć więcej na zdjęciu. łatwiej odjąć niż dodać na zdjęciu później ;)
siedemczwartych
04-03-2009, 14:37
po co kupować D300 i robić np w "basic jpg" ??????????
Skoro mam 14-bit to z nich korzystam bez wątpliwości.
Poza tym większe pliki zmuszają do rozważnego dobierania kadrów, a nie "walenie" seriami tylko dlatego, że na karcie się mieści 10000 fotek.
Troche to przypomina analogi... i dobrze bo sie szanuje kadr.
Tyle, że katowanie się rozmiarami 14 bitowych RAWów ma sens tylko i wyłącznie tam, gdzie ma sens. I nigdzie poza tym. Ich obróbka... cóż. Wymaga sporej mocy komputera. I dużo miejsca na dysku ;)
Nie widzę praktycznie żadnej różnicy w obróbce między 12 a 14bit - a jeśli są to tak szczątkowe, że procesor tego nawet "nie czuje" mz.
Różnice są na samym dole, w głębokich cieniach. Jeżeli np. używa się ISO100 i ciągnie cienie tak mocno, że widać już "spód" RAWa (to znaczy takie płaskie "placki" zamiast szczegółów), ale jeszcze nie widać dyskwalifikującego szumu, to znaczy że więcej bitów pozwoliłoby zapisać dodatkowe szczegóły. Jeżeli nie zauważacie w obróbce takich efektów, to 14 bitów raczej wiele wam nie da, chyba że dodatkowy bit poświęcany jest na zapis dodatkowych świateł, w co osobiście nie wierzę, bo tu nie ma co oszczędzać przy 12 bitach.
ja u siebie właśnie placki zauwazylem, np. na niebie, od teraz 14 bit...
Kraftsman
04-03-2009, 18:18
Oszczędzanie na przestrzeni dyskowej nie ma większego sensu w sytuacji gdy za parę stówek można kupić terabajtowy dysk. Dlatego używam tylko 14-bit, chcę mieć zapisane maksimum informacji nawet jeśli w większości przypadków nie będę dostrzegał różnicy. IMO warto, nawet jeśli ma się to przydać raz na jakiś czas, kiedy decyduję się na bardziej forsowną obróbkę.
Tak już żeby nie zakładać drugiego wątku to tu podepnę, kupiłem niedawno 16gb SanDiska i ustawiłem sobie tym razem nef'a 14bitowego ale niekompresowanego - co ciekawe na 14bitowym ale skompresowanym bezstratnie - karta pokazuje mi taką samą ilość zdjęć do zrobienia czyli 606 - ciekawa sprawa.
Btw - dobrze, że nie 666 :twisted:
Oszczędzanie na przestrzeni dyskowej nie ma większego sensu w sytuacji gdy za parę stówek można kupić terabajtowy dysk. Dlatego używam tylko 14-bit, chcę mieć zapisane maksimum informacji nawet jeśli w większości przypadków nie będę dostrzegał różnicy. IMO warto, nawet jeśli ma się to przydać raz na jakiś czas, kiedy decyduję się na bardziej forsowną obróbkę.
Popieram w całej rozciągłości.
Btw - dobrze, że nie 666 :twisted:
a tego to nie rozumiemm, zawsze to 60 więcej :)
Nie bardzo rozumiem co ma 14 bitów do przestrzeni dyskowej, przecież to tylko 1/6 wielkości pliku.
siedemczwartych
05-03-2009, 09:09
aparat pokazuje liczbę OKOŁO, ponieważ nie wie jakie będą zdjecia.
Po zapwłnieniu karty moze sie okazać, że masz nie 606 a 580, albo 620 bo fotki są lżejsze lub cięższe niż średnio aparat przewidywał.
Więc bym szczególnie się do ilości nie przywiązywał.
O tym doskonale wiem, ale myślałem, że licząc początkową ilość wg jakiegoś tam "wzoru" powinien brać pod uwagę kompresję takiego nef-a...
siedemczwartych
05-03-2009, 09:53
a czy różnica w wielkości między skompresowanym a nieskompresowanym jest na tyle duża, że różnica w ilości jest większa - niż różnica w ilości wynikająca z wielkości plików zależnej od kadru? Pewnie NIE i dlatego średnia skompresowanych i nieskompresowanych jest tą samą liczbą. Tak domniemam :)
Ma ktoś doświadczenie, czy nieskompresowane NEF-y 14 bitowe wywołują i obrabiają się wyraźnie szybciej od skompresowanych bezstratnie, czy może różnica jest pomijalna?
Wigi - leniu - zrób sam i sprawdź a potem nam napisz :mrgreen:
Wigi - leniu - zrób sam i sprawdź a potem nam napisz :mrgreen:
Dokładnie :D
Czekam na wyniki ;)
Jak w tytule, teorii w sieci multum, a jak jest naprawdę ?
Pzdrawiam
Sprawa jest mz. szalenie prosta - w przypadku fotografowania scen o b. dużej rozpiętości tonalnej wybrałbym 14 bit. Robię zdjęcia ciemnej klity z oknami wychodzącymi na południowe słońce, murzyna zdobywającego nago biegun północny, zgniłe domki spowite proszę pana wieczorną tą tak zwaną ach poświatą - walę 14 bit.
W pozostałych przypadkach - naga dziewoja w studiu na szarym tle czy spowite mgłą blokowisko i w ogóle wszystko, gdzie rozpiętość tonalna to 2EV z hakiem - szkoda sobie zawracać głowę.
a czy różnica w wielkości między skompresowanym a nieskompresowanym jest na tyle duża, że różnica w ilości jest większa - niż różnica w ilości wynikająca z wielkości plików zależnej od kadru? Pewnie NIE i dlatego średnia skompresowanych i nieskompresowanych jest tą samą liczbą. Tak domniemam :)
Zasadniczo pobieżnie to co Ty chciałeś powiedzieć?? Że średnia wielkość NEFa 12 i 14 bitowego jest taka sama?
Ma ktoś doświadczenie, czy nieskompresowane NEF-y 14 bitowe wywołują i obrabiają się wyraźnie szybciej od skompresowanych bezstratnie, czy może różnica jest pomijalna?
Doświadczenie jest takie, że szybciej wywołują się NEFy skompresowane. Dlaczego? Bo średnia wielkość 14bitowego jest skompresowanego pliku jest o ponad 40% mniejsza od średniej wielkości nieskompresowanego. To znaczy, że komputer dużo szybciej jest w stanie odczytać taki plik z dysku, a właśnie operacje dyskowe mają tu kluczowe znaczenie.
To znaczy, że komputer dużo szybciej jest w stanie odczytać taki plik z dysku, a właśnie operacje dyskowe mają tu kluczowe znaczenie.Przy dzisiejszych predkosciach dyskow smiem watpic, czy odczytanie ~2 MB wiecej z dysku, zajmie wiecej czasu niz dekompresja spakowanego. Ale zeby to faktycznie dobrze zmierzyc, trzeba by przepusic batchem ze 100 skompresowanych i 100 nieskompresowanych. ;)
siedemczwartych
05-03-2009, 12:16
RAW SKOMPRESOWANY BEZSTRATNIE - z użyciem odwracalnego algorytmu. Bez jakiegokolwiek wpływu na jakosc obrazu.
Pytanie: gdzie i czym jets odwracany ten algorytm? Trzeba mieć NX? Czy jak wywołuje raw innym programem to też to sie dzieje?
Czy jak wywołuje raw innym programem to też to sie dzieje?
Też się tak dzieje. Są algorytmy stratne (np. JPG) i bezstratne (np. zip) :D
siedemczwartych
05-03-2009, 12:22
to wiem, ale ZIP jest rozpakowywany preznaczonym do tego programem.
A co odwraca algorytm kompresji raw?
Ten algorytm jest powiedzmy "nikonowski", więc moze do prawidłowego odwrócenie potrzeba "nikonowskiego" programu?
to wiem, ale ZIP jest rozpakowywany preznaczonym do tego programem.
A co odwraca algorytm kompresji raw?
Ten algorytm jest powiedzmy "nikonowski", więc moze do prawidłowego odwrócenie potrzeba "nikonowskiego" programu?
To tak naprawdę to pewnie żaden nikonowski algorytm, a jakiś standardowy bzip/zip/lzw czy coś w tym stylu. ZIP jest rozpakowywany dowolnym programem, który za zaimplementowany kod do dekompresji algorytmem ZIP.
Co do tych stratnych/bezstratnych - Ken Rockwell pisze w swojej "instrukcji D700", że używa zawsze skompresowanych stratnie RAW i w większości przypadków nie zauważa różnicy pomiędzy tymi nieskompresowanymi a skompresowanymi stratnym algorytmem. Więc pewnie coś w tym jest.
Zależy, czy ktoś bardziej ceni miejsce na dysku, czy potencjalną stratę istotnych informacji w RAW.
Ja wybieram tą pierwszą opcję - już 3 dyski 250GB leżą opisane jako "zdjęcia (i tu milion tagów)" + 500gb raida 1 a miejsce się kończy.
Chociaż wiadomo - dyski teraz są tanie...
Co do tych stratnych/bezstratnych - Ken Rockwell pisze w swojej "instrukcji D700", że używa zawsze skompresowanych stratnie RAW i w większości przypadków nie zauważa różnicy pomiędzy tymi nieskompresowanymi a skompresowanymi stratnym algorytmem. Więc pewnie coś w tym jest.
No pewnie to tak samo jak oglądasz na ekranie w powiększeniu 40% TIFFa i JPGa :D
Różnicy nie zauważysz. ;)
No pewnie to tak samo jak oglądasz na ekranie w powiększeniu 40% TIFFa i JPGa :D
Różnicy nie zauważysz. ;)
Ja tam nie wiem. Piszę tylko co wyczytałem w jego spreparowanej instrukcji do D700...
To pewnie jest nawet mierzalne. Może warto było by się pokusić o sprawdzenie, które rzeczywiście informacje z pliku RAW są wycinane przez stratne algorytmy kompresji?
Np. jak wiadomo w jpg przy kompresji na poziomie 90% giną informacje i tak generalnie nieistotne z punktu widzenia ludzkiego oka i nie warto kompresować jpg na poziomie 100%, bo wiele się na tym nie zyska _sensownej_ informacji.
Chociaż to pewnie rozpętanie wojny takie stwierdzanie. Ale cóż - ja już takie mam praktyczne podejście do sprawy :)
Dla mnie praktycznie jest stosować mniejsze rozmiary plików tylko po to, by szybciej się je obrabiało i zajmowały mniej miejsca - nawet, jeśli tracę przez to jakieś ułamkowe części i tak często pomijalnych danych :)
Edit:
A tak mi się jeszcze przypomniało: "Ignorancja jest cnotą"
Dla mnie praktycznie jest stosować mniejsze rozmiary plików tylko po to, by szybciej się je obrabiało[...]Czyli wg Ciebie 5 MB JPGa obrabia sie szybciej (z mniejszym obciazeniem dla procesora), niz 25 MB TIFFa (jesli rzecz jasna maja te sama ilosc pikseli)?
No nie. W tym porównaniu akurat nie, ze względu na to, że do obróbki jpg jest rozpakowywany do bitmapy prawdopodobnie. Ale już 5MB jpga a 1MB jpga to jest różnica.
Zresztą o tym już kiedyś rozmawialiśmy. JPG wyłącznie do prezentacji w sieci - koniec kropka. A tu rozmiar ma znaczenie, obiektywnie.
Mnie się rozchodzi o to, że do ustawień typu 12 czy 14 bit, kompresowany czy niekompresowany RAW itp. warto podchodzić zdroworozsądkowo, jednak. Różnice w wielkości plików są spore (zauważalne w każdym razie), a czasami (pewnie nawet w większości przypadków) można sobie to darować idąc na swego rodzaju "kompromisy".
Ale EOT z mojej strony, nie jestem specjalistą w tej dziedzinie i ewentualnie chętnie poczytam co mają do powiedzenia mądrzejsi. Może zmienię pod wpływem tych informacji poglądy i zacznę strzelać wyłącznie w 14 bitowych niczym nieskompresowanych RAW'ach.
Jak dobrze, że nie mam D3X ;-)
Np. jak wiadomo w jpg przy kompresji na poziomie 90% giną informacje i tak generalnie nieistotne z punktu widzenia ludzkiego oka i nie warto kompresować jpg na poziomie 100%, bo wiele się na tym nie zyska _sensownej_ informacji.
Jeśli mówisz o pliku wynikowym to się zgodzę. Ale jeśli mówimy o pliku, który chcemy dopiero obrabiać i przerabiać... W takim razie dlaczego nie obrabiasz gotowych JPG tylko RAWy?...
Dla mnie praktycznie jest stosować mniejsze rozmiary plików tylko po to, by szybciej się je obrabiało i zajmowały mniej miejsca - nawet, jeśli tracę przez to jakieś ułamkowe części i tak często pomijalnych danych :)
Już Ci Stig zadał pytanie. :D
No nie. W tym porównaniu akurat nie, ze względu na to, że do obróbki jpg jest rozpakowywany do bitmapy prawdopodobnie. Ale już 5MB jpga a 1MB jpga to jest różnica.Jesli ma nadal te sama ilosc pikseli, to nie ma roznicy. Tak czy siak -- jest zdekompresowany do mapy bitowej i to te mape -- skladajaca sie z tej samej ilosci pikseli -- obrabiasz. Nie ma znaczenia, czy wczesniej to byl JPG 1 MB, 5 MB, 15 MB, czy TIFF 25 MB.
Jeśli mówisz o pliku wynikowym to się zgodzę. Ale jeśli mówimy o pliku, który chcemy dopiero obrabiać i przerabiać... W takim razie dlaczego nie obrabiasz gotowych JPG tylko RAWy?...
Przykład kompresji jpg podałem po to, żeby uargumentować, że są sytuacje, w których kompresja nawet stratna nie powoduje drastycznego spadku jakości.
Nie porównywałem jpg do raw. To oczywiście nie ma sensu.
Zastanawiamy się w tym wątku co to jest w ogóle ta kompresja RAW - stratna i bezstratna. Nie wiem, czy warto ją stosować, czy nie - wyczytałem u Ken'a, że wg niego warto, nawet tą stratną bez zauważalnego spadku jakości RAW'a.
W przypadku JPG, który - jak już napisałem - służy mi do prezentacji w sieci - kompresja na poziomie nawet 90% nie spędza mi snu z powiek. Może tak samo jest w przypadku kompresji RAW, o której mowa?
Mnie się rozchodzi o to, że do ustawień typu 12 czy 14 bit, kompresowany czy niekompresowany RAW itp. warto podchodzić zdroworozsądkowo, jednak. Różnice w wielkości plików są spore (zauważalne w każdym razie), a czasami (pewnie nawet w większości przypadków) można sobie to darować idąc na swego rodzaju "kompromisy"
Ale rownie dobrze kompromisem moze byc cos takiego, ze focisz w 14bit raw skonwertowanych bezstratnie (na wszelki wypadek), nastepnie robisz selekcje, wolasz/obrabiasz pliki, i gotowce - te ktore chcesz zostawic, zapisuje sobie do jakiegos sesnownej wielkosci/jakosci JPGa celem archiwizacji, a z NEFem sie zegnasz wywalajac go do kosza.
Wilk syty i owca cala :)
Ale rownie dobrze kompromisem moze byc cos takiego, ze focisz w 14bit raw skonwertowanych bezstratnie (na wszelki wypadek), nastepnie robisz selekcje, wolasz/obrabiasz pliki, i gotowce - te ktore chcesz zostawic, zapisuje sobie do jakiegos sesnownej wielkosci/jakosci JPGa celem archiwizacji, a z NEFem sie zegnasz wywalajac go do kosza.
Wilk syty i owca cala :)
E. To już była by profanacja i przesada :)
Po to robię RAW, żeby go przechowywać i w razie czego uzyskać - wyrzuconego wcześniej do kosza - gotowca w postaci czegokolwiek :)
no bez przesady, raw to nie religia... ja np. praktycznie zawsze tak robie w przypadku zdjec prywatno-wakacyjno-albumowych
A mi jest jednak zawsze szkoda wyrzucić.
Bo a nuż się do tego wróci z jakichś przyczyn? A nuż nauczę się czegoś nowego i będę chciał te raw'y lepiej wywołać? A nuż "cioci na imieninach" spodoba się uśmiechnięta wnusia wuja Stacha, którą trzeba będzie powiększyć na pół ściany?
No i dlatego szukam możliwości kompromisów - żeby rawy przechowywać, ale jednak zmniejszać ich objętość na tyle, na ile to możliwe/sensowne...
Przy dzisiejszych predkosciach dyskow smiem watpic, czy odczytanie ~2 MB wiecej z dysku, zajmie wiecej czasu niz dekompresja spakowanego. Ale zeby to faktycznie dobrze zmierzyc, trzeba by przepusic batchem ze 100 skompresowanych i 100 nieskompresowanych. ;)
1. Tak się składa, że niezależnie od tego czy dysk szybki czy wolny odczytanie dłuższego pliku zajmie więcej czasu, zawsze. I jest to wartość jak najbardziej mierzalna, a zależność miedzy czasem odczytu a wielkością pliku jest liniowa.
2. Mierzyłeś kiedyś średnią z plików 12 i 14 bitowych, skompresowanych lub nie? Ja sobie zmierzyłem, i wyszło mi co następuje (dla 14bitów): średnia dla niekompresowanych 23MB, średnia dla skompresowanych 12MB. Trochę więcej niż 2 MB, prawda?
1. Tak się składa, że niezależnie od tego czy dysk szybki czy wolny odczytanie dłuższego pliku zajmie więcej czasu, zawsze. I jest to wartość jak najbardziej mierzalna, a zależność miedzy czasem odczytu a wielkością pliku jest liniowa.Chodzilo o roznice miedzy otwarciem pliku z kompresja, a pliku bez kompresji. Tak sie sklada, ze plik z kompresja musi zostac zdekompresowany, co rowniez zajmuje iles tam czasu. Kwestia tego, czy czas odczytu tej roznicy w wielkosci pliku (z kompresja lub bez) nie jest tozsamy z czasem dekompresowania przez aplikacje w ktorej te pliki otwierasz. :)
2. Mierzyłeś kiedyś średnią z plików 12 i 14 bitowych, skompresowanych lub nie? Ja sobie zmierzyłem, i wyszło mi co następuje (dla 14bitów): średnia dla niekompresowanych 23MB, średnia dla skompresowanych 12MB. Trochę więcej niż 2 MB, prawda?Mea culpa. :) Piszac o 2 MB mialem na mysli roznice miedzy kompresja stratna, a bezstratna (trybu "bez kompresji" -- nigdy nie wlaczam, bo to marnotrawienie miejsca, i na nic nie ma wplywu). A zeby nie bylo "srednio", to zrobilem porownanie wielkosci plikow na tym samym motywie. :)
NEF 12 bit:
1. 19,2 -- bez kompresji
2. 11,2 -- z kompresja bezstratna
3. 9,9 -- z kompresja stratna.
1. Tak się składa, że niezależnie od tego czy dysk szybki czy wolny odczytanie dłuższego pliku zajmie więcej czasu, zawsze.
Tylko ile dłużej? 10ms? 20m? 2s? :D
jesli kogos to zainteresuja to Thom Hogan w swojej ksiazce mniej wiecej opisal na czym polega algorytm stratnej kompresji nefow
http://rapidshare.de/files/45850575/nef.pdf.html
tam są jakieś gołe panie...
[QUOTE=messer;1162632]tam są jakieś gołe panie...[/QUOTE
trzeba kliknac free i wpisac kod ktory pojawi sie do wpisania i wtedy plik bedzie do sciagniecia
urok tego typu hostingow plikow
te panie będą wtedy do ściągnięcia? :)
te panie będą wtedy do ściągnięcia? :)
heheh, nie - plik pdf z tym co pisalem
Chodzilo o roznice miedzy otwarciem pliku z kompresja, a pliku bez kompresji. Tak sie sklada, ze plik z kompresja musi zostac zdekompresowany, co rowniez zajmuje iles tam czasu. Kwestia tego, czy czas odczytu tej roznicy w wielkosci pliku (z kompresja lub bez) nie jest tozsamy z czasem dekompresowania przez aplikacje w ktorej te pliki otwierasz. :)
Widzisz, w Twoim zdaniu zawarta jest moja odpowiedź, OTWARCIE - im większy plik tym dłużej się otwiera. Jeśli chodzi o dekompresję to:
a) Dekompresja zajmuje mniej czasu niż kompresja.
b) Na otwarcie (przygotowanie do obróbki) KAŻDEGO pliku, nawet tego bez kompresji, potrzebny jest czas. Tzn. program musi przygotować sobie plik tymczasowy, który potem będzie poddany dalszej obróbce. Wielkość tego pliku nie zależy od stopnia kompresji czy jej braku. Nawet plik bez kompresji też trzeba będzie tak przygotować, czyli CPU będzie musiał poświęcić na to jakiś czas. Zdecydowanie nie doceniasz możliwości współczesnych procesorów, od czasu Pentium II kiedy to zintegrowany z procesorem koprocesor ma możliwość jednoczesnej pracy z jednostką MMX, takie operacje są obliczane naprawdę szybko.
Mea culpa. :) Piszac o 2 MB mialem na mysli roznice miedzy kompresja stratna, a bezstratna (trybu "bez kompresji" -- nigdy nie wlaczam, bo to marnotrawienie miejsca, i na nic nie ma wplywu). A zeby nie bylo "srednio", to zrobilem porownanie wielkosci plikow na tym samym motywie. :)
NEF 12 bit:
1. 19,2 -- bez kompresji
2. 11,2 -- z kompresja bezstratna
3. 9,9 -- z kompresja stratna.
Ale ja odpowiadałem na posta kolegi, który pytał o NEFy 14 bitowe z kompresją lub bez. Jeśli chodzi o 12bitów i różnicę między kompresją stratną i bezstratną, to uzyskałem wyniki podobne do Twoich.
Tylko ile dłużej? 10ms? 20m? 2s? :D
Różnica między NEFem 14 bitowym bez kompresji a skompresowanych bezstratnie wynosi ponad 40%. W przypadku jednego pliku różnica będzie tak mała, że jej nie zauważysz, ale jeśli plików będzie więcej już tak.
Przykład kompresji jpg podałem po to, żeby uargumentować, że są sytuacje, w których kompresja nawet stratna nie powoduje drastycznego spadku jakości.
Nie porównywałem jpg do raw. To oczywiście nie ma sensu.
Zastanawiamy się w tym wątku co to jest w ogóle ta kompresja RAW - stratna i bezstratna. Nie wiem, czy warto ją stosować, czy nie - wyczytałem u Ken'a, że wg niego warto, nawet tą stratną bez zauważalnego spadku jakości RAW'a.
W przypadku JPG, który - jak już napisałem - służy mi do prezentacji w sieci - kompresja na poziomie nawet 90% nie spędza mi snu z powiek. Może tak samo jest w przypadku kompresji RAW, o której mowa?
Co do tego co pisze Ken, trzeba podchodzić ostrożnie.
Jeśli chodzi o kompresję stratną, to czytałem testy, z których wynika, że powoduje ona utratę detali w bardzo jasnych partiach zdjęcia. Moim zdaniem nie warto tego stosować, bo skoro wybrałeś NEF to zależy Ci na jak największej jakości. Jedyny przypadek kiedy stosuje skompresowanego 12b NEFa to wtedy, kiedy zależy mi na miejscu na karcie, wielkość tego pliku prawie się nie różni od JPG najwyższej jakości.
jesli kogos to zainteresuja to Thom Hogan w swojej ksiazce mniej wiecej opisal na czym polega algorytm stratnej kompresji nefow
http://rapidshare.de/files/45850575/nef.pdf.html
Dzięki! Potwierdza to wyniki testów, które można znaleźć na necie.
Widzisz, w Twoim zdaniu zawarta jest moja odpowiedź, OTWARCIE - im większy plik tym dłużej się otwiera.Mierzyles to, czy tylko teoretyzujesz? Bo mi caly czas chodzi o faktyczna roznice w czasie otwierania (czyli procesu od momentu odczytu z dysku, do pojawienia sie na ekranie).
Jeśli chodzi o dekompresję to:
a) Dekompresja zajmuje mniej czasu niż kompresja.jest to oczywiste, ale nic nie mowilem o procesie kompresji.
b) Na otwarcie (przygotowanie do obróbki) KAŻDEGO pliku, nawet tego bez kompresji, potrzebny jest czas. Tzn. program musi przygotować sobie plik tymczasowy, który potem będzie poddany dalszej obróbce. Wielkość tego pliku nie zależy od stopnia kompresji czy jej braku. Nawet plik bez kompresji też trzeba będzie tak przygotować, czyli CPU będzie musiał poświęcić na to jakiś czas. Zdecydowanie nie doceniasz możliwości współczesnych procesorów, od czasu Pentium II kiedy to zintegrowany z procesorem koprocesor ma możliwość jednoczesnej pracy z jednostką MMX, takie operacje są obliczane naprawdę szybko.Dobrze, niech to nawet bedzie mega-szybko. Ale czy jestes pewny, ze pliki z kompresja otwieraja sie szybciej niz te bez kompresji? Bo ja to sprawdzalem, i wbrew pozorom zauwazylem cos zupelnie odmiennego. Plik bez kompresji, mimo roznicy ponad 90% w wielkosci, w NC NX2 otwiera sie szybciej, co przeczy Twojemu wczesniejszemu stwierdzeniu. Tak wiec bardziej pasuje mi teza, ze w procesie otwierania pliku (czyli jak wspomniales -- przygotowania pliku tymczasowego) wiecej czasu procesor potrzebuje na dekompresje niz dysk na odczytanie roznicy w wielkosci pliku.
Testowane na C2D 2.8 GHz, dysk Caviar 250 GB 16 MB, 3 GB RAM 800 MHz, Nikon Capture NX2.
Panowie. Na "szybkość" obróbki składają się w praktyce trzy elementy.
Pierwszy, to szybkość odczytu danych z dysku (lub karty) i tu zależności są bardzo proste. Im mniejszy plik w MB (czy KB) tym szybciej zostanie on odczytany (mniej czasu potrzeba na transfer danych z dysku do pamieci). Druga zależnośc to taka, że im mniejsza złożoność algorytmu kompresji (lub brak kompresji), tym mniej do roboty ma procesor, czyli jest szansa na zwiększenie szybkości. To wszystko się oczywiście na siebie nakłada i wynikowo wychodzi, że wielkość pliku (długość transferu danych) ma zdecydowanie większy wpływ na czas odczytania danych, niż zastosowana kompresja. Dzieje się tak dlatego, że "szybkość" procesora i pamięci RAM jest o kilka rzędów wielkości większa niż "szybkość" transferu danych z dysku.
Drugi element to obróbka zdjęcia w pamięci komputera. Tu wielkość pliku w MB nie ma żadnego znaczenia, bo ważna jest jedynie wielkość zdjęcia w pikselach i głębia koloru. Odnośnie wielkości zdjęcia w pikselach, to chyba wszystko jest jasne. Jeśli coś ma 200x300=60000 pikseli to będzie się obrabiało znacznie szybciej (pewnie około 100 razy szybciej) niż coś co ma 2000x3000=6000000 pikseli. To chyba też oczywiste, bo wszystkie operacje trzeba przeprowadzić na większej liczbie obiektów (pikseli). Głębia koloru ma na to wpływ następujący. W pamięci komputera pojedyncza składowa koloru może mieć albo 8 bitów, albo 16 bitów. Taka jest organizacja pamięci i tego nie zmienimy. Wniosek z tego taki, że pomiędzy głębią 12-tu i 14-tu bitów NEFa nie ma tu żadnej różnicy. W obu przypadkach "robocza" składowa koloru będzie miała 16 bitów, czyli dwa bajty. Wyraźna skokowa różnica wystąpi dopiero przy "zejściu" w dół do 8-miu bitów. Tu każda składowa koloru będzie zapisana tylko na jednym bajcie. Danych do przetwarzania będzie mniej, dwa razy mniej, więc obróbka będzie "szybsza". Dlatego właśnie 8-mio bitowe JPEGi "obrabiają" się wyraźnie szybciej niż 16-to bitowe TIFFy, czy RAWy. Ale różnicy pomiędzy obróbką JPEGa i 8-mio bitowego TIFFa już nie będzie. Do tego dochodzi jeszcze fakt większej złożoności obliczeniowej 16-to bitowych algorytmów (takie pojęcie informatyczne) i to już właściwie wszystko.
Trzeci etap to zapis danych. Tu mamy identyczne uwarunkowania, jak w przypadku odczytu danych. Im mniej danych ma się znaleźć na dysku (w MB), tym szybszy bedzie zapis, ale im "bardziej złożony" algorytm kompresji, tym będzie wolniej. Przy czym znów w paktyce decyduje nie kompresja, a ilość danych do zapisania na dysku.
Co z tego wynika? Ano to, że jeśli komuś zależy na ekstermalnej szybkości, to powinien sobie ustawić w puszce JPEG Small (jakość kompresji FINE, ..., BASIC, nie ma tu praktycznego znaczenia). Jeśli ktoś ustawi sobie NEF, to różnice w czasie mogą być powodowane praktycznie tylko faktyczną wielkością plku na dysku. To, czy jest to 12, czy 14 bitów nie ma prawie żadnego znaczenia, bo i tak oba obrazki bedą obrabiane jako 16-to bitowe. A to czy NEF jest kompresowany, czy nie, ma znaczenie tylko podczas fizycznego odczytu i zapisu danych.
Oczywiście nie dotyczy to jakości zdjęć, tylko ogólnie rozumianej "szybkości" obróbki na komputerze.
Dzięki JK za tego posta. Wartościowe informacje.
nikomisiaki
06-03-2009, 15:34
Czy można zatem wywnioskować, że obróka w NX NEF-ów 14-to bitowych nieskompresowanych, będzie szybsza niż skompresowanych np bezstratnie??
Piotr
Czy można zatem wywnioskować, że obróka w NX NEF-ów 14-to bitowych nieskompresowanych, będzie szybsza niż skompresowanych np bezstratnie??Podczas obrobki kompresja pliku nie ma juz nic do rzeczy. Roznica jest w czasie otwierania i zapisu.
polecam 12 bit
jak nie widać różnicy to po co nadpisywać :)
a ja różnicy nie widzę żadnej
nikomisiaki
06-03-2009, 21:00
Podczas obrobki kompresja pliku nie ma juz nic do rzeczy. Roznica jest w czasie otwierania i zapisu.
Właśnie o czas zapisu do JPG mi chodzi. Czy nieskompresowany poleci szybciej?? Zresztą - muszę to sprawdzić empirycznie.
Właśnie o czas zapisu do JPG mi chodzi. Czy nieskompresowany poleci szybciej?? Zresztą - muszę to sprawdzić empirycznie.No, ale tu juz nie ma nic do rzeczy kompresja NEFa. :) Po tym jak zostanie otwarty, to juz nie wplywa na czas zapisu JPGa. Ten bedzie sie zapisywal (kompresowal) tak samo, jakby materialem zrodlowym byl NEF skompresowany, nieskompresowany, TIFF, czy JPG.
Mierzyles to, czy tylko teoretyzujesz? Bo mi caly czas chodzi o faktyczna roznice w czasie otwierania (czyli procesu od momentu odczytu z dysku, do pojawienia sie na ekranie).
Mam Ci udowadniać że dłuższy plik dłużej się wczytuje???
jest to oczywiste, ale nic nie mowilem o procesie kompresji.
Czyżby? :
Chodzilo o roznice miedzy otwarciem pliku z kompresja, a pliku bez kompresji. Tak sie sklada, ze plik z kompresja musi zostac zdekompresowany, co rowniez zajmuje iles tam czasu. Kwestia tego, czy czas odczytu tej roznicy w wielkosci pliku (z kompresja lub bez) nie jest tozsamy z czasem dekompresowania przez aplikacje w ktorej te pliki otwierasz.
Dobrze, niech to nawet bedzie mega-szybko. Ale czy jestes pewny, ze pliki z kompresja otwieraja sie szybciej niz te bez kompresji? Bo ja to sprawdzalem, i wbrew pozorom zauwazylem cos zupelnie odmiennego. Plik bez kompresji, mimo roznicy ponad 90% w wielkosci, w NC NX2 otwiera sie szybciej, co przeczy Twojemu wczesniejszemu stwierdzeniu. Tak wiec bardziej pasuje mi teza, ze w procesie otwierania pliku (czyli jak wspomniales -- przygotowania pliku tymczasowego) wiecej czasu procesor potrzebuje na dekompresje niz dysk na odczytanie roznicy w wielkosci pliku.
Testowane na C2D 2.8 GHz, dysk Caviar 250 GB 16 MB, 3 GB RAM 800 MHz, Nikon Capture NX2.
Widzisz, jedyny wniosek jaki można wysnuć jest taki, że:
1. na Twoim komputerze
2. w NX2
udało Ci się dłużej otwierać bliżej nieokreśloną liczbę skompresowanych plików. Czyli udowodniłeś dokładnie nic...
Męczysz mnie strasznie :D dlatego sam postanowiłem w NX2 zrobić testy. I, dla 20-tu 14b NEFów, wyszło co następuje:
- pliki skompresowane: 54 sek
- pliki nieskompresowane: 2 min 40 sek
AMD X2 64 3600, 2GB RAM 800, Seagate 250 Barracuda, Win XP Prof
Szczerze mówiąc, bardzo jestem ciekawy, jakie wyniki byłyby dla innych programów do obróbki RAWów.
Mam Ci udowadniać że dłuższy plik dłużej się wczytuje???Znowu przeinaczasz... :) Nie jest tu mowa tylko o odczycie z dysku, ale o procesie otwierania pliku przez aplikacje, na ktora sklada sie odczyt pliku z dysku i dekompresja (jesli takowa jest zastosowana).
jest to oczywiste, ale nic nie mowilem o procesie kompresji.
Czyżby? :
Chodzilo o roznice miedzy otwarciem pliku z kompresja, a pliku bez kompresji. Tak sie sklada, ze plik z kompresja musi zostac zdekompresowany, co rowniez zajmuje iles tam czasu. Kwestia tego, czy czas odczytu tej roznicy w wielkosci pliku (z kompresja lub bez) nie jest tozsamy z czasem dekompresowania przez aplikacje w ktorej te pliki otwierasz.
I co mi tu powyzej udowodniles? Jesli piszesz o kompresowaniu pliku, a ja oznajmiam, ze nigdzie nie wspominalem o procesie kompresowania, a nastepnie Ty twierdzisz mi ze jednak pisalem, cytujac jako "dowod" cytat, gdzie ani jednego slowa o kompresowaniu zdjecia nie ma, to jaki jest tego sens? :)
Widzisz, jedyny wniosek jaki można wysnuć jest taki, że:
1. na Twoim komputerze
2. w NX2
udało Ci się dłużej otwierać bliżej nieokreśloną liczbę skompresowanych plików. Czyli udowodniłeś dokładnie nic...Nic? Dla mnie do jest dowod, ze nie mylilem sie w przypuszczeniach, ze wydajnosc dzisiejszych dyskow jest na tyle duza, ze jakies tam smieszne 8-9 MB w roznicy odczytywanego pliku potrafi byc niczym w porownaniu z czasem jaki potrzeba na dekompresje w programie otwierajacym te pliki. :)
Męczysz mnie strasznie dlatego sam postanowiłem w NX2 zrobić testy. I, dla 20-tu 14b NEFów, wyszło co następuje:
- pliki skompresowane: 54 sek
- pliki nieskompresowane: 2 min 40 sek
AMD X2 64 3600, 2GB RAM 800, Seagate 250 Barracuda, Win XP Prof
:D
Takze zrobilem test. Dla 10 plikow skompresowanych i 10 plikow niekompresowanych:
-- nieskompresowane -- 15 sekund
-- skompresowane -- 17 sekund
Zeby bylo jeszcze bardziej porownywalnie do Twojego testu, zrobilem to samo na 20 plikach. Efekt:
-- nieskompresowane -- 32 sekund
-- skompresowane -- 36 sekund
Z tego wyciagnac mozna nastepujacy wniosek, ze system dyskowy w Twoim komputerze jest do bani! :D I to jest cale rozwiazanie zagadki -- skad sie bierze Twoje odwrotne do mojego stwierdzenie. Wyniki Twojego testu dla plikow nieskompresowanych, sa o prawie 200% gorsze niz w przypadku plikow skompresowanych, ktore sa mniejsze o najwyzej 80%. Jesli caly czas twierdzisz, ze na czas otwarcia pliku ma wplyw jedynie rozmiar pliku, a co za tym idzie czas ladowania go przez dysk, to jakim cudem z 80% roznicy w wielkosci, zrobilo Ci sie nagle 200% roznicy w czasie? Masz po prostu zle skonfigurowanego kompa i to wszystko. :D
A wracając do meritum sprawy 12 czy 14 bit (2s w tą czy w tamtą stronę to jałowa dyskusja, jak zależy mi na zdjęciu, może to być i 10s), może ktoś podsumuje wątek i podzieli się swoimi doświadczeniami? Jakoś nie zauważyłem w dyskusji kwestii szybkości zapisu w puszkach w obu trybach dla zdjęć wykonywanych w trybie ciągłym i problemu zapełnienia buforu.
A co do podstaw trochę ogólnych wyjaśnień można znaleść tu:
http://www.fotosite.pl/pdf/artykuly/cyfrowa-ciemnia/16-bitow-na-kanal.pdf.
(mam nadzieję, że autor i właściciel strony nie wniesie zastrzeżeń)
No chyba się nie spodobalo, niestety 404 - nawet jak poprawwi się adres w przeglądarce (.)
Jakoś nie zauważyłem w dyskusji kwestii szybkości zapisu w puszkach w obu trybach dla zdjęć wykonywanych w trybie ciągłym i problemu zapełnienia buforu.A co za problem samemu sobie to sprawdzic? :)
A co za problem samemu sobie to sprawdzic? :)
Nie problem, wystarczy poczytać instrukcję. stig - zbaczasz z wątku. Pytanie jest proste - czy warto korzystać z 14 bit nef-a kosztem spadku prędkości zapisu (dla fotografujących sport, ptaki itp. to istotne)?.
Oczywiście w studio, czy foceniu np. architektury pytanie na wyrost, ale nie o to mi chodziło.
miłego weekendu
Nie problem, wystarczy poczytać instrukcję.No wiec wlasnie -- skoro mozna to wyniesc z instrukcji, to po co zadajesz to pytanie?
Pytanie jest proste - czy warto korzystać z 14 bit nef-a kosztem spadku prędkości zapisu (dla fotografujących sport, ptaki itp. to istotne)?Ale to juz musisz sobie sam na to odpowiedziec -- czyli dla Ciebie liczy sie szybkosc, czy jakosc w cieniach. Akurat w takiej kwestii chcesz sie opierac na przyzwyczajeniach czy opinii innych? W kwestii bourbon czy szkocka, tez przeciez nie bedziesz wyciagal wnioskow po tym co kto lubi, tylko co Ty lubisz, prawda? :)
OK, jest to dyskusja o wyższości świąt Wielkiej Nocy nad świętami Bożego Narodzenia jak widzę. Dla mnie sprawa jest prosta - wątek zaczął się od tematu RAW 14 bit - warto, czy nie, a skończył się na bezsensownej dyskusji o twardych dyskach i możliwości systemów komputerowych.
Postawiłem proste pytanie - czy dla standardowych zastosowań, z jakimi na co dzień mamy do czynienia w fotografii amatorskiej warto stosować zapis 14 bit-owy, czy nie. Jak widać forumowicze to sami "zawodowcy" i takie pytania uważają za trywialne, wręcz śmieszne. Szkoda, że nie widać tego w publikowanych (z nielicznymi wyjątkami) na tym forum fotografiach. No cóż, każdy "orze jak może" .
Dziękuję za konstruktywne podejście do tematu życzę udanych zdjęć w pełnej 14 bitowej rozpiętości tonalnej.
Postawiłem proste pytanie - czy dla standardowych zastosowań, z jakimi na co dzień mamy do czynienia w fotografii amatorskiej warto stosować zapis 14 bit-owy, czy nie. Jak widać forumowicze to sami "zawodowcy" i takie pytania uważają za trywialne, wręcz śmieszne.Nie. Ale odpowiedz na to pytanie jest tak subiektywna, ze nie ma sensu sie nia kierowac. Nie potrafisz tego zrozumiec? Na jaka cholere sie czepiasz ciagle tego samego? Zaczniesz uzywac 14-bitow, bo ja napisze, ze uzywam, albo nie bedziesz uzywal, bo ja nie uzywam*? Co za problem zrobic sobie w kilku sytuacjach zdjecia 12 i 14 bit, porownac i wyciagnac wniosek? Jeden robi w 14 bitach bez kompresji, jeszcze inny w 12 bitach z kompresja stratna, a jeszcze inny w JPGu. Skoro juz sie zastanawiasz czy 12 czy 14 bit, to znaczy, ze juz JPGi raczej odrzuciles. Miales ku temu powodu, chociaz sporo ludzi nadal z powodzeniem fotografuje w tym formacie. A przeciez chyba nie zrobiles tego tylko dlatego, ze inni robia zdjecia do RAW, tylko zrobiles to (mama taka nadzieje) na podstawie konkretnych powodow, ktore zrozumiales sam, prawda?
* -- za "ja", wstaw kogokolwiek innego
Chyba jednak w takich wątkach jak ten warto zrezygnować z własnych opinii a po prostu dyskutować na pewnym poziomie ogólności. Każdy będzie mógł wyciągnąć z takiej dyskusji wnioski sam dla siebie i z powodzeniem używać takiego formatu, jaki mu odpowiada.
Jak wspomniałem - dla mnie objętość pliku ma znaczenie, dlatego mam takie a nie inne preferencje. Rozumiem natomiast (również dzięki temu wątkowi) włąściwości NEF 14bit nieskompresowanego i na pewno chętnie go wykorzystam tam, gdzie zajdzie taka potrzeba. Tyle, że to nie ma zupełnie żadnego znaczenia dla kogokolwiek oprócz mnie :)
Dość często zdarza się, że w moich zjęciach makro wystepują nieciągłości (skoki) tonalne - tak było z D80 i tak jest z D300. Zdjęcia zawsze robiłem w NEF-ach 12-bitowych.
Jak myśłicie, czy jest szansa na wyeliminowanie, lub znaczące ograniczenie tego zjawiska, jeśli będę robił zdjęcia w 14-bitowych NEF-ach (w nadchodzącym sezonie mam taki zamiar)?
Poniżej bardzo typwy przykład.
Pełny kadr
https://forum.nikoniarze.pl//brak.gif
źródło (http://img6.imageshack.us/img6/1243/0915.jpg)
i crop 1:1
https://forum.nikoniarze.pl//brak.gif
źródło (http://img6.imageshack.us/img6/2877/09151.jpg)
Te skoki masz po obróbce, czy z NEFa od razu? Największa szansa że zlikwidujesz takie coś jest, gdy będziesz obrabiał nawet 12bitowe zdjęcie w 16bitach.
pozdr
Jak myśłicie, czy jest szansa na wyeliminowanie, lub znaczące ograniczenie tego zjawiska, jeśli będę robił zdjęcia w 14-bitowych NEF-ach (w nadchodzącym sezonie mam taki zamiar)?
To raczej kwestia wywołania i profilu barwnego, ale musiałbym zobaczyć tego NEF-a żeby się upewnić. Wątpię, by 14 bitów mogło na to zaradzić.
Te skoki masz po obróbce, czy z NEFa od razu? Największa szansa że zlikwidujesz takie coś jest, gdy będziesz obrabiał nawet 12bitowe zdjęcie w 16bitach.
pozdr
Tak, te nieciągłości widać od razu po otwarciu NEF-a i niestety 16-bitów nie pomaga - próbowałem różnych kombinacji i efakt zawsze był wudoczny, mniej lub bardziej, ale był.
Przy rozjaśnianiu zdjęcia efekt oczywiśćie się potęguje, ale to naturalne raczej.
No to przykro mi. Ja się przekonałem, że dodając sztuczną winietkę w 16bitach jest plynność, a w 8-miu bardzo szybko wyłażą "krążki". Troche OT: przy kilkukrotnych zmianach przestrzeni RGB<>LAB w 8 bitach widać stratę, w 16 raczej bezkarnie...
No to przykro mi. Ja się przekonałem, że dodając sztuczną winietkę w 16bitach jest plynność, a w 8-miu bardzo szybko wyłażą "krążki". Troche OT: przy kilkukrotnych zmianach przestrzeni RGB<>LAB w 8 bitach widać stratę, w 16 raczej bezkarnie...
Wycieczki z przestrzeni edycyjnych RGB (najczęściej TRC gamma 2,2) do przestrzeni L*a*b (TRC L*) są masakrujące dla tonalności. Bez 16-tu bitów nie powinno się nawet tej przestrzeni dotykać, a ilość konwersji należy ograniczyć do minimum.
eeetamm...raz można przeskoczyć w te i nazad, co by w L podostrzyć...
eeetamm...raz można przeskoczyć w te i nazad, co by w L podostrzyć...
Wszystko można - tylko fakty są takie, że po takiej konwersji z 256 tonów na kanał zostanie 234. Do tego jeszcze jakaś krzywka, jakiś levelik, jakiś burn/dodge toolik, i mamy posteryzację jak sto diabłów.
Ja tam takie medzgipedzgi produkuję że mi to niestraszne
A do tematu to ma się tak, że dla mnie NEF daje głównie kontrolę nad WB i troche expozycją po fakcie, a już 12 czy 14 bitów, to ja w praktyce nie widze różnicy.
pozdr
Ja tam takie medzgipedzgi produkuję że mi to niestraszne
A do tematu to ma się tak, że dla mnie NEF daje głównie kontrolę nad WB i troche expozycją po fakcie, a już 12 czy 14 bitów, to ja w praktyce nie widze różnicy.
pozdr
By różnica między 12 a 14 bitową kwantyzacją była wyraźnie widoczna, trzeba bardzo forsownego potraktowania zdjęcia. Ma to zastosowanie w przypadku scen o b. dużych kontrastach tonalnych - przykładowo mamy ciemny pokój z dużymi oknami, ustawiamy ekspozycję na krajobraz za oknem, a potem wyciągamy z cienia niedoświetlone pomieszczenie.
A co do L*a*b to tak ostrzegam przy okazji, bo za sprawą Margulisa niefrasobliwe wycieczki do tej przestrzeni są dość popularne, warto mimo wszystko wiedzieć czym to ew. grozi.
Właśnie bardzo sobie cenię Margulisa, że pokazał mi jak zrobić żeby białe było białe (dla ślubnych fotografów ta przestrzeń jest bezcenna IMHO), i to jest dla mnie cenniejsze w LAB niż samo ostrzenie. Bardzo dobrze że te książki pojawiły się na polskim rynku, chociaż na dłuższą metę to jest HARDCORE, czytam to już drugi rok...
Czornyj - myślę, że można powiedzieć, że każda operacja czy konwersja w pewnym sensie jest ryzykiem degradacji obrazu, ale na ile konwersja do LAB i z powrotem w trybie 16 bit obniża tonalność? Przecież robiąc RAWY pracujemy w 16 bitach i dopiero na koniec zapisujemy JPG. Wydaje mi się, że wtedy nie ma aż takiej straty, chociaż ja oceniam tylko na oko, więc nie musi to być ocena miarodajna ;)
A Margulisa i tak chwalę, bo nie tłumaczy co nacisnąć, tylko "jak to działa" ;)
Ja tylko dodam, że poza makro (z doświetlaniem lampą) nigdy takich nieciągłości nie zauważyłem i poza makro ten problem dla mnie nie istnieje.
Ja tylko dodam, że poza makro (z doświetlaniem lampą) nigdy takich nieciągłości nie zauważyłem i poza makro ten problem dla mnie nie istnieje.
Bo w makro doświetlając lampą uzyskujesz bardzo czyste i wysycone barwy, oraz rozliczne partie długich gradientów. Podeślij mi NEF-ika, gdzie występuje problem - chętnie rzucę okiem.
Czornyj - myślę, że można powiedzieć, że każda operacja czy konwersja w pewnym sensie jest ryzykiem degradacji obrazu, ale na ile konwersja do LAB i z powrotem w trybie 16 bit obniża tonalność? Przecież robiąc RAWY pracujemy w 16 bitach i dopiero na koniec zapisujemy JPG. Wydaje mi się, że wtedy nie ma aż takiej straty, chociaż ja oceniam tylko na oko, więc nie musi to być ocena miarodajna ;)
A Margulisa i tak chwalę, bo nie tłumaczy co nacisnąć, tylko "jak to działa" ;)
Margulis to doświadczony parktyk, pomysłowy eksperymentator i poszukiwacz - wiele jego rozwiązań jest inspirujących, ale techniki te są często dość brutalne dla kogoś, kto lepiej rozumie matematyczną tkankę cyfrowych obrazów. Odnosiłem się do działań na palecie 8-o bitowej, gdzie przy tego typu agresywnych konwersjach szybko nastąpi zmęczenie materiału. Nie chodzi mi o udawadnianie, że dana technika jest błędna i powoduje degradację, tylko o to, by mieć świadomość że tego typu konwersje degradują paletę zdjęć i należy stosować je rozsądnie i z umiarem (w miarę możliwości ubezpieczając się paletą 16-o bitową).
Podeślij mi NEF-ika, gdzie występuje problem - chętnie rzucę okiem.
Ok, zaraz coś poszukam i podeślę na adres z Twojej wizytówki :)
Ok, zaraz coś poszukam i podeślę na adres z Twojej wizytówki :)
Tak jak przypuszczałem - powodem są jakieś dziwne nieliniowości w profilach barwnych Nikona, które dodatkowo są potęgowane przez D-lightning. W ACR problem praktycznie nie występuje, nawet przy forsownym operowaniu "fill lightem" (odpowiednik NX-owego D-lightningu w opcji shadows)
To przykre, że nikonowski CNX nie radzi sobie sobie z takimi sytuacjami, a ACR daje sobie radę. :(
Czy da się jakoś zmusić CNX-a do radzenia sobie z tymi nieliniowościami? Może jakieś inne ustawienia, profile, przestrzenie, czy co tam jeszcze...
Czy jeszcze jest ktoś chętny do pobawienia się przykładowym NEF-em w CNX? ;)
Czy jeszcze jest ktoś chętny do pobawienia się przykładowym NEF-em w CNX? ;)Slij na
[email protected] Ale tkne go dopiero jutro. Dzisiaj za duzo roboty mnie jeszcze czeka.
Wrzuć gdzieś tego NEFa, to się chętni znajdą. :wink:
Czy da się jakoś zmusić CNX-a do radzenia sobie z tymi nieliniowościami? Może jakieś inne ustawienia, profile, przestrzenie, czy co tam jeszcze...
Czarno to widzę - próbowałem praktycznie wszystkiego. Tęcza wychodzi na wszystkich profilach barwowych, a d-lightning akurat bardzo ją podkreśla.
Wrzuć gdzieś tego NEFa, to się chętni znajdą. :wink:
chętnie, gdzie mam go wrzucić? (ponad 13 MB)
wigi, szczerze mówiąc ja nie widzę tych nieciągłości ani w ACR ani w CNX. Dla jasności: w przykładzie który dałeś na forum widzę to wyraźnie, w pliku który mi przysłałeś jakoś nie mogę się przyczepić. Możesz mi wysłać dokładnie ten plik który tu zamieszczałeś?
włącz d-lighting - bez tego też widać, ale słabo i na dobrym monitorze.
a po co uzywac tego d-costam ?
przeciez wiadomo ze to nie jest bez wplywu na jakość?
wigi, szczerze mówiąc ja nie widzę tych nieciągłości ani w ACR ani w CNX. Dla jasności: w przykładzie który dałeś na forum widzę to wyraźnie, w pliku który mi przysłałeś jakoś nie mogę się przyczepić. Możesz mi wysłać dokładnie ten plik który tu zamieszczałeś?
Dostałeś ten sam plik, co Czornyj - na nim równie dobrze widać ten problem, co na pliku zamieszczonym wcześniej w wątku.
Dziwne, że nic nie widzisz. Chodzi o przejścia do głębokiego cienia w LG. Mam raczej dobry monitor (Eizo 2110W) i widzę wyraźnie nieciągłości po wywołaniu w CNX, a po zastosowaniu D-lighitng robi się masakra.
a po co uzywac tego d-costam ?
przeciez wiadomo ze to nie jest bez wplywu na jakość?
I bez D-lighting nie jest dobrze.
a po co uzywac tego d-costam ?
przeciez wiadomo ze to nie jest bez wplywu na jakość?
po to, żeby rozjasnic cienie. Można zresztą użyć krzywych, czy suwaka ekspozycji - albo uważnie oglądnąć to co jest -w cieniu czai sie nieliniowość, a d-lughting tylko ją eksponuje.
Mooooożeeee coś tam jakby troche mniej ciągle z dL... ale to w ogóle niepodobne do tego co widzę jako przykład w tym wątku. Czornyj, mamy te same pliki? 0706?
Oglądam to na EIZO 1932, jakoś mnie to wcale nie przekonuje, problem jak na razie niewidoczny...
edit/ OK, wywołam, zapiszę i wystawię, może ja mam coś z oczami
Nic nie ruszane, CNX:
http://www.pbase.com/andrzejmakal/image/109974184
Odpalony dLightning jakiś tam w CNX (bo chyba o to Wam chodzi)
http://www.pbase.com/andrzejmakal/image/109974188
Proszę o komentarz
Odpalony dLightning jakiś tam w CNX (bo chyba o to Wam chodzi)
To nie tak - rozjaśniłeś tylko jasne partie, zamiast rozjaśnić cienie :)
W D-lighting utaw: HQ i Adjustment np. 30
No to jak mocno forsujesz krzywe, to zawsze jakiś syf wylezie. I tu nie ma chyba nic do rzeczy czy dL zrobisz w CNX czy rozgrzebiesz plik w CSie po wywołaniu ACRem. Ale nawet w Twoim ustawieniu nie widze tragedii, pliki w wątku wyglądają dużo gorzej.
Tak w ogóle to ja NX dużo bardziej cenię jako wywoływacz niż ACRa, a główne pretensje to raczej do aparatu niż do softu raczej...
maki. ale nawet na pierwszym, jedynie wywołanym, zdjęciu widać nieciągłości (popatrz na monitor LCD z boku ;)), po zastosowaniu DL jest już po prostu źle.
Ciekawe dlaczego ACR radzi sobie z tym zancznie lepiej?
Tak na szybko. Fota jest niedoświetlona o 1EV. Zdjęcie z body jest wyostrzone na 5 (jest to przyjmowane defaultowo), a to powoduje "rozwalanie" gradientów podczas wyciągania informacji z cieni - wyostrzany jest szum, a później się to jeszcze bardziej pogłębia przy wyciąganiu.
Ja bym to zrobił tak:
- Profil D2X mode II.
- Wyostrzanie na 0 (ewentualnie lekki zjazd z saturacją).
- Korekta +1EV.
- Kontrast -1 lub -2.
- Odpowiednie ustawienie suwaczków w Quick Fix, żeby nie tracić żadnych informacji z cieni i ze świateł.
- D-Lighting (jaki chcesz, ale trzeba pamiętać, że już wyciągnęliśmy o +1EV, a D-Lighting wyciągnie o nastepne 1-2EV, czyli wylezą szumy - w gradientach też).
- Maska na te miejsca, gdzie nie mamy tych "wyciąganych" gradientów, tylko ostre żyjątko.
- Mocne odszumianie tego, co nie jest zamaskowane (było wyciągane), albo jakiś Gauss (rezultat bedzie podobny).
- Maska na to, co nie ma być wyostrzane, czyli na te "wyciągane" gradienty.
- Selektywne wyostrzenie okolic żyjątka i tego co ma być ostre.
Ale i tak pewnie bym zaczął od dokładniejszego naświetlenia i włączył bym ADL - to się zawsze daje wyłączyć, a często pomaga.
maki. ale nawet na pierwszym, jedynie wywołanym, zdjęciu widać nieciągłości (popatrz na monitor LCD z boku ;)), po zastosowaniu DL jest już po prostu źle.
Ciekawe dlaczego ACR radzi sobie z tym zancznie lepiej?
ACR radzi sobie z tym znacznie lepiej, bo nie czyta tego deaultowego wyostrzenia ustawionego na 5 i paru innych rzeczy.
Tak na szybko. Fota jest niedoświetlona o 1EV.
Ja bym to zrobił tak:
- Korekta +1EV.
- D-Lighting (jaki chcesz, ale trzeba pamiętać, że już wyciągnęliśmy o +1EV, a D-Lighting wyciągnie o nastepne 1-2EV, czyli wylezą szumy - w gradientach też).
No bez przesady Jacku - fota jest niedoświetlona jedynie o 0,5 EV i nie ma potrzeby po kolei wyciągania jej poprzez korektę aż +1EV, a następnie jeszcze silny D-lighting 1-2 EV, jak sugerujesz.
Ale i tak pewnie bym zaczął od dokładniejszego naświetlenia i włączył bym ADL - to się zawsze daje wyłączyć, a często pomaga.
Czy ADL daje się wyłączyć przy/po wywoływaniu NEF-a?
Oczywiście dziękuję wszystkim za uwagi i pomoc :)
ACR radzi sobie z tym znacznie lepiej, bo nie czyta tego deaultowego wyostrzenia ustawionego na 5 i paru innych rzeczy.
ACR radzi sobie lepiej, bo ma inne profile, lub algorytmy demozaikizacji. W NX-ie ewidentnie jest jakaś nieliniowość w cieniach, która interpretuje ciemną zieleń raz jako bardziej zieloną, raz bardziej magentową. Nie ma sensu dorabiać do tego ideologii, w ACR choćbym niewiem jak się znęcał i jak bardzo się starał nie uzyskam podobnego efektu:
https://forum.nikoniarze.pl//brak.gif
źródło (http://members.chello.pl/m.kaluza/acrvsnx.jpg)
wigi, czy te nefy są skompresowane? u mnie w d300 podobny problem zniknął po przestawieniu ze skompresowanych na nieskompresowane
Ja bym to zrobił tak:
- Profil D2X mode II.
- Wyostrzanie na 0 (ewentualnie lekki zjazd z saturacją).
- Korekta +1EV.
- Kontrast -1 lub -2.
- Odpowiednie ustawienie suwaczków w Quick Fix, żeby nie tracić żadnych informacji z cieni i ze świateł.
- D-Lighting (jaki chcesz, ale trzeba pamiętać, że już wyciągnęliśmy o +1EV, a D-Lighting wyciągnie o nastepne 1-2EV, czyli wylezą szumy - w gradientach też).
- Maska na te miejsca, gdzie nie mamy tych "wyciąganych" gradientów, tylko ostre żyjątko.
- Mocne odszumianie tego, co nie jest zamaskowane (było wyciągane), albo jakiś Gauss (rezultat bedzie podobny).
- Maska na to, co nie ma być wyostrzane, czyli na te "wyciągane" gradienty.
- Selektywne wyostrzenie okolic żyjątka i tego co ma być ostre.
Ale i tak pewnie bym zaczął od dokładniejszego naświetlenia i włączył bym ADL - to się zawsze daje wyłączyć, a często pomaga.Miast tej ekwilibrystyki, wystarczy wlaczyc tylko Noise Reduction na okolo 10 w trybie Better Quality i tylko dla kanalu chrominancji. Pasmowanie znika.
Miast tej ekwilibrystyki, wystarczy wlaczyc tylko Noise Reduction na okolo 10 w trybie Better Quality i tylko dla kanalu chrominancji. Pasmowanie znika.
Stig - mówisz o NX2? W NX1 mogę sobie dać na 100% a i tak nie znika.
wigi, czy te nefy są skompresowane? u mnie w d300 podobny problem zniknął po przestawieniu ze skompresowanych na nieskompresowane
kurde, byłem pewien, że to 12 bitów, a NX pokazuje, że 14 - skompresowane bezstratnie (tylko w jednym miesiacu tak miałem ustawione, w pozostałych 12 bit).
a tak liczyłem, że jak przejde na 14 bitów to się nieco poprawi, a tu jest już max :(
Czornyj, to po lewej to ACR, a po prawej CNX?
wigi, ludzie jakoś z tym żyją, bez przesady. Co masz lepszego w tej chwili? Film? Na czym musiałbyś go skanować żeby zachować ogólnie wyższą jakość niż z d300/700/3?
kurde, byłem pewien, że to 12 bitów, a NX pokazuje, że 14 - skompresowane bezstratnie (tylko w jednym miesiacu tak miałem ustawione, w pozostałych 12 bit).
a tak liczyłem, że jak przejde na 14 bitów to się nieco poprawi, a tu jest już max :(
Czornyj, to po lewej to ACR, a po prawej CNX?
Tak - z lewej ACR, po prawej NX1, w ACR wymiąchałem cienie nawet trochę mocniej, by pokazać że na niego nie ma bata. Tak jak mówiłem - efekt wychodzi nawet na 14-tu, bo to nie jest kwestia mało precyzyjnej kwantyzacji, tylko najprawdopodobniej profilów barwnych, lub algorytmów demozaikizacji NX-a.
Jedyne co mz. ewentualnie może pomóc to wypróbować NX2 i tą metodę stiga, w NX1 oczywiście też to sprawdziłem, ale tutaj to nie daje efektu.
"Tym co mi najbardziej przeszkadza w robieniu pięknych zdjęć jest p...ny aparat fotograficzny" - Fajnie by było - marzę o tym - widzisz piękny landszafcik i przesyłasz znajomym - wprost. Tak z głowy do głowy - bez sprzętu, oprogramowania itp kłopotów. No ale to utopia niestety. Wypaliłem tu jak "filip z konopii" - ale coś w tym jest
"Tym co mi najbardziej przeszkadza w robieniu pięknych zdjęć jest p...ny aparat fotograficzny" - Fajnie by było - marzę o tym - widzisz piękny landszafcik i przesyłasz znajomym - wprost. Tak z głowy do głowy - bez sprzętu, oprogramowania itp kłopotów. No ale to utopia niestety. Wypaliłem tu jak "filip z konopii" - ale coś w tym jest
Tak naprawdę to to by popsuło całą zabawę ;)
I kazdy by umial. I nie byloby fotografii... :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.