GIMP ve stylu Photoshopu (diskuse)

[gsnak]

Priliz malo miesta na vrstvy

[Attila]

Asi by sa to dalo vyriešiť potiahnutím kategórií položiek v ľavom panely do spodného okna

[Kleofasz Kutya]

"priliz" je od slovesa lízať?

[reb]

Doufám, že někdo brzy opraví tu úchylárnu se Save/Export.

[Max]

Také mně to silně irituje.
Zdar Max

[kyekros]

+1

[Zohan]

Allahu chraň. Tak jak je to teď to alespoň dává smysl.

[xkucf03]

+1, má to svoji logiku

[Pavel Čejka]

Logiku možná, praktičnost ani omylem. Předchozí stav mi vyhovoval mnohem lépe.

[ikar]

+1

[Jarek]

+1

[Heron]

Dávalo by to smysl, kdyby celkové workflow Gimpu bylo úplně jiné. V tomto případě to pouze přidává práci.

[Kvakor]

Mně osobně to zas tak úchylné nepřijde, rozumím důvodům, které k tomu autoři měli, i když provedení považuju za trochu matoucí a inkonsistentní, například Save for Web... by mělo být spíš Export for Web... a smysl samostatného Save a Copy... mi uniká, protože ho plně nahradí Save As... (i když možná je to jen tím, že jsem ještě nedosáhl stejného osvícení jako autoři ). V praxi mi to ale nijak nevadí, protože za běžných okolností mi stačí jen Save a Save for Web... hotového výsledku. Mimo toho, viděl jsem programy, které byly z mojeho pohledu mnohem, mnohem úchylnější

[xkucf03]

a smysl samostatného Save a Copy... mi uniká, protože ho plně nahradí Save As...

To právě ne. Save a Copy znamená, že uložíš kopii, ale v okně Gimpu máš otevřený stále ten původní soubor – takže další editace a ukládání půjdou do něj. Zatímco u Save As pokračuješ v editaci pod novým názvem.

[Punny]

+1

[jehovista]

+100 Se vzdycky naseru, kdyz minutu hledam misto kam to ulozit a pak zjistim, ze jsem misto na export kliknul na save.

[xkucf03]

Pořád je lepší přijít o minutu než přijít o hodiny práce, když si uložíš obrázek v nějakém ne-plnohodnotném (pouze exportním) formátu.

[pta]

+ 101

[little.owl]

+1

[mikirc]

Pokud vim, jak pri exportu do jakehokoliv formatu to vzdy rve jeste s nejakym dodatecnym nastavenim exportu, takze pokud clovek neignoruje co mu program hlasi tak nevidim problem.

[potato]

Dodatečné nastavení to chce pouze při prvním exportu. Volba File, Overwite foo.png (jpeg, etc., do čehokoli to bylo exportováno předtím) by měla prostě provést export do stejného souboru se stejným nastavením. Podle stylu práce toho může někdo chtít jako default, nebo nemusí. V prvním případě je zapotřebí nastavit klávesové zkratky, aby to nebyla zbytečná pruda...

[Pavel Čejka]

Hloupost. Stačí, kdyby Gimp upozornil, že se neuloží vrstvy (etc ... další fíčury), pokud nějaké v editovaném obrázku existují a zvolím jiný formát než XCF.

Dost často otevřu v Gimpu JPG/PNG, udělám drobnou úpravu (ořez, změnu barevné hlouby ... cokoli co není specialitou XCF), exportuji (jako by to nemohlo být postaru) a chci zavřít, načež Gimp řve, že není uloženo. Pokud takových obrázků zpracovávám víc, tak se tu a tam musím přesvědčit mimo Gimp, že uloženo bylo i se změnami a otravnou hlášku ignorovat ...

Já chápu, jakou logiku asi programátoři zamýšleli a to smysl dává, ale provedení záměru ve skutečnosti komplikuje práci.

[klingger]

+1

[xkucf03]

Stačí, kdyby Gimp upozornil, že se neuloží vrstvy

Dost často otevřu v Gimpu JPG/PNG, udělám drobnou úpravu (ořez, změnu barevné hlouby ... cokoli co není specialitou XCF), exportuji (jako by to nemohlo být postaru) a chci zavřít, načež Gimp řve, že není uloženo.

Zrovna tenhle případ užití:

1. otevřu JPEG v Gimpu
2. oříznu nebo udělám další drobné změny
3. dám Overwrite původní.jpeg
4. zavřu Gimp a zobrazí se mi varování, že bych mohl přijít o některé informace

Alternativně by to mohlo vypadat takhle:

1. otevřu JPEG v Gimpu
2. oříznu nebo udělám další drobné změny
3. dám Save a zobrazí se mi varování, že bych mohl přijít o některé informace
4. zavřu Gimp (a už se žádné varování nezobrazuje)

Někde tam to upozornění ale být musí, jinak by uživatel mohl přijít o data a to by ho sakra mrzelo – mnohem víc, než že musí odkliknout nějaký dialog.

Možná by tam mohla být funkce „Přepsat a zavřít“ – ale je to poměrně nebezpečné. Bylo by lepší, aby byla ve výchozím nastavení skrytá a pokročilý/informovaný uživatel si ji mohl v konfiguraci zapnout (lepší než se dívat na zástupy nespokojených uživatelů, kteří nadávají, jak jim ten zlý Gimp ztratil data).

[Pavel Čejka]

... a to varování, že přijdu o informace by se mělo zobrazovat jen tehdy, pokud o nějaké mohu přijít.

Sekvence příkazů zpět, nebo označená oblast pro mne nejsou významné informace, přidaná vrstva (resp. existence dalších vrstev) rozhodně ano. Tím chci říct, že by uživatel neměl být obtěžován zbytečnou hláškou, protože to otupuje jeho pozornost, příště na ní možná bude kašlat a kliká bez rozmyslu. A pokud si programátor ušetří práci a zobrazí varování pokaždé, místo aby poctivě řešil, jestli změna nastala, nebo ne, tak to je špatně.

Hodně uživatelů je zvyklých na CTRL+S (nebo CTRL+SHIFT+S, pak je na místě dotaz overwrite?), nebo nějaký ekvivalent. Málokdo čeká, že bude program bránit v uložení PNG, když v něm PNG otevřel.

Neprotestuju proti existenci funkce Export (ostatně viz MyPaint, Inkscape ...). Ta má určitě smysl, když otevřu XCF, upravím, exportuji bitmapu a zas XCF uložím. Ale určitě nemá smysl, když otevřu JPG/PNG a chci uložit JPG/PNG, to by měl Gimp rozlišovat a původ souboru si po dobu práce s ním pamatovat. Programátoři si prostě ušetřili práci a vytvořili paskvil.

[xkucf03]

V MyPaintu si zase vývojáři ušetřili práci opačným směrem – otevřu JPEG, přidám vrstvu, do ní něco nakreslím, dám Ctrl+S, zavřu – vše bez jediného varování, ale přišel jsem o data – mám obrázek zmršený několikanásobnou ztrátovou kompresí a všechny vrstvy splácnuté do jedné.

Krita se chová stejně, akorát po stisku Ctrl+S zobrazí dialog, kde můžu nastavit kompresi. Ale opět přijdu o případné vrstvy a další informace – a to bez varování.

S rozpoznáváním operací, které lze v tichosti zahodit a které už ne, si v těchto programech zatím nikdo práci nedal. Ono to úplně triviální není… Třeba jednou někdo takový patch pošle, ale do té doby mi přijde lepší zobrazit ten dialog „navíc“ než uživateli ztrácet data.

[xkucf03]

Maximálně by se dalo uvažovat o spojení Save a Copy a Export. Ale pokud by se to pak jmenovalo Save a Copy, tak by bylo nelogické, že v Save a Copy máš na výběr jinou množinu formátů než u Save (As)

Ale u samotného Save nebo Save As uživatel přece předpokládá, že si uloží plnohodnotný soubor včetně vrstev a všeho a může pokračovat v editaci. Jak by se podle tebe měl editor chovat, kdybych dal Save As např. GIF? Měla by se osekat barevná hloubka a měla by mi z editoru zmizet většina tlačítek, protože jejich použití pak nedává smysl? Nebo by se to mělo tvářit pořád stejně a ve chvíli, kdy uložím soubor, zavřu editor, přijdu o spoustu informací – a při dalším otevření téhož souboru se budu sakra divit, kam to všechno zmizelo?

[chrono]

Ja ako používateľ predpokladám, že keď otvorím napr. png súbor, tak po použití Save budem mať png súbor a nie niečo, čo sa nedá nikde idne použiť (a preto si myslím, že mali použiť mierne iný názov, aby bolo zrejmé, že to ukladá kompletný stav dokumentu; niečo také aj odporúčali niektorí používatelia na ich mailing liste, problém ale bol, že tú zmenu urobili vývojári bez nejakej diskusie a potom už nechceli nič zmeniť).

[pta]

a preto si myslím, že mali použiť mierne iný názov, aby bolo zrejmé, že to ukladá kompletný stav dokumentu

To je ale uplne nepochopeni. Ta editacni metadata Gimpu (vrstvy, objekty, masky, …) prece nemuze ulozit pod mierne inym nazvom, protoze v tech bitmapovych formatech jako PNG neni kam ! Proto je _nutne_ pouzivat vlastni format.

[chrono]

Mierne iný názov pre "Save" (a nie pre samotný súbor). ;)

[Pavel Čejka]

Při mnohých úpravách metadata nevzniknou, nebo jsou bezvýznamná. Načtu-li bitmapu bez vrstev a žádné nevytvořím, nač otravovat s formátem XCF?

[Michal Kubeček]

Obávám se že ne. Vývojáři se prostě rozhodli, že budou zcela ignorovat, kdo jsou jejich uživatelé a k čemu a jak drtivá většina z nich GIMP používá, a vnutí jim násilím svou filosofii. Samozřejmě že to nedopadne tak, že by uživatelé používající GIMP k úpravám fotek přešli na model "pracuji na projektu, který průběžně ukládám v XCF a na konci (možná) jako bonus udělám export do něčeho jiného", kterým se vývojáři ohánějí, ale aspoň jim znepříjemní život. Uživatelé se se skřípěním naučí, že jednou z libůstek tohoto programu je to, že místo Save se používá Export a vývojáři budou mít dobrý pocit, jak jejich "logika" zvítězila nad realitou.

Musím říct, že bych vývojářům GIMPu docela přál, aby se našel někdo, kdo si udělá analýzu, kdo GIMP používá, k čemu, jak a proč, a pak založil fork, který tohle vezme na vědomí a místo dělání naschválů pod praporem jakési bláznivé vize vyjde vstříc skutečným uživatelům, jejich potřebám a přáním…

[xkucf03]

Samozřejmě že to nedopadne tak, že by uživatelé používající GIMP k úpravám fotek přešli na model "pracuji na projektu, který průběžně ukládám v XCF a na konci (možná) jako bonus udělám export do něčeho jiného"

Jistě, uživatel si třeba může stáhnout z foťáku JPEG a pak na tom začít „pracovat“ – jeden den si to otevře, ořízne, uloží jako JPEG, druhý den si to otevře, aplikuje nějaký filtr, uloží jako JPEG, třetí den si to otevře, domaluje někomu kníry nebo brýle, uloží jako JPEG, čtvrtý den si to otevře, něco vyretušuje, udělá modřejší oblohu, uloží jako JPEG… sedmý den už je obrázek opakovanou JPEG kompresí citelně zmrvený, uživatel ho vystavuje na web nebo posílá na tiskárnu a chlubí se, že to udělal v Gimpu.

Tohle je styl práce hodný nemocného člověka. Vůbec se nedivím, že ho ten SW nepodporuje¹ a snaží se místo toho uživatelům ukázat lepší cestu.

_{[1] což neznamená, že by ho neumožňoval}

[Michal Kubeček]

Tohle je styl práce hodný nemocného člověka.

No a co? Uživatel má plné právo být blbcem a žádný program mu nikdy nedokáže stoprocentně zabránit v tom, aby dělal hlouposti. Když bude tentýž uživatel sice pracovat s "XCF projektem", ale střídavě bude obrázek zmenšovat na 640x480 a zvětšovat na původní velikost a prokládat to různými "vylepšujícími" filtry, bude kvalita degradovat úplně stejně a GIMP nehne prstem, aby mu v tom zabránil. V jednom konkrétním případě se o to ovšem snaží, ale tak nešťastně, že to přidělává práci i těm uživatelům, kteří dobře vědí, co dělají a proč.

Ony tyhle snahy psát software tak, že místo toho, aby uživatelům pomáhal efektivně pracovat, se snaží uživatele vychovávat ve jménu vyšších idejí svých autorů, většinou dopadají dost smutně.

[potato]

Souhlasím s tím, že při některých způsobech práce GIMP akorát zbytečně otravuje. Na druhé straně je prostě rozdíl mezi uložením-načtením a sekvencí export-import. To naprosto chápu coby vývojář programu, který také umí nějak naimportovat použitelná data ze spousty formátů, ale řadu z nich neumí uložit, aby se to líbilo programům, pro které je tento formát nativní (a někdy to ani nejde, protože ony formáty prostě nejsou dost obecné).

Vývojáři v tuto chvíli vzali jako prioritu nemást v tomto směru uživatele. OK. Jelikož GIMP zvládá cyklus import-export pro formáty jako PNG dobře, chybí možnost říci, že chci pracovat s jednoduchými formáty, nechci serializovat plnohodnotnou representaci obrázku v GIMPu, a ať už mne s tím furt neotravuje. To sice teď téměř lze, ale vyžaduje překopání klávesových zkratek.

[Mti.]

Doufam, ze ta neustala snaha prezentovat Gimp JEN jako Photoshop zdarma nesla az tak daleko, ze by pouzili Photoshopi grafiku bez souhlasu autora. (nezkoumal sem to detailne)

Gimp pouzivam uz hodne dlouho a nektere "vylepseni" mne nelakaji/netesi. :-/

[Saul Tigh]

Ta neustálá snaha prezentovat GIMP jako úplnou náhradu za Photoshop ten projekt hlavně nejvíc poškozuje...

(Nemluvě o chování např. toho "šéfredaktora" z GIMP Magazine...)

[chrono]

Kde sa napr. v tom odkazovanom článku hovorí o tom, že Gimp by mal byť plnohodnotná náhrada za Photoshop?

[Mti.]

Nemluvi, "jen" se z neho zrovna dela atrapa. Photoshop neni plna nahrada za GIMP.... tak nevim, proc se o to snazi. :-P

[vain]

No aby byl, za ty prachy Ale furt mi ho budou vnucovat, když mě ale stačí GIMP zadara!

[gtz]

No jelikož GIMp prozatím podporuje PSD jen pro čtení tak přechod bude hodně těžký.

[Bedňa]

Stiahol som to a vyzerá použiteľne.

[loki]

Gimp je super, ale myslim, ze nema smysl si lhat, ze je lepsi nez photoshop.

[xkucf03]

Photoshop už jsem dlouho nepoužíval, ale důležitější otázka mi přijde: umí Gimp všechno, co potřebuji?

[Bedňa]

Z môjho pohľadu áno a s týmto nastavením sa mí páči ešte viac.

[gtz]

Kdyby dokázal korektně otevřít PSD soubory tak by to bylo ještě lepší. O zápisu ani nemluvím.

[Bedňa]

Pozeral som TODO, majú v pláne doplniť ďalšiu funkcionalitu. S čím je najväčší problém?

[gtz]

Gimp co jsem zkoušel tak otevře standardní PSD, ale pokud si člověk pohraje s nastavením CS4 tak má GIMP po ptákách. Snaží se to otevřít, ale šmytec. Divné mi je, že XnvieMP to otevře v pohodě ať se jedná o jakékoliv PSD. XnvieMP to dokáže i v tom PSD formátu uložit.

Hlavní problémem vidím možnost uložení nativního formátu PSD, protože ten formát přečtou skoro všechna studia.

[Bedňa]

Keby si mal PSD čo ide otvoriť a to isté PSD ktoré nejde otvoriť po zmene nastavení, tak by som sa pozrel čo rozbíja import do GIMP.

[gtz]

Většinou se jednalo o použití multi-page PSD. Kdyby Gimp dokázal otevřít PSD, udělat v něm nějaké úpravy a pak ho zase "korektně" uložit tak to bych přivítal asi nejvíc.

[Bedňa]

Musel by byť na to dostatočný tlak, v TODO to je, ale priority si nastavujú vývojári.

[gtz]

asi vývojáři nechtějí, aby Gimp používal někdo z pro oblasti, že? Pokud by tato funkce byla tak spousta lidí o GIMPu budou uvažovat a budou se ho snažit používat.

Další věc jsou velké soubory (PSD, TIFF) z velkých TIFFů se GIMP totálně posere a na tyto věci se pak musí použít nip2, takže by to chtělo zamakat i na tom.

[Bedňa]

Daj link na taký veľký TIFF, ja s GIMP nemám žiadne problémy.

[pepe_]

Stačí jakýkoliv 100mb tiff třeba pro CTP a GIMP spadne.

[Bedňa]

Neviem čo je to CTP, ale práve som otvoril .tiff s veľkosťou 143.1MB bez najmenšieho problému.

[Mti.]

a nemuze to byt tim, ze nesplnujes podminky na neco takoveho ? (tj. novejsi nebo zase starsi verze? Problemy maji lidi z vice distribuci)

Konkretne Fedora 20 s "defaultnim" gimpem a kernelem... neotrevre toto (odkazovano tamtez, bacha nic pro slabsi povahy, je toho pres 300MB ale zas je to hezky detailni, s domaci technikou to jeden da tezko. ).... no zkusil sem v tom bugreportu uvedene "obejiti" problemu ... MALLOC_MMAP_MAX_=0 a nasledne spustit gimp s prislusnym obrazkem... a de to. (to podtrzitko tam ma byt)

Vyse uvedeny problem se vztahuje na kombinaci gimpu 2.8 a kernelu 3.12... gimp 2.9 tim "pry" uz netrpi... :-/

Ehm... uplne stejne mi to de na tlamu kdyz chcu otevrit vic (>5) "normalnich" obrazku najednou, ("normalni" obrazek je napr jpeg z Eos650D...) coz mne teda toci vic, jak jeden velky obrazek, ale vysledek je stejny.

[Matelko]

Re:__Konkretne Fedora 20 s "defaultnim" gimpem a kernelem... neotrevre toto ....

Tak jsem to zkoušel na PCLinuxOS (2.6.38.8 -pclos3.bfs) s Gimpem 2.8.6 o otevřel to i na dost slabým počítači úplně v pohodě asi za 10 vteřin. Píše mi to rozlišení 15 427 x 12 549 a dole pod obrázkem 1.8 GB.

Ale Firefox měl velký problém s načítáním odkazu.

[Bedňa]

Příloha:

• gimp.jpg (361545 bytů)

Kernel 3.13.0, GIMP 2.8.10, Sabayon, pohoda jazz viď screenshot v prílohe. Takže zas ďalší mylný odhad že GIMP stojí za kulové a pri tom ide o Fedoru. Tak aspoň si chalanom pomohol nájsť skutočnú chybu.

[Mti.]

Kopni si do Fedory, klidne. Pokud by ses podival, ten bugreport psal clovek, co to testoval na Ubuntu a Mintu, pridal se tam kdosi s Archem...

A taky tam psali, ze to delalo s 3.12 kernelem...

...ale urcite za to muzou lidi od Fedory.

[little.owl]

Ten limit ma duvod, a pokud si mam vybrat mezi selhanim SW a zbytkem systemu, radsi sestrelym mizerny SW.

[Bedňa]

Nekopem do Fedory, to si začal ty Neviem či mám zázračné ruky, ale mne všetko ide

[little.owl]

Useknout a vystavit!

[Bedňa]

Ja fakt neviem ako je to možné, keď čítam čo všetko v Linuxe nejde a mne to roky ide k spokojnosti, tak to prikladám vyššej sile Napr tu spomínaný GIMP som asi ani nevidel padnúť.

Prípadne je chyba v užívateľoch na druhej strane a majú chorobu magnetických rúk. Dá sa to identifikavať tak, že si na seba začneš prikladať oceľové predmety a budú na tebe držať

[little.owl]

Dá sa to identifikavať tak, že si na seba začneš prikladať oceľové predmety a budú na tebe držať

Ale mne maminka rikala ze je to normalni ....

[Bedňa]

[little.owl]

Pokud nestaci stavajici limit M_MMAP_MAX, ktery je tusim 65536, tak by se vyvojari gimpu meli jit snad picnout.

[Mti.]

2.9 uz tim "pry" netrpi a s predchozim jadrem to "pry" problem taky nedelalo. Ja, s dovolenim, nezastavam nazor, ze Gimp je spatny... jen jsem dal k dobru, proc to nekomu mohlo nechodirt.

[little.owl]

Musi prepsat kod, tady je zadny kernel je nezachrani.

[little.owl]

mmap(NULL, 67108864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0)                                  = 0x7fcedd182000
brk(0x7fcedd1a3000)                     = 0x7fcedd182000

Zachazi s mmap() jak cuncata ....

[otula]

Přílohy:

• eso-gimp28.png (657752 bytů)
• eso-gimp29.png (590938 bytů)

Jen tak na zkoušku jsem zkusil uvedený obrázek otevřít, ještě jsem ho i naklonoval do více vrstev - zcela bez problému GIMP 2.8 i 2.9

[otula]

Stačí jakýkoliv 100mb tiff třeba pro CTP a GIMP spadne.

No, už jsem v něm pákrát otevíral do několika vrstev několik TIFF souborů, které měly každý kolem 1 GB, přičemž GIMP držel (i když teda práce s tím byla celkem utrpení, jenže víc než 8 GB RAM do počítače nedostanu…)

[gtz]

Bohužel ty soubory jsou neveřejné (většinou se jedná o FF panorama pořizované z letadel -> ty TIFFy jsou v nekomprimované podobě a mají kolem 350 - 650MB). A to jsem zkoušel na nějakém C2D s 4GB jak s kernel-default tak i s PAE a Gimp vždy udělal bumbác. Právě protože GIMp padal tak jsem začal používat nip2.

[Bedňa]

Skúšal som tu odkazovaný 300MB TIFF a úplne v pohode, asi to bude tou kombináciou Kernelu a GIMPu ako tu už bolo spomínané.

[gtz]

Zkoušel jsem poslední co je pro opensuse tedy 2.8.10 i poslední kernel co je a dopadne to stejně. Ty TIFFy mají (11386*11447 , dpi cca 1199) a Gimp to neotevře ani náhodou. Co jsem se díval tak 2.9/2.10 je pouze nějaká hodně raná verze, kterou nemá cenu ani zkoušet.

[Michal Kubeček]

Ten, který tu byl jako ukázka, ve 12.3 bez problémů otevřu, včetně nabízené konverze barevného profilu - gimp 2.8.2, kernel 3.7.10.

[gtz]

Vyzkouším to na 13.1 (2.8.6 GIMP, kernel 3.11.6-4)

[Michal Kubeček]

Zkusil jsem i 13.1 a otevře to taky (na stroji s 4 GB paměti).

[gtz]

Na 13.1 ten odkazovaný soubor se mi podařil na stroji s 4GB (T8100) otevřít. Sice mu to trvalo celkem dlouho, ale otevřel ho. Zkoušel jsem to na pomalejší mašině (1.5GB) a tam ho otevřel až za dlouho dobu a nešlo s tím ani moc dělat (každá operace byla utrpení). No zkusil jsem rebootnout do XP kde mám nějaký starší PhotoSop Elements a ten ani neprotestoval a otevřel ho v klidu a celkem rychle (myslím, že to celé bude asi v nastavení toho PS scratch disku).

U těch TIFFů co jsem měl k dispozici možná byl problém s kompresí, protože ten TIFF zde udává něco kolem 560M po načtení, ale to co jsem zkoušel (soubor cca 500MB a po natažení měl skoro 1.2G a i tehdy na mašině s 4GB s tím měla CS4 dost co dělat).