Dpp 3.9

[wagteil]

A jesteś pewien, że problem tkwi w DPP, a nie w twoim (być może zaśmieconym) systemie? Zrobiłem podobną próbę, lekko licząc koło 100 kliknięć pipetą w różne zdjęcia - zero zwiechy.

System zalozylem wczoraj win7 64, 16 ram i a caly system na SDD. Nie ma mowy o zasmieconym systemie.

[Merde]

System zalozylem wczoraj win7 64, 16 ram i a caly system na SDD. Nie ma mowy o zasmieconym systemie.

<spekulacja>Być może problem tkwi w 64 bitowym systemie?</spekulacja>

[wagteil]

Problem tkwi definitywnie w DPP a nie w systemie;-)

[szwayko]

Problem tkwi definitywnie w DPP a nie w systemie;-)

Ja od roku używam DPP na Win7-64 nie miałem żadnych zawieszeń. Z tym ze mało używam pipety. Pozostałem na wersji chyba 3.9.4, bo potem zwiększyli czcionkę nazw plików w thumbs i nie widziałem ich całych. Dzisiaj sprawdzę pipetę i napiszę czy miałem zawieszenie.

[ewg]

MAM ZŁE WIEŚCI dla osób fotografujących obiektywami normalnie niekorygowanymi przez DPP - które jednak dotąd korzystały z korekcji (przynajmniej niektóych) aberracji dzięki modyfikowaniu metadanych swoich plików (Canon Makernotes: LensType). Otóż zauważyłem, że od wersji 3.10 wspomniane obejście już NIE DZIAŁA i pliki tak zmodyfikowane we wcześniejszych wersjach DPP, w tej najnowszej będą wyświetlane i konwertowane bez stosowania korekcji aberracji czyli inaczej!

JEST JEDNAK NADZIEJA! Otóż dzięki pomocy i wnikliwości autora ExifTool GUI, pana Bogdana Hrastnika mamy już sposób na obejście wspomnianego ograniczenia! Otóż okazuje się, że DPP 3.10 sprawdza dodatkowo zgodność merytoryczną wartości LensType (dotychczas jedyna istotna) z wartościami LongFocal i ShortFocal - czyli skrajnymi wartościami ogniskowych zooma. Po ich uzgodnieniu DPP 3.10 przywraca opcje korekcji aberracji tak zmodyfikowanym plikom! :cool:

Pan Bogdan podaje też sposób takiej modyfikacji przy użyciu jego ExifTool GUI v4.x i dostęnego tam wiersza poleceń 'ExifTool direct'. Właściwe polecenie dla przykładowego LensType: EF-S17-55 to:

-LongFocal=55 -ShortFocal=17

Link do źródła: http://u88.n24.queensu.ca/exiftool/f...ic,3279.0.html

Miejmy nadzieję, że autorowi uda się to zadanie niebawem jeszcze bardziej zautomatyzować. ;-)

[airhead]

<spekulacja>Być może problem tkwi w 64 bitowym systemie?</spekulacja>

16 gb ram w 32-bitowym systemie?

[myslidar]

Może 13 GB to RAM dysk

[szwayko]

Ja od roku używam DPP na Win7-64 nie miałem żadnych zawieszeń. Z tym ze mało używam pipety. Pozostałem na wersji chyba 3.9.4, bo potem zwiększyli czcionkę nazw plików w thumbs i nie widziałem ich całych. Dzisiaj sprawdzę pipetę i napiszę czy miałem zawieszenie.

Pierwsze klikniecie pipeta - zawiecha, trzy razy pod rząd odpalałem program. Za czwartym razem coś się odblokowała i można było klikać do woli.

[Merde]

16 gb ram w 32-bitowym systemie?

Zdaję sobie sprawę z ograniczeń WIN32 co do ilości obsługiwanej pamięci.
Po prostu zakładam, że DPP pisane jest z myślą o WIN32 i testowane na WIN32 może nie zachowywać się prawidłowo na systemie 64-bitowym.
64-bity to chyba dalej więcej problemów niż korzyści dla 90% użytkowników.

[Kanghoy]

@Merde oj już od dłuższego czasu nie. Biorąc pod uwagę jeszcze możliwości win7 w odpalaniu oprogramowania zgodnie z różnymi systemami zupełnie bez sensu jest obecnie inwestycja w system 32bitowy. Aplikacje 64bitowe chodzą zauważalnie szybciej od 32bitowych odpowiedników.