Photoshop CS5

[de Fresz]

Tak się bawię wersją krążącą po sieci i co mogę powiedzieć:
1. Największą zmianą będzie dla mnie chyba usprawniony quick selection tool. Nie dość, że sam z siebie działa naprawdę dobrze, to jeszcze pozwala przy refine edge dodać obszar za pomocą maski.

Czyżby w końcu stał się w ogóle używalny? I to już po 2 wersjach od wprowadzenia? Ojej, wzruszyłem się

2. NARESZCIE lens correction jest osobną zakładką w filters i NARESZCIE ma normalne narzędzie do prostowania zdjęcia. Już nie trzeba w debilny sposób najpierw prostować zdjęcia, a potem go cropować jak uprzednio.

IMHO ficzer bez większego sensu, bo zrobienie tego transformem daje większą kontrolę i jest conajmniej równie szybkie. No ale może to degustibusy.
Pewnie możliwości korygowania nieliniowej poduchy się nie doczekaliśmy?

3. W tej wersji nie ma jeszcze wgranych profili dla obiektywów, ale z tego co widzę, będą gotowe profile dla obiektywów i wystarczą dwa kliknięcia i pozbywamy się CA/winetowania/dystorsji.

Pytanie czy te algorytmy będą działały lepiej od tego, co serwuje np. Olek w Penach i czy nie będą robiły sieczki w pikselach.

4. Content aware fill w większości wypadków jest kiepski, content aware healing brush też niezłe kwiatki wywala. Jednak fill przy uzupełnianiu niektórych przypadków działa wręcz rewelacyjnie i oszczędza mnóóóóóstwo czasu. Ale to raz na 10 przypadków.

Przy jakiej wielkości zdjęć?

[de Fresz]

Nowe narzędzia do retuszu szumnie prezentowane uważam jednak za pomyłkę. Nie nadają się dla wymagających. Różnice na przejściach są widoczne gołym okiem. Algorytmy jednak nie wyręczą człowieka z mniej zautomatyzowanymi narzędziami.

Ło matko, zaraz wyjdzie, że jestem jakimś jasnowidzem , ale oglądając to na demie z (bodaj) jesieni już to wiedziałem. Coś takiego nie ma jeszcze szans działać na naprawdę dobrym poziomie, bo do tego potrzebna byłaby szczegółowa analiza zawartości obrazu oraz algorytmy do losowej dystrybucji elementów naturalnych, dodatkowo nie gubiące się na powtarzalnych wzorach i analizujące światło sceny. To jeszcze nie te komputery
Zastosowania do znajdzie przy fotkach na NK, może przy niektórych w rozdzielczościach netowych oraz może przy dłubaniu klatek filmowych. Cokolwiek więcej od razu będzie jechać sztuczyzną. Ale Adobi już od dawna celuje w wyrywaniu dla Szopa klienteli spośród lajkoników, co widać po kolejnych cudownych i przenetelygentnych automatach, których z wersji na wersję jest coraz więcej.

Pozdrawiam
de Fresz

[de Fresz]

Możemy podziękować za to firmie Apple - ZTCW programiści Adobe musieli odwalić kawał tak tytanicznej i zbędnej pracy by przepisać kod CS z Carbona na Cocoę, że nie bardzo mieli czas na takie pierdoły, jak wprowadzanie nowych, rewolucyjnych funkcji w Photoshopie.

Równie absurdalne byłoby twierdzenie, że zupełnie niepotrzebnie marnowali czas przy optymalizacji CS4 dla Windy, zamiast wziąć się za pisanie nowych ficzersów.
Cocoa wyszła z pierwszymi OS X i od początku było wiadomo, że Carbon jest tylko rozwiązaniem tymczasowym. Przez blisko 10 lat jakoś sami z siebie ci młodzi, zdolni i jakże pracowici programiści z Adobe nie byli w stanie znaleźć wolnej chwilki na optymalizację makowego Szopa (zresztą można ich zrozumieć, był tam totalny burdel w kodzie, który narastał przez wiele lat), że dopiero prztyczek od Jejpla ich do tego zmusił, gdyż ów nie ma ochoty na zabawę a la Winda z pokładami kompatybilności sięgającymi 25 lat wstecz. No i teraz w Adobe będą pewnie mieli spokój na następne z 10 lat.

Nareszcie porządne wsparcie wykorzystujące przechył i kąt Intka w pędzlach podczas malowania!

Ło matko, po 15 latach!

[de Fresz]

Zaden zawodowiec od retuszu nie pracuje na jednej warstwie.

Zdziwiłbyś się

Ostrzenie NEFa to takze katastrofa -- lepiej zostawic to samemu Shopowi.

Czyli bez zmian (wbrew krążącej tu i ówdzie legendzie). Ale już może za 3 wersje...

Ale narzedzia korekcji lokalnej nie dzialaja tak dobrze jak w NXie. I co najwazniejsze -- ciagle produkuje ch...we kolory i przebarwione cienie.

Akurat w Szopowym ACRze korekcje lokalne to IMHO wodotrysk. Bo po co sobie aż tak utrudniać życie?

Szczerze przyznam, ze biorac pod uwage upgrade z CS4 -- nie widze tutaj sensu przesiadki dla zadnej grupy uzytkownikow. Czyli potwierdze tylko slowa Andrzeja i Czornyja. Dla kogokolwiek -- czy to DTPowiec, czy fotograf, czy grafik (rysownik) -- ulepszenia czy dodatki -- sa znikome. Wiekszosc pozycji we wspomnianym whats new, to nadmuchane *******y, majace naprawde znikome znaczenie.

Ale że niby to nowum jakieś? Toż to dobrze ugruntowana tradycja u Adobiego, sięgająca hen, hen wstecz. Jeden-dwa przydatne ficzersy i parę wodotrysków.
W CS1 dali ACRa (bo siódemkowy to była marna imitacja), w CS2 AFAIR dali sensowniejsze Sety, w CS3 pieczątkę, w CS4 (jak dla mnie i na Maku) - nic. No nie licząc apdejtów ACRa, które zwłaszcza dla posiadaczy nowszych aparatów bywały niezbędne (DNG-C sobie darujmy).
IMHO apdejt ma sens o co najmniej 2 wersje, choć jak patrzę na CSa 5 w zestawieniu z CS3, to poza ACRem oraz optymalizacją pod OS X, nie dostrzegam nic wnoszącego cokolwiek do codziennej pracy. No może jeszcze tą nową inteligentną różdżkę.

zeby wlasnie mozna bylo umieszczac przeciagany plik w ten wlasnie sposob. No i zrobili... Tyle, ze troche niedopracowana jest ta opcja. Umieszczany obrazek (jesli jest wiekszy niz dokument, w ktorym jest umieszczany), jest automatycznie dopasowywany do rozmiarow krotszego boku dokumentu istniejacego.

W CS4 jest opcja "Resize image during place/paste" - nic nie zmienia?

Drugi duperelek -- to dodany przycisk "Straighten" w opcjach Ruler Tool. Teraz przy prostowaniu horyzontu, nie trzeba bedzie po tym odpalac obrotu o dowolny kat, tylko wystarczy wcisnac ten przycisk, a zdjecie obroci sie samodzielnie do poziomu, wg wyrysowanej linii.

Nigdy nie zrozumiem po co się bawić z linijkami, skoro prościej, wygodniej i bardziej wielozadaniowo jest użyć transforma

Jeszcze jedno mnie ucieszylo. Opcje Duplicate, Image Size i Canvas Size, wrocily do menu kontekstowego, pojawiajacego sie po kliknieciu na belce obrazka.

Mówisz że wygodniej jest jechać myszą i klikać niż nacisnąć kombinację klawiszy lewą łapą i tak leżącą cały czas na kibordzie?

Precyzyjne korekty tez wole robic w Shopie, ale mam np. takie kilkadziesiat zdjec z fotoreportazu. Jesli mam zrobic wstepna korekte w ACR, a pozniej wszystkie do korekty lokalnej zapisac do TIFFa i beblac jeszcze w Shopie, a pozniej takie zdublowane zestawy z 15 megowymi TIFFami archiwizowac, to mnie krew zalewa.

Po co wypluwać z ACRa tiffy, skoro można je wrzucić od razu do Szopa, wyedytować bezstratnie i skończyć z NEFem, roboczym PSD/TIFFem oraz (jeśli trzeba) JPGiem.

Pozdrawiam
de Fresz

[Czornyj]

Równie absurdalne byłoby twierdzenie, że zupełnie niepotrzebnie marnowali czas przy optymalizacji CS4 dla Windy, zamiast wziąć się za pisanie nowych ficzersów.
Cocoa wyszła z pierwszymi OS X i od początku było wiadomo, że Carbon jest tylko rozwiązaniem tymczasowym. Przez blisko 10 lat jakoś sami z siebie ci młodzi, zdolni i jakże pracowici programiści z Adobe nie byli w stanie znaleźć wolnej chwilki na optymalizację makowego Szopa (zresztą można ich zrozumieć, był tam totalny burdel w kodzie, który narastał przez wiele lat), że dopiero prztyczek od Jejpla ich do tego zmusił, gdyż ów nie ma ochoty na zabawę a la Winda z pokładami kompatybilności sięgającymi 25 lat wstecz. No i teraz w Adobe będą pewnie mieli spokój na następne z 10 lat.

No właśnie nie bardzo było wiadomo, bo jabol solennie ponoć obiecywał 64 bitowy Carbon, po czym nagle zrobił siupę i wymyślił sobie Cocoę. Z tą chwilką czasu na optymalizację Szopa mógł być problem, bo jest tego 1mln linijek kodu - raczej nie było opcji, by mogli to machnąć poświęcając na ten cel kilka przerw na lunch.
Podobne umilające życie wolty są zresztą specjalnością Appla:
- 68K na PPC
- System 9.x na 10.x
- PPC na MacIntel
- Metroworks na Xcode dla kompilacji
- Carbon na Cocoa dla 64-o bitowego przeliczania

W tym samym czasie "mały-miękki" zafundował koderom przejście z Windows ME na XP i z Visty na Windows 7, przy czym jedna i druga platforma jest obecnie równie wydajna. Z punktu widzenia developera pisanie aplikacji na Maca musi przypominać działalność "Spółdzielni Pracy Daremny Trud".

Po co wypluwać z ACRa tiffy, skoro można je wrzucić od razu do Szopa, wyedytować bezstratnie i skończyć z NEFem, roboczym PSD/TIFFem oraz (jeśli trzeba) JPGiem

Przy hurtowej obróbce kilkuset zdjęć? Mało realne.

[stig]

Mówisz że wygodniej jest jechać myszą i klikać niż nacisnąć kombinację klawiszy lewą łapą i tak leżącą cały czas na kibordzie?

Probowales wcisnac lewa reka skrot Shift+Ctrl+i? Jakkolwiek, nawet jesli masz dlugie i wygimnastykowane palce, szybciej jest jednak wybrac to z menu na belce obrazka (tym bardziej, ze myszke i tak trzymasz juz w lapce). Do Duplicate nie ma skrotu, a dorabiac go specjalnie przy uzyciu 1 czy 2 razy dziennie -- nie ma najmniejszego sensu.

Po co wypluwać z ACRa tiffy, skoro można je wrzucić od razu do Szopa, wyedytować bezstratnie i skończyć z NEFem, roboczym PSD/TIFFem oraz (jeśli trzeba) JPGiem.

Ale po co sobie dokladac plikow, skoro moznaby miec wszystko w NEFie?

[samek]

...Do Duplicate nie ma skrotu, a dorabiac go specjalnie przy uzyciu 1 czy 2 razy dziennie -- nie ma najmniejszego sensu...

Spróbuj CMND J - czy dla całej warstwy czy dla wybranej selekcji.

[stig]

Spróbuj CMND J - czy dla całej warstwy czy dla wybranej selekcji.

Duplicate Image, to jednak zupelnie co innego.

[samek]

Duplicate Image, to jednak zupelnie co innego.

Oj nie doczytałem że chodzi o obrazek. Przepraszam.

[de Fresz]

No właśnie nie bardzo było wiadomo, bo jabol solennie ponoć obiecywał 64 bitowy Carbon, po czym nagle zrobił siupę i wymyślił sobie Cocoę.

Zupełnie nie tak. Od samego początku OS X, czyli gdzieś od roku 2001, było wiadomo, że Carbon to środowisko tymczasowe, mające zapewnić wsteczną kompatybilność ze starymi systemami (karbonowe aplikacje z tamtego czasu mogły chodzić natywnie pod systemami klasycznymi i OS X, jak np Szop 7, Ai10, Indyk 2, Quark 6 itd.), zaś API docelowym, przyszłościowym i preferowanym od początku była Cocoa. Rozwój Carbona trwał tak długo właśnie przez molochy pokroju Adobe czy MS, którym nie chciało się/nie kalkulowało przepisywać swoich aplikacji i tak jechały lata całe na doklejaniu nowego kodu do starej kupki. Ich aplikacje miały nikłe szanse na bycie wydajnymi, ale jak w jakimś segmencie jest się (prawie) monopolistą, to można to zlewać.
Jejpl od lat przekonywał deweloperów, że już czas zakopać tego trupa z szafy i jednak poświęcić trochę czasu na przepisanie i optymalizacje, co mogłoby być tylko korzystne dla użytkowników. No ale prośby to było za mało, więc aby nie wkopać się na amen w związek z niechcianą babą (Carbonem), w 2007 przy okazji premiery 10.5 w pewien sposób utłuczono dalszy rozwój tego API (ciągle jest i ma się dobrze, ale zamrożone na 32-btach).
Carbon 64-bitowy był swego czasu rozwijany, najpierw gdzieś w okolicach G5, później przy Intelach, ale to prowadziło do paranoi podwójnego rozwoju systemowych API nakładających się funkcjonalnością - to musiałoby się mścić na szybkości działania i dopracowaniu systemu.

Z tą chwilką czasu na optymalizację Szopa mógł być problem, bo jest tego 1mln linijek kodu - raczej nie było opcji, by mogli to machnąć poświęcając na ten cel kilka przerw na lunch.

No fakt, lekko licząc 6 lat, to daje tylko jakieś ~1500 przerw na lunch. Mało casu kruca bomba, mało casu.

Podobne umilające życie wolty są zresztą specjalnością Appla:
- 68K na PPC

W 1994. Windzie nie wypominasz przejścia na W95?

- System 9.x na 10.x

Około 2001 r. Nie można w nieskończoność odgrzewać tego samego kotleta, mimo pewnych bóli na początku, dla użytkowników to wyszło na dobre.

- PPC na MacIntel

2006 r. A podziękowania należy słać głównie do IBM & Motorolki, bo to oni zawalili sprawę. W sumie kompatybilność z Windzianym światem też nie jest złą sprawą. No i we wszystkich tych "przewrotach" Jejpl zapewnił zarówno deweloperom, jak i użytkownikom narzędzia tymczasowe, które zapewniały wsteczną kompatybilnośc.

- Metroworks na Xcode dla kompilacji

W dużym stopniu wolny wybór deweloperów. Nie mowiąc tym, że od jakiegoś czasu Xcode jest za fri.

- Carbon na Cocoa dla 64-o bitowego przeliczania

A co, mieli stać w miejscu? Tu przynajmniej wszystko jest w kupie (w jednym systemie, w jednej aplikacji), a nie jak u konkurencji - osobny system, osobna wersja softu.

W tym samym czasie "mały-miękki" zafundował koderom przejście z Windows ME na XP i z Visty na Windows 7, przy czym jedna i druga platforma jest obecnie równie wydajna.

Jeśli pominąć:
- przejście z 16 bitów na hybrydę 16/32 w okolicach 3.11 (jak dłubiemy w prehistorii, to na całego ),
- "prawie jak prawdziwe 32-bity" 95/98/Me, po drodze jazda ze słabo udokumentowaną zmianą standardu driverów
- poboczną rodzinę NT, z której kompatybilnością drzewiej różnie bywało, w tym pierwsze eksperymenty z systemami 64-bitowymi
- XP-ka w 3 wersjach - jednej 32 i dwuch x64 oraz wycięciem DOSa
- Viśtę i jej jazdy z kompatybilnością m.in. dzięki UAC

Z punktu widzenia developera pisanie aplikacji na Maca musi przypominać działalność "Spółdzielni Pracy Daremny Trud".

Jakoś dziwnym trafem największe problemy mają molochy pokroju Adobe czy MS. Niby jakimś tam wytłumaczeniem może być opasłość ich produktów, ale w moim przekonaniu istotniejszym powodem jest zamiłowanie do łatwych pieniędzy - minimum wysiłku i krótkowzroczność. A wydajność? Se juzki kupią szybsze procki, to wyjdzie na to samo. Mimo że na obu platformach wciąż duża część softu nawet nie radzi sobie z pełnym wykorzystaniem tego, co już jest (wielowątowść).

Pozdro
deF