Zły pomiar światła w Samyangu 35mm z chipem dandelion

[sylwek2k]

w tym momencie zasadne jest pytanie: na diabla w takim razie dandelion z przekazaniem maksymalnego swiatla i mozliwoscia ustawienia w korpusie wartosci przyslony?

Jak robisz studyjne, to faktycznie, mozna sie tak bawic (czyli blokowanie ekspozycji, zmiana przeslony na obiektywie, pstryk). Mnie by szlag trafil, gdybym w ten sposob mial postepowac w zmiennym oswietleniu (czyli w praktyce w plenerze).

jesli dobrze pamietam, to sa tez dandeliony, ktore tylko identyfikuja szklo i zapewniaja potwierdzenie ostrosci, ale nie pozwalaja na zmiane liczby f. przynajmniej tak mi sie wydaje, ze mial moj do OM-a.

Owszem i co ciekawe, w takich nie ma problemu z 'pomiarem swiatla' - one zawsze dzialaja :P

w wypadku tego Samyangowego IMHO lepiej juz po ustawieniu parametrow ekspozycji, wybrac sobie w korpusie wlasciwe f, zeby je miec w EXIF-ie. jesli pracuje sie w trybie manualnym, to na ekspozycje to nie bedzie mialo wplywu...

Ech.. nie wiem jak Ty, ale ja rzadko sprawdzam, na jakim 'f' robilem dane zdjecie :P czesciej sprawdzam jakim 'f' ktos inny robil :P

[mc_iek]

Przekłamywanie światłomierza przy szerokich obiektywach manualnych to chyba efekt kątów padania światła na matówkę. Mam manualne 28/2,8; 50/1,5; 135/2,8 i 300/4. Zasadniczo przy 135 i 300 nie występuje problem błędu pomiaru nawet przy maksymalnym przymknięciu przysłony. Przy 50-tce jest on niewielki ale przy 28 jest już na tyle duży, że przy f:4 muszę dawać korektę. W 350d miałem matówkę z klinem i rastrem i na niej nie było problemu. Na standardowej już niestety był. Na standardowej matówce w 50d problem też jest, więc chyba chodzi o sposób odbijania się światła od matówki.

[Aleximov]

Witam,

O dandelionach programowalnych i nieprogramowalnych, oraz dlaczego "przekłamują EV", słów kilka napisano tutaj:
http://www.canon-board.info/showthre...=10534&page=14

Pozdrawiam, Alex

[akustyk]

Jak robisz studyjne, to faktycznie, mozna sie tak bawic (czyli blokowanie ekspozycji, zmiana przeslony na obiektywie, pstryk).

a fe, prosze mnie nie obrazac od zwierzecia zyjacego w niewoli domow z betonu

fotografuje wylacznie na dworze (landszaft, podrowe). we wnetrzach, jesli juz, to nazwalbym to pstrykaniem fotek.

Mnie by szlag trafil, gdybym w ten sposob mial postepowac w zmiennym oswietleniu (czyli w praktyce w plenerze).

nie robi mi. i tak standardowo pracuje w pelnym manualu, poza automatyka nastawiania ostrosci (no, w tym konkretnym przypadku nawet i bez niej ).

Owszem i co ciekawe, w takich nie ma problemu z 'pomiarem swiatla' - one zawsze dzialaja :P

jak wyzej: jest to w pelni logiczne. tylko jest to przyklad "triumfu" inzynierii nad egonomia. jako analityk danych poslugujacy sie na codzien wlasnym firmowym softem moge tylko napisac &*& (cenzura) $#$, kolejnym znowu triumfem implementacji nad use case'ami i testami uzytkowymi

Ech.. nie wiem jak Ty, ale ja rzadko sprawdzam, na jakim 'f' robilem dane zdjecie :P czesciej sprawdzam jakim 'f' ktos inny robil :P

przy kopiowaniu ustawien odplamkowania w LR czesto sprawdzam f. robie 95% na f/8 albo na f/11 i w tym drugim przypadku niestety juz trzeba walczyc, nie da sie na skroty. dlatego sprawdzam czy nie f/8, bo wtedy moge troche czasu oszczedzic

[Usjwo]

Aby pomiar swiatla byl prawidlowy to aparat musi wiedziec jaka jest rzeczywista wartosc przyslony. Jezeli obieektyw takiej informacji nie przesle do korpusu (a tak jest w tym przypadku) to puszka przyjmuje to co zwraca mu dandelion. To nie jest przyklad "triumfu inzynierii nad egonomia", z pustego to i Salomon nie naleje. Tryb manualny tu pomoze, o tyle o ile wiemy jakie f widzi puszka, jakie f ustawilismy na obiektywie, wtedy mozemy "przeswietlac/niedoswietlac" wskazanie swiatlomierza

[akustyk]

Aby pomiar swiatla byl prawidlowy to aparat musi wiedziec jaka jest rzeczywista wartosc przyslony. Jezeli obieektyw takiej informacji nie przesle do korpusu (a tak jest w tym przypadku) to puszka przyjmuje to co zwraca mu dandelion.

nic nie stoi na przeszkodzie temu, zeby aparat "przyjal", ze to co on ma naklikane to faktyczna wartosc. poza implementacja, ktora jest wlasnie inzynierska i w tym konkretnym przypadku za diabla nie przystaje do realiow. kwestia tego konkretnego, ztrywializowanego przez projektantow przypadku, ale to nadal jest przypadek, w ktorym rozwiazanie jest poprawne i logiczne technicznie, ale za diabla nie przystaje do praktyki.

i absolutnie daleki jestem od bronienia inzynierow/projektantow, bo IMHO powinni strzelac do takich, ktorzy projektuja bez uwzglednienia potrzeb faktycznych i bez testu uzytkowego przez realnych uzytkownikow. mimo ze sam tez jestem po Polibudzie. niestety, w realu musze tyle badziewia po Java-patalachach latac, ze mnie krew zalewa. a wystarczy po prostu pomyslec, ze w raporcie do druku dla ksiegowego, 1.080.345.345,22 to poprawna kwota, natomiast 1,08E07 albo 1.080.345.345,219999999 to nie jest. a to tylko jeden, aczkolwiek notoryczny przyklad takiego "triumfu" inzynierii...

[Usjwo]

Najlepiej w takich przypadkach zeby na puszce ustawione bylo takie samo f jakie jest zwracane przez dandelion, wtedy wszystko sie zgadza z pomiarem (poza EXIFem). Zlym rozwiazaniem jest mozliwosc "nakilkania" wartosci, ktora wlasnie oszukuje swiatlomierz. Co do programowania to nie zawsze jest czas na wszystko (a w zasadzie nigdy nie ma). W koncu napisanie aplikacji to zawsze "pikus", oprogramowanie wyjatkow i bledow to jest wyzwanie, wychodzi z 60% kodu, i to wtedy gdy w aplikacji nie ma interface z userem .

[akustyk]

Najlepiej w takich przypadkach zeby na puszce ustawione bylo takie samo f jakie jest zwracane przez dandelion, wtedy wszystko sie zgadza z pomiarem (poza EXIFem). Zlym rozwiazaniem jest mozliwosc "nakilkania" wartosci, ktora wlasnie oszukuje swiatlomierz.

to jest to rozwiazanie z dandelionem, ktory nie podaje f do korpusu, a tylko identyfikacje lensa. i to dziala.

ale jesli jest juz dandelion podajacy f, to chcialoby moc z tej funkcji korzystac, a przy takim rozwiazaniu jak jest, robi sie to kompletnie afunkcjonalne.

Co do programowania to nie zawsze jest czas na wszystko (a w zasadzie nigdy nie ma). W koncu napisanie aplikacji to zawsze "pikus", oprogramowanie wyjatkow i bledow to jest wyzwanie, wychodzi z 60% kodu, i to wtedy gdy w aplikacji nie ma interface z userem .

wiem, przerabialem.

ale mowie o przypadkach, kiedy oprogramowanie jest kompletnie nieprzystajace do realiow. przyklad z mojego podworka: hadoop pig, prosty jezyk skryptowy do algebry relacji na plikach tekstowych.
wydawaloby sie, ze funkcja SUM(x) zostala zaimplementowane w celu wyliczenia sumy jakichs wartosci, w szczegolnosci w przypadku floatow bedzie to stosowane do sumowania kwot (pomijam chwilowo pomysl zapisywania kwot jako floatow - to juz wewnatrzfirmowi Java-programisci mi to popelnili). ale zeby to raz przetestowac i zauwazyc, ze wynik w notacji '1E08' mozna sobie w tylna czesc ciala wsadzic... to trzeba miec troche wiecej wyobrazni niz miedzy { a }

[MacRo]

Używam dandeliona z Samyangiem 85. Ba, nawet programowalnego . Problem z niewłaściwym czasem naświetlnia niestety również tu występuje. Według mnie jedyne co można w tej kwestii zrobić, by osiągać zadowalające wyniki to zabawa w pełnym manualu lub tryb Av + kombinowanie z korektą ekspozycji.

[sylwek2k]

jak wyzej: jest to w pelni logiczne. tylko jest to przyklad "triumfu" inzynierii nad egonomia. jako analityk danych poslugujacy sie na codzien wlasnym firmowym softem moge tylko napisac &*& (cenzura) $#$, kolejnym znowu triumfem implementacji nad use case'ami i testami uzytkowymi

Dwie kwestie: Canon produkuje w zasadzie tylko szkla z AF - wiec im nie zalezy na implementacji czegokolwiek w standardzie komunikacji, z czego skorzysta tylko i wylacznie konkurencja :P

Druga kwestia: Samyang moglby zrobic uklad automatycznej migawki - tyle ze to zwiekszylo by koszty produkcji i niekoniecznie te obiektywy byly by takie konkurencyjne...