Fotím hodně i do RAWu. Měl jsem možnost vyzkoušet si komerční i nekomerční programy. Pro moje potřeby nadšeného amatéra linuxové alternativy postačí. Nicméně některé úpravy, které souvisejí např. s portrétem se opravdu pohodlněji dělají pomocí komerčních programů. Vyretušování drobností Gimp ještě zvládne, ale složitější úpravy (lokální tonální posun, lokální doostření, úprava pleti) prostě zabírají strašně moc práce. Dle mého profík spíše použije komerční wokení aplikace. Kdysi my jeden profesionální fotograf na workshopu řekl, že pokud si s fotkou musím hrát dýl jak 5minut, tak je lepší ji nafotit znovu a pořádně. Ono když se fotí móda a je těch fotek kolem třístovky tak je důležitá i doba postprodukce.
Hodina produktové, reklamní a architektonické fotografie mě stojí 1.5-15kKč, postprodukce 800Kč - nepočítám svoji odměnu. Na dobrou výslednou fotku počítám 1/2-3hod za kamerou, tak že si občas hraju s postprocesem jednoho záběru i 3 dny. Je fakt, že často v tom hraje hlavní roli HDRI.
Postprodukci dělám pro studia na jejich HW/SW a tedu v APh, sám mám pipeline postavenou na Linuxu s RT jádrem a používám GIMP, LuminanceHDR, Nuke a (dříve víc) CinePaint. Nepociťuji žádná kvalitativní ani funkční omezení. Je pravda, že lehce zvládnu většinu UI.
GIMP je vcelku povedený nástroj a často kritizovaný UI mi vyhovuje. Ten by jen mohl být více konfigurovatelný, aby uživatel mohl odstranit duplicitní ovládání podle vlastní volby a celou aplikaci zpřehlednit. Podotýkám, že starý víceoknový systém mi vyhovoval víc ... snad zvyk z 3d pipeline.
Produkty Adobe jsou mi obecně dost protivné.
http://www.thefoundry.co.uk/products/nuke/
Jinak bych jeste doporucil Autodesk Smoke
http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=15657302
"I když by někdo mohl nabídnout, že je možné užít Wine, je jasné, že se nejedná o plnohodnotné řešení na každodenní systematickou práci."
Proč, pokud je Wine schopné rozchodit Photoshop na 100%? Upřímně, nezkoušel jsem to, mě bohatě stačí GIMP, ale je to asi rok a půl, co Adobe někde tvrdilo, že tedy vyjde vstříc uživatelům na Linuxu a bude Photoshop vyvíjet a testovat tak aby jel plnohodnotně i pod Wine. Jestli se jim to daří, pak je naprosto z hlediska použití tohoto programu jedno, zda jej provozujete pod Linuxem, nebo Widlemi.... (a asi se jim to daří, protože CS5 jede podle Wine AppDB ve zlatě.)
Bohužel Wine AppDB je komunitní aktivita, takže je testování dost pochybné. A když si člověk rozklikne detaily, tak zjistí, že "Gold" aplikace má problémy s během na více monitorech, neběží 64-bitově, GUI se občas nepřekresluje jak má, okna a toolbary se občas otevírají pod aplikací místo nad ní atd. Nemluvě o instalaci, která vyžaduje použití různých workaroundů. A znovu zdůrazňuji, že o komplexnosti testování lze mít oprávněné pochyby. Jestli takhle vypadá Gold aplikace, jak potom vypadají ty ostatní?
http://appdb.winehq.org/objectManager.php?bShowAll=true&bIsQueue=false&bIsRejected=false&sClass=version&sTitle=&sReturnTo=&iId=20158
pochyby lze mít o všem (koneckonců sám kolikrát dokazujete, že i kdyby žádné důvody k nim nebyly, lze je vytvořit uměle) Neznám lepší a spolehlivější testy než praxi :)
Jinak ono u AppDB ani nejde o nějaké komplexní testování a nikdo to netvrdil. Jde o orientační ukazatel jak která aplikace běží, pokud Vám to nestačí co Vám brání provést komplexnější testy? Já vím - Vy šachy nehrajete, ale raději do nich kafráte ;)
Ano, ale spíš mě zajímalo co tím měl na mysly autor - Váš názor je v tomto směru stoprocentně předvídatelný, což v praxi znamená, že vás se ptát nemusím, protože dopředu znám vaši odpověď.
Jinak o Wine a jeho fungování nemám jednak žádné iluze, a myslím si, že s ním mám i dost zkušeností. Jenom jako ilustrativní příklad: http://www.abclinuxu.cz/clanky/zpravodaj-o-vine-2.-5.-2011/diskuse . Zprovoznil jsem pod Wine hodně her i praktických aplikací. Pro sebe i pro druhé, myslím, že opravdu, alespoň tuším o čem Wine je - proto ty šachy - při četbě Vaši odpovědi jsem si vzpomněl na Anděla na horách :-D
Takže nikde nevylučuji, že Gold aplikace mají své problémy. Jak píšu informace v AppDB na WineHQ je víceméně orientační, ale stačí to na to aby si člověk mohl udělat představu. od dob co Adobe přišlo s tím, že bude při vývoji Photoshopu podporovat i Wine, jsem bohužel nečetl žádný seriózní test jak se jim to daří a upřímně mě to i mrzí.
Pokud by takový test dopadl (alespoň) slibně, není problém vytvořit nastavení prefixu Wine na určitou verzi Wine a Photoshopu a to potom šířit jako závislostní balíček. Vím, že některé aplikace jsou takto řešeny, kde dokonce i s bottlí se šíři už rovnou předinstalovaná aplikace. Ale ani to není úplně dokonalé řešení. naráží to třeba na možné problémy s HW a i jiné, vím. Jenomže jak jsem už naznačoval ve shrnutí na Abíčku: Pouze používáním se dá vychytat většina závažných a konfiguračně závislých chyb. hloupé remci o tom jak je to na ho**o ničemu nepomůžou.
Ano, často se vyjádřím, když čtu věci nepravdivé nebo opomíjející důležitá fakta. V tom jsem předvídatelný. A váš komentář "asi se jim to daří" se mi zdál opomíjet ten fakt, že - vašimi slovy - "je to na ho**o".
Pomůžu tím Wine? Ne, to fakt nepomůžu :). Wine je mrtvě narozené. Implementuje jen subset Win32 API, a snaží se co nejkvalitněji implementovat ta API, bez kterých se aplikace neobejde. Zbytek volání API se prostě ignoruje. Fakt čekáte, že nějaká větší aplikace v takovém prostředí poběží opravdu bez problémů?
http://www.winehq.org/winapi_stats
Zajímavé, že se ale spíše vyjadřujete tehdy, když máte možnost si do Opensource a hlavně do Linuxu a věcí kolem něj kopnout. Ona anonymita internetu je krásná věc, že? Nemluvě o to, že jsem se vám tím snažil naznačit, že není potřeba, aby jste se tak okatě vnucoval - zajímal mě hlavně názor autora.
Komentář "asi se jim to daří" rozhodně znamená, že je něco na ho**o, ale dobrý pocit z dobře odvedené práce, už jen vzhledem k tomu, že Wine je projekt už od narození mnohonásobněji živější, než unixové API ve Widlích (které nikdo nechce ani zadarmo). Navíc vzhledem k tomu o jak velkou kompatibilitu s aplikacemi pro různé verze Windows se vývojáři snaží je 52% rozhodně velmi slušný výsledek. Taky jaksi pomíjíte fakt, že z API, které je momentálně implementováno aplikace nutně potřebuje zhruba něco málo přes polovinu. Taktéž jaksi opomíjíte logiku věci. Je jasné, že nejdřív se bude implementovat to co je pro chod Windows aplikací životně důležité a až pak doplňujicí funkčnosti. Osobně bych to ještě roztřídil na ty, které jsou nějak užitečné a vyložené zbytečnosti. Další věcí které opomíjíte jsou problémy a překážky s nimiž se vývojáři Wine musejí vypořádat. Ono Wine urazilo velmi slušný kus cesty a velmi slušný kus cesty má ještě před sebou. Ovšem leskem M$ zlata zaslepenému trollovy to budeme asi těžko vysvětlovat ;)
Z toho je normálnímu člověku jasné, že se najdou aplikace které poběží naprosto bez jakýchkoliv problémů, s problémy a nebo vůbec. ;) Ozanačení Gold v AppDB znamená, že těch problémů při testu běhu aplikace nebyly žádné, nebo jen minimum a nebyly nijak závažné.
UNIXové API ve Windows je prakticky nepoužívané, protože naprosté většině uživatelů nemají UNIXy ohledně aplikací co nabídnout. Zajímavé unixové aplikace jsou většinou portované. Uživatelé Windows nepostrádají kvalitní office, DTP a line of business aplikace, hry atd., na rozdíl od uživatelů Linuxu. Proto typicky neinstalují SFU, nemají dual boot s Linuxem, ani neběží Linux ve virtálním stroji.
Množství verzí Windows nemá s pokrytím API ve Wine nic společného. Protože je Win32 API zpětně kompatibilní, při implementaci API nejnovější verze Windows implementujete zároveň i jeho starší verze. Naopak 52% vnímám po všech těch letech jako dost mizerný výsledek.
Která API konkrétní aplikace "nutně potřebuje"? Kdykoliv aplikace volá *jakékoliv* API, které Wine nenabízí, něco v aplikaci přestává fungovat jak autor zamýšlel. Někdy máte štěstí, a aplikace to možná rozdýchá. Jindy to štěstí nemáte. Z tohoto je jakékoliv chybějící API problém.
Dalším problémem je odlišná implementace. Některé popisované problémy (práce s více monitory, toobary objevující se pod aplikací apod) budou nejspíš výsledkem odlišností, ne nutně chybějících API.
Jistě, aplikace může pod Wine běžet zcela korektně. Pokud se strefí do implementovaných API, a nenarazí na odlišnosti implementace. Bohužel by to zřejmě byly jen malé jednoduché věci typu Notepadu :). Pak jsou aplikace, které neběží korektně, což se projevuje menšími (klidně uživatelem nepozorovanými) problémy, případně většími problémy (v extrému pádem aplikace).
Problémy a překážky vývojářů Wine naopak vidím velmi dobře. Přirovnal bych to ke snaze postavit si v garáži kopii VW Golf. Můžete to být už z 52% hotové, ale nikdy to nebude ono.
WSFU je prakticky nepoužívané, protože naprostá většina uživatelů dá přednost buď přímo nějakému Unixu, nebo Linuxu.
Množství verzí má s pokrytím API sakra hodně společného, protože API je sice zpětně kompatibilní, ale to znamená pouze a jedině to, že program může použít tytéž datové konstrukce a volání jako u předešlých verzích Windows. Ovšem problém je v tom, že API je pouze komunikační rozhraní, tedy deklarace volání funkcí a datových struktur. Samo o sobě je absolutně k ničemu, musí být implementované, a právě implementace API určuje výsledné chování a celkovou kompatibilitu aplikace s různými verzemi OS. A právě implementace se verze od verzi liší (v některých případech až diametrálně).
Další věcí je to, že knihovny ve Vámi odkazovaném linku nejsou jen čistě API WIndows (Win32 API). Např. DirectX, které jsou do seznamu zahrnuty, minimálně do verze 10, byl samostatný produkt se svým vlastním API.
Windows aplikace nutně potřebuje Win32 API. bez něj neotevře ani to pitomé okno. Tedy hlavně kernel32.dll, advapi32.dll a gdi32.dll (nemluvím o původním 16-bitovém API Windows). Všechny jsou už z 90% hotové (implementované) a to pro všechny podporované verze.
Sečteno, podtrženo: 52% z celkově vytyčeného rozsahu je sakra dobrý výsledek. A můžete flusat své jedy jak jen chcete.
No pokud máte dojem, že na Wine, běží korektně pouze aplikace typu notepad, tak vás lituji, protože ukazujete, že s ním moc praktických zkušeností nemáte. Tak např. Zaklínač, TES IV, Need for Speed (a - nejen - u mě jedou naprosto bez problémů...)jsou aplikace typu notepad? Aha, tak to jsem fakt netušil... :-D
obavám se, že nemáte naprosto potuchy ani o tom jak Wine funguje v praxi, natož aby jste viděl nějaké problémy a překážky s nimiž se musejí potýkat vývojáři Wine. A nebo záměrně lžete.
Nějak jsem si nevšiml, že by naprostá většina uživatelů dala přednost UNIXu nebo Linuxu. Čísla tvrdí, že dávají přednost Windows a běhu aplikací pro Windows.
Implementace API se pochopitelně v různých verzích Windows liší - v novějších toho často dané API umí víc. Ale to nic nemění na faktu, že stačí implementovat API poslední verze Windows, a s tím máte implementované i API všech předchozích verzí. Existují výjimky, ale je jich minimum.
Někomu stačí 52% API a nevadí mu dlouhá řada problémů; jiní to považují za nedostatečné. Chápu, že když nemáte dost aplikací pro Linux, je potřeba nějak běžet aplikace z Windows. To znamená dual boot, virtuální stroj s Windows, nebo Wine. Wine je nejkomfortnější, pokud ale funguje. Uživatelé Linuxu jsou zvyklí vystačit s málem, tak si to užívejte.
Fakt myslíte, že ty "korektně" běžící aplikace nepoužívají API, které Wine neimplementuje? Nejspíš ho používají. Pokud aplikace přesto funguje, je to spíš happy accident, než výsledek systémového přístupu.
S Wine jsem krátce experimentoval, a byl jsem znechucený. Ve Windows spustím setup, klik, klik, a je hotovo. Ve Wine můžu na setup ve většině případů zapomenout. Spolehlivější je provést instalaci do Windows, nakopírovat aplikaci do Wine, a pak experimentovat, nastavovat, v případě her použít no-CD crack, a hlavně hodně doufat. Na konci je po spoustě úsilí ve většině případů skoro-funkční aplikace, co má mouchy, které ve Windows prostě nejsou (rozpadající se zobrazení, nefunkční features, někdy padání). Děkuji, polotovary neberu.
Vy jste si nevšiml více věcí. Například té, že v minulých příspěvcích nebyla porovnávána používanost Windows a Unixu/Linuxu, ale WSFU a Unixu/Linuxu.
Jinak neustálé nabalování nových funkcí na stávající kód asi nebude jediný model vývoje, který MS používá, i když bych byl ochoten tomu i věřit - pak nezbývá než jen politovat uživatele, ať si ty tuny mrtvého kódu a backdooru ve zdraví užijou ;) Navíc od NT 4.0 v tom musí být takový marast, že se v tom ani prase nevyzná. Je však zajímavé jak zarytě jste oponoval, když jsem někde napsal, že zpětná kompatibilita stojí uživatele spoustu zbytečného kódu navíc, který využijí možná někdy a možná taky nikdy - a teď tomu sám nahráváte. Asi v tom nemáte sám moc jasno, nebo plácáte co se vám momentálně hodí.
Ať tak či tak, každá změna v API, nebo jeho implementaci vede k odlišnostem v jeho chování. V celku jako jsou Windows se tyhle odlišnosti neprojevují nutně jako havarijní chyby, buď proto, že byly plánovány a zapadají do sebe jak ozubená kolečka; a nebo se ztratí ve zbytku nedostatků (jakých ve Widlích není zas až tak málo). A když je to moc velkej problém, tak se uživatelům nakecá, že nejde o chybu, ale feature - volů, kteří to sežerou i s navijákem se najde vždycky více než dost. Jiná situace však nastává, když se někdo snaží napsat toto API sám, bez řádných informací o jeho implementaci, se potom taková změna může projevit pádem, nebo nekorektním chováním aplikace, která dané API využívá. Bohužel, nebohý vývojář si neplatí žádné PR flamery a fabulátory, takže to koupí rovnou z první ruky.
Velmi zajímavá je vaše až patologická potřeba se vyjadřovat za nás, linuxáře, a všem vnucovat VAŠI VERZI našich názorů a postojů. Ono je to ale jinak... Nespokojíme se z kde jakým šmejdstvem, který vyprodukují v Redmontu, taky se nespokojíme s pindáním podobných ophirů, kteří do omrzení budou vykládat našprtané kydy o tom jak jsou Widle úžasné a světoborné a jak bez toho nikdo nemůže žít. My můžeme. Navíc si rádi vybereme to co vyhovuje nám, a ne to co nám nějaký přechytralý panák naservíruje až pod nos, nejlépe tak, aby nebylo vidět nic dalšího. A věřte, že já mám jen v základní instalaci takový výběr, o jakým se uživatelům Windows nezdá ani po letech. A není to o tom, že by nic lepšího než widlařům předhodíte nebylo, jen si to nechají nabulíkovat - jako ovce, jdoucí za mečením berana. Aplikace pro Linux jsou a jsou jich mraky. Od méně po ty velmi kvalitní. Ano, existují i aplikace které na Linuxu nemají ekvivalent, nebo jsou psány prostě pouze jen pro jednu platformu (Windows her, PC Translator, ...) a Wine nám umožňuje si ten výběr ještě podstatně rozšířit i o tyto kousky. Také umožňuje některým firmám jednoduše, poměrně snadno a s malými náklady své produkty rozšířit i na další platformu. Tolik k známému a už dávno pasé FUDU, že na Linuxu nejsou aplikace a Linuxářům stačí málo. Ono IMHO stačí porovnat Servery s aplikacemi pro Windows a instalační média Debianu a hned je jasné kde asi je podstatně menší výběr a komu stačí fakt málo ;)
IMHO je úplně jedno, jestli aplikace používají neimplementované části API, nebo ne, pokud běží bez problému, tak jak mají. Může se jednat o zázrak, skvěle odvedenou práci vývojářů dané aplikace (tím líp), nebo to taky znamená, že dané funkčnosti API jsou nepodstatné. Pokud však aplikace problémy mají, buďte si jist, že se tomu někdo dřív nebo později bude věnovat. Podle priorit, důležitosti/závažnosti a všeobecného zájmu. Linuxový přirozený výběr funguje skvěle i zde.
LOOOOL !!!! :-D :-D No, nejsem si jist, jestli se tak nepostupovalo při instalaci win aplikací někdy v dřevních dobách Wine (verze 0.0.1 - 0.3.x), já si akorát pamatuji, že bylo potřeba jistou dobu od začátku nainstalovány Windows, a konfigurace se prováděla přes globální soubor v /etc. Mám ten dojem, že někdy na přelomu verze 0.8 / 0.9 i tato potřeba odpadla a konfigurace se plně přesunula do wineregistrů. Ale jste první, od koho čtu takhle složitý postup a ani se teď nedivým, že vám to moc nefungovalo a byl jste tím znechucen :-D kopíroval jste i záznamy z registrů? a co registrace knihoven a mimetypů? Taky? :-D Jinak, co k tomu říkají sami autoři : http://wiki.winehq.org/FAQ#head-497f1a295d53dd3444f211df2b13312c7767afa2
Buďte ubezpečen, že všecho instaluji přímo v Linuxu a s pomocí programu setup - a jak vidíte, funguje mi to dokonale. Zkuste to také : wine setup.exe click, click a je to hotovo:) A pokud se nechcete párat s CLI, máte na výběr i GUI nástroje pro pohodlnější práci s Wine. Spousta lidí spokojeně používá PlayOnLinux, já mám však alergii na hady, takže spíše doporučuji Q4Wine. poohlédnout se můžete i po CrossOver, nebo zkusit projekt Cedega. V Linuxu platí, že vždy máte na výběr ;)
Při vývoji Windows se nepoužívá extrémní programování (aka bordel), ale promyšlený návrh.
"každá změna v API, nebo jeho implementaci vede k odlišnostem v jeho chování" - to není pravda. Vezměme si jako příklad funkci CreateFile(). Ta používá parametr dwFlagsAndAttributes. Od jisté verze Windows je možné nastavit flag FILE_FLAG_SEQUENTIAL_SCAN, který napoví cache manageru, jak se nejspíš bude soubor číst. Jakou odlišnost v chování aplikace taková změna API podle vás přinese? A jaký mrtvý kód ten nový flag podle vás v OS zanechá? Odpověď: žádná změna chování pro staré aplikace, žádný mrtvý kód. A tak je to s naprostou většinou změn.
Nevyjadřuji se vás. Popisuji svůj pohled na věc, a podkládám ten pohled fakty.
Aplikace pro Linux jsou. Je jich málo, a v řadě oborů chybí aplikace na úrovni kvality běžné ve Windows. Nakonec právě proto naprostá většina uživatelů Linuxu běží v dual bootu, a/nebo má virtuální stroj s Windows, a/nebo používá Wine. Může se vám to nelíbit, ale tak to je.
Pokud aplikace mají problémy: jak se můžete dočíst už v testech těch "Gold" aplikací na webu Wine, problémy jsou. Že vás ty problémy netrápí? Jak jsem psal, uživatelé Linuxu se spokojí s málem.
Instalační média Debianu obsahují nekomerční opis UNIXu, a něco co by se dalo srovnat s výtahem z archivu freewaru na Tucows (hromady "praktických" utilit, a dokonce sem tam něco opravdu použitelného). MS ale měl oplétačky, i když si dovolil tak "hroznou" věc, jako přibalit k OS přehrávač multimédií, a stálo ho to stovky milionů EUR. Poděkujte EK :)
Vám možná setupy procházejí; když jsem to zkoušel já, instalace často nedoběhla, nebo potom aplikace nešla spustit, nebo se za běhu vyskytovaly problémy, které rozhodně nebylo možné přehlédnout.
Ano, v Linuxu máte vždycky na výběr ze dvaceti možností. Nejprve je důkladně prostudujete, abyste zjistil, že ani jedna z nich není na úrovni slušného komerčního SW. A po instalaci zjistíte, že ty jsou ty aplikace o řád horší, než byste si coby uživatel komerčního SW představil ve špatném snu. Nakonec skončíte se sadou 4-8 aplikací, které dohromady udělají s hromadou chyb horko těžko 80% toho, co zvládne jeden slušný komerční SW. A k tomu řešíte problémy typu nefunkční zvukovky, špatné detekce video karty, z neznámého důvodu nesmírně mizerného výkonu HDD, zamrzání stroje, problémů s uspáváním (resp. častěji s probouzením), vysokou spotřebou, a patláte se s rozhraním, které snad nezkoušeli používat ani jeho autoři. Problémy na Linuxu nejsou výjimkou, ale životním stylem uživatele. Tak to vypadá z mého pohledu.
http://jank.blog.root.cz/2011/09/18/quo-vadis-linux/
Photoshop som vo Wine rozbehol uplne bez problemov, ale starsiu verziu 7 :) Problem s novym bol ten, ze ked chcel validovat SW online, tak ma nepustilo.. Vlastne podobne s dalsimi, ktore potrebovali byt online pri prvom spusteni.. Mozno bolo len potreba otvorit nejaku cestu, ale to som moc neskusal, ked mi siel aspon ten starsi..
Všechny články jsem víceméně přečetl, něco i otestoval, možná by se i něco použít dalo, ale! Kde je zmínka o kalibraci monitoru??? To je totiž achilova pata práce s fotkama v Linuxu - u stolního LCD ještě něco naklikám, ale co na noťasu? Pči každém povýšení systému kouknu na kartu s nastavením monitoru a zakroutím hlavou, pořád nic... i když uznávám, nastavit rozlišení jde. Trochu mi ale chybí barevné profily, teplota barev, kontrast, barevné kanály, gama, ...
Takže na otázku v nadpisu: NENÍ! pokud to tedy myslíte aspoň trochu vážně...
Pokud vím, tak kalibrace monitoru se provádí pomocí speciálních obrazců, které by měli být ke stažení na stránkách výrobců gr. karet.
Co se týče teploty barev, kontrastu, gammy - /etc/x11/xorg.conf, nebo některý z konfiguračních dialogů Desktopů KDE/Gnome.
Přizném se, že barevné profily jsem ještě neřešil, takže netuším, ale domnívám se, že Xorg by teoreticky pro to něco mohl mít....
Kalibrace a barevné profily jsou trochu složitější, ale ne zase tak moc aby to člověk nezvládl. Kdysi jsem k tomu napsal několik málo článků ... Zjednodušené, ale pochopitelné i pro laika ...
http://nikonclub.cz/sprava-barev-pri-zpracovani-fotografie
http://nikonclub.cz/blog/kalibrace-pomoci-colormunki-photo
http://nikonclub.cz/kalibracni-sonda-spyder3pro
... nebo doporučuji Romana Pihana ...
http://www.fotografovani.cz/art/fozak_df/rom_color1.html
... atd.
Pěkné články. Nicméně je třeba si uvědomit, že čtenáři tohoto serveru mají poněkud jiné standardy. Pro ilustraci se podívejte třeba na tenhle seriál o úpravách fotek v Gimpu:
http://www.root.cz/clanky/snizeni-hloubky-ostrosti-v-gimpu/
http://www.root.cz/clanky/oprava-cervenych-oci-v-gimpu/
http://www.root.cz/clanky/vyvazeni-barev-v-gimpu/
Speciální obrazce nejsou potřeba, záleží na použití: u kalibrace pro tisk je potřeba kalibrační foto z tiskárny/minilabu + data pro monitor.
Kontrast se pak třeba nastavuje pomocí rastru (porovnání rastru s okolím).
Pro kalibraci v Linuxu jsem našel tady pár zajímavostí:
http://linuxtidbits.wordpress.com/2008/03/10/linux-design-calibrate-the-display/
Dost mě děsí, že drtivá většina návodů pro xorg je sada příkazů do terminálu! Podle mě by logicky mělo být nastavení výstupu na monitor součástí ovladačů grafiky, tak jak je to třeba u Catalyst - a hlavně by to mělo být graficky! Možná je něco efektivnější dělat pomocí příkazů, ale ukažte mi, kdo v Linuxu upravuje fotky v terminálu??
Jednoduše řečeno mi nejvíc u noťasu chybí OSD jako u stolních LCD, pro tyto případy by to mělo být natvrdo zadrátováno do všech ovladačů ve všech distrech, proč z něčeho tak základního dělat detektivku pro uživatele...
Podpora pro barevné profily na Linuxu je poměrně dobrá. Nejen, že je většina grafických aplikací podporuje přímo, ale existují i řešení pro celý desktop využívající akcelerace pomocí GPU — compicc, compiz-cms.
Takže zatímco ve Windows mám na wide‐gamut monitoru na spoustě míst (vč. třeba plochy) barvy úplně mimo, na Linuxu je to téměř bez problémů. Jen by to chtělo do grafických aplikací dodělat tu podporu pro net‐color (resp. libXcm).
Aha, problém se týká monitoru s více než 8 bity na kanál. Color management ve Windows XP uměl jen 8 bitů na kanál, s ICC profily (tj target sRGB, aRGB, nebo cokoliv podle kalibrace monitoru). HDR umí až Vista a Win7, ale podle dokumentace jen pro WCS-enabled aplikace (na WinHEC 2008 tvrdili, že jen ve full screen mode). Žádné takové zařízení jsem ale na stole neměl, takže neznám související praktické problémy. Předpokládal bych, že monitor umí rozlišit 24- a 30/36/48-bitový signál, a správně to ošetří.
HDR desktop bude, ale zřejmě díky WCS-enabled shellu.
To co popisujete vypadá jako problém všech non-WSC aplikací s HDR monitory (resp. se signálem pro monitor s více než 8 bity na kanál). Pokud máte monitor s 8 bity na kanál, problém se nekoná.
Otázkou je situace ve Win7. Ta odpověď na answers.microsoft.com byla psaná ještě před finalizací Win7.
Zkusil bych 1. použít Windows 7 s wide gamut monitorem, správnými profily pro zařízení i viewing conditions (proti Vistě jsou tam změny). 2. Pokud to pořád nejde, přepnout všechno do 8 bitů na kanál (včetně monitoru - mělo by to být někde v OSD) a použít 8-bit profily. Jo a 0. nepoužívat Adobe Gamma Loader, nastavení barev v driveru grafické karty apod.
Mám monitor s 8 bity na kanál a problém se koná (alespoň ve Windows Vista, Windows 7 tu momentálně nemám, tak to nemůžu vyzkoušet). Monitor žádné OSD nemá, jediné, co jde nastavit, je jas.
Podle mne ale nejde ani tak o to, kolik těch bitů je, ale jak je to interpretuje. Ten monitor má nějaký vlastní barevný prostor (odlišný od sRGB), takže např. pokud mu grafická karta pošle <0, 255, 0>, tak to nezobrazí jako sRGB zelenou, ale jako nějakou mnohem zelenější zelenou.
Aby ty barvy nebyly přesaturované, tak je potřeba provést transformaci gamutu, kterou podle mne ale Windows Vista (a domnívám se, že ani Windows 7) automaticky nedělají. Jediné, co automaticky dělají, je ta transformace gama křivky, to je něco, co grafické karty umí už delší dobu, a není kvůli tomu potřeba používat žádné textury, shadery apod. Akorát Windows XP to myslím neuměly nastavit automaticky (ale v API na to funkce byla), takže bylo potřeba používat různé ty gamma loadery.
"chybí mu lehkost, rychlost a kvalita."
Typický FUD. GIMP používám už hodně dlouho (ano, občas i na editaci fotek), rychlost a kvalita mu rozhodně nechybí, a pod "lehkostí" si nedovedu nic představit. Můj soukromý dojem je, že autor buďto jen bezmyšlenkovitě opakuje co stejně bezmyšlenkovitě opakují jiní, nebo v lepším případě pod chybějící "lehkostí" rozumí "nevypadá to přesně jako Photoshop".
Chápu že GIMP má rezervy v oblasti pre-press (není možno přímo pracovat v CMYK), ale zrovna pro fotky a web je myslím výborný.
Ale neposlouchejte mě, já patřím k těm podivínům, co se jim víc líbilo původní víceokenní rozhraní GIMPu než to nové jednookenní.
-Yenya, http://www.fi.muni.cz/~kas/blog/
Samozřejmě CMYK je jeden problém. Další problém je HDR, tedy 16 či více bitů na kanál. A největším neštěstím Gimpu byl vždycky interface. Uživatelé Linuxu jsou řekněme poněkud nenároční, ale profesionálové se Gimpu odjakživa vyhýbají právě díky jeho UI. Po vyzkoušení (pravda před pár lety) se jim vůbec nedivím.
Jenže ono je toho pro profesionální práci potřeba *o hodně* více. Já mám kupříkladu GIMP rád a dělalo by se mi s ním dobře. Ale po krátkém zamyšlení člověk zjistí, že těch "pár drobností", které pro alespoň základní práci fotografa chybí, se v dohledné době nemá šanci zlepšit. Nejsou to totiž drobnosti a každá z nich je v náročnosti, řekněme, srovnatelná s celým GIMPem. Např. barevná hloubka, práce s barevnými prostory, práce s výběry, práce se vzorky...
No a takových věcí je v Linuxu více. Priority jsou IMHO jinde než v profesionální práci (ať už fotografické jiné).
pracuju s gimpem na linuxu fotim profi zpracovavam fotografie a nemam jediny problem jak s funkcionalitou tak s multiokenim rezimem. naopak by mi vadilo kdyby byl pouze rezim jednoho okna. mam dva monitory presto chci videt co se mi deje i "pod" gimpem a je to pro me jasna vyhoda (ve win se s tim pracuje hure ale to je problem win ne gimpu.) jinak co se tyka sonackyho ARW pod wine slape bez problemu ten sonackej SW na jeho zpracovani.
profesionál hodnotí 1. funkci včetně výkonu a kvality 2. poměr výkon cena a pak možná jestli je mu to sympatické. Dělám na 3D modelačním SW s bláznivým nekoncepčním a neintuitivnim popiskovým interfacem, který má jen jedno undo a to jen v rámci aktuálního nástroje, je neuvěřitelně drahý a zabugovaný, ale v oboru je to pro svůj výkon zatím nepřekonatelný standard.
Já už s GIMPem pracuji výhradně tak ?6? let (zbavil jsem se všech nakradených sw), ale doteď vzpomínám "s láskou" na starý PS 6.0, Kdyby Adobe prodávalo starší verze za rozumné peníze, tak si o GIMP "neopřu ani kolo". Bohužel to samé je i s jinými nástroji, např. RawTherapee mi přišlo celkem dobré, než jsem si zkusil Lightroom. To co v něm udělám za minutu v RT vůbec nejde (např. odšumování i na max skoro nic neodstraní, LR stačí +-25% a fotka je krásně vyčištěná). O rychlosti vůbec nemluvím, v RT často trvá operace po změně hodnoty 5s (všechny 4 jádra na 100%, program nereaguje), v LR většinou jde hýbat jezdci a výsledek se interaktivně mění. O kvalitě výstupu nemluvě. Ne že bych chtěl nadávat, jsem rád, že ty free alternativy jsou, protože na komerční nemám, ale pokud mám koukat na "lehkost/rychlost/kvalita", tzn. bez ohledu na cenu, jsou komerční aplikace (v tomto případě od Adobe) úplně někde jinde.
>> O rychlosti vůbec nemluvím, v RT často trvá operace po změně hodnoty 5s (všechny 4 jádra na 100%, program nereaguje)
Jaka operace? Od nejake 3.0 alpha neni s rychlosti problem, u 2.4.1 byl, ale jenom proto, ze se muselo rucne nastavit, aby se neprepocitaval obraz v meritku 1:1, ale jenom treba 1:5.
>> (všechny 4 jádra na 100%, program nereaguje), v LR většinou jde hýbat jezdci a výsledek se interaktivně mění.
Divne, v mem RT, opet od 3.0 alpha, moje vsechna 4 jadra zvladaji bez problemu a vysledek se interaktivne meni stejne jako v tvem LR...
Jenom jestli Petre trochu nekecas ;)
Tak mi to nedalo a zkusil jsem (mám RT 3.0.0 final + jsem zkoušel i 2 verze z řady 4.0.0 (4.0.0.2 a 4.0.1.něco tuším). Už asi vím, zapnul jsem při 1:1 (doostření vlasů atd nemohu kontrolovat na 33%) expozice/stíny světla/vysoká kvalita a poté posunul obraz. 10Mpix RAW z Olympusu (.ORF), i5-760, 4GB RAM, 64bit verze na 64bit W7, porovnáváno proti LR 3.4.1. Možná se té pomalosti dá dosáhnout i pomocí jiných voleb, jedu teď na zkušební verzi toho LR a zatím nevím, do čeho půjdu, až mi vyprší. Jak jsem psal, u RT se mi někdy (např. tmavší roh zdi v místnosti) vůbec nepovedlo odšumit ani na 100% jasu i barvy, v LR už na 25% byl roh krásně čistý bez toho, aby to začalo ničit detaily. I další činnosti se mi v LR dařily lehčeji s lepším výsledkem. Naopak u RT se mi líbí, že vytváří jednotlivé soubory úprav, LR to ukládá do databáze, tj. trochu rozdíl jako txt konfiguráky a binary registry blob. Trochu to kazí fakt, že když jsem RAW upravený v 3.0.0 načetl do 4.0.0, tak byl barevně atd úplně jiný, vím, je to dev verze, ale i tak mě ten velký rozdíl překvapil a jsem zvědav, jestli se to srovná (jinak bude přechod na 4.x dost problém, když rozhodí úpravy u starších fotek).
Tady bohužel Gimp zhaním, protože taková pitomost jako jsou snadné ořezy a změny velikosti (ať už vrstvy, či celého plátna), je fakt právo útrpné (a ani Pinta není stále o moc lepší). Ty stávající dialogy jsou použitelné jen do omezené míry, chtělo by to na řezání něco, jako má M$ Office Picture Manager či blbé Malování. A to je věc, která se s takovými nástroji páchá na fotkách nejčastěji.
Takze na vsetky kecy o 16 bit a nepouzitelnosti pre profi retus/ farby/ boh vie co este vsetko mozne, je napriklad jedna odpoved - cinepaint. Vyrobene v ILM a pouzivane kopu rokov, dokonca volne k stiahnutiu.
Inak samozrejme gimp - jedine stara verzia s viacerimi oknami , pokial niekto podstatne nezmenil orezavanie tak nechapem prispevku ze v gimpe to nejde....
IM umí spoustu z uvedeného a např. na úpravu v GIMPu ořezaných fotografií pro web (aby se vešly do 400x600, např., na výšku nebo na šířku, tvorbu náhledových obrázků apod. - jedním příkazem pro obsah celého adresáře - i více) nic jiného rozumně použitelného neexistuje. Umí i řadu zásahů do samotného obrázku (pochopitelně, neinteraktivně), které v některých případech (např. doostřování) vypadají (alespoň pro mě subjektivně) líp, než co vyleze z GIMPovských filtrů.
Na druhou stranu uznávám, že syntaxi má naprosto šílenou a navíc blbě zdokumentovanou (včetně oficiální dokumentace).
Tak si říkám, proč vlastně upravovat fotky? Abychom zkreslovali realitu a dělali věci hezčí, než jsou? Abychom zamaskovali to, že neumíme používat fotoaparát ... zlaté časy, kdy se něco vyfotilo, vyvolalo a to bylo všechno ... maximálně se zvětšilo a zmenšilo .... Dnes každý upravuje :-D ... Není však lepší vylepšovat svět reálně, než si ho zkreslovat virtuálně?
O tomhle se vedou diskuse už někdy od časů pánů Nipeceho, Daguerra a Talbota, protože už jejich procesy nějakým způsobem pozměňovaly realitu. Za časů analogové fotografie bylo naprosto běžné ovlivnění tvorby negativu vyvoláváním nebo pozitivu výběrem papíru a vývojky a "nadržováním" při expozici papíru pod zvětšovákem. O různých typech speciálních procesů, montážích apod. nemluvě.
Navíc: Kde byste hledal a jakou realitu třeba na fotografiích Jana Saudka? I velmi realistické a s minimálními zásahy do procesu vyvolávání fotografie pana Sudka jsou spíš ozvěnou reality než realita sama (viz např. "Moje zahrádka", "Skleněné labyrinty" atd.).
Dnes se pouze těžiště zásahů do finálního obrazu přesunulo z oblasti snímání do postprocesingu. Svým způsobem je to plus, protože původní snímek nemusí přitom být zničen a současně nedochází ke ztrátě kvality, ke které docházelo v analogové fotografii vždy při vytváření jakékoli záložní kopie.
Možná se na frekvenci úprav digitálních fotografií podepisuje i to, že df dává zatím technicky méně kvalitní snímky než analogová (např. snímky žárovkového světla ve sklepě, na nichž jsou vidět podrobnosti na osvětlených zdech a současně i vlákno žárovky - P. Koblic jimi v jedné ze svých knížek demonstruje možnosti speciálních metolových vývojek) jsou digitálně (kvůli technickým omezením čipu) nedosažitelné bez zkomponování speciálním softem alespoň tří dílčích obrázků s různou expoziční korekcí do jednoho.
Navíc úpravy fotografií, tedy něco nad úroveň syrového snímku, který vylezl z fotoaparátu, se staly až nyní pro řadu lidí vůbec možné, protože experimentovat doma s něčím podobným v analogové barevné fotografii - to bylo jednak hodně peněz za zkažený materiál a jednak hodně času (mezi expozicí papíru a jeho ustálením do podoby, kdy už se s ním mohlo na denní světlo, uplynula skoro půlhodina), to samé v GIMPu je záležitost pár sekund a ještě si někteří "rozežraní" stěžují. Současně je to prakticky jen za cenu proudu, co spotřebuje počítač když běží.
Díky za tak rozsáhlou odpověď, dobře se to četlo. S1amozřejmě vím, že úpravy fotografií je strašně stará záležitost. Můj povzdech byl spíše tím směrem, jestli je dobré, aby se tyto nástroje dostali do rukou běžných uživatelů, kteří dříve maximálně zvětšily a vyvolali snímek. Dnes se snaží aby rodinný snímek vypadal jak z časopisu. A když jsme u těch úprav, co takový filmový pás? Když si vzpomenu na Falešnou hru s Králíkem Rogerem, tak tam smekám, ale to už jsou mistrovská díla ;-)