Przygarnij GIMPa
Wśród wielu zarzutów jakie pojawiają się pod adresem edytora graficznego GIMP, chyba najczęściej wymienianym argumentem jest swoista niemoc rozwojowa tego projektu. 20 lat minęło a projekt dopiero teraz zaczął obsługiwać (w wersji deweloperskiej) większą precyzję obliczeń (zamiast dotychczasowych 8bitów na kanał), że obsługę CMYK przemilczę. Jak zwykle powodem jest rozległość projektu i brak rąk do pracy. Lecz wspomniany zarzut wobec tempa rozwoju nie jest pustym biadoleniem nad ludzkim lenistwem i zawiera niewypowiedziane pytanie – dlaczego GIMP nie doczekał się kampanii na Kickstarterze, gdzie z powodzeniem zbierają pieniądze na rozwój choćby deweloperzy edytora Krita?. Otóż coś drgnęło w tym temacie i teraz możemy w końcu sypnąć groszem na rozwój tego projektu.
Øyvind Kolås jest programistą odpowiedzialnym za rozwojów GEGLa. W gruncie rzeczy jest on liderem tego projektu a pracę nad nim rozpoczął w połowie 2000 roku. W GIMPie odpowiada za niedestrukcyjną obróbkę grafiki, efekty warstw, itp. Mecenat nad jego pracami możemy podjąć pod tym adresem. Na dzień dzisiejszy (19.01.2016) Øyvind Kolås może liczyć na 142 patronów i miesięczny grant w wysokości 633 dolarów.
Jehan Pagès jest artystą pracującym nad filmem animowanym ZeMarmot wykonanym w całości za pomocą narzędzi opensource. Jego pracę możemy docenić pod tym adresem, a cześć dochód Jehan przeznaczy na rozwój zaawansowanych narzędzi animacyjnych w GIMPie. Jehan jest jednym z najaktywniejszych deweloperów w historii ostatnich lat rozwoju naszego ulubionego edytora graficznego.
Powyższe w jakimś stopniu powinno zakończyć utyskiwania na temat niemożności finansowania rozwoju GIMPa. Jednak należy przyznać, że takiej formie (dotacja na fundację) zbiórki nie są tak wyraziste jak choćby patronat nad konkretnym deweloperem. W tym drugim przypadku widzimy skalę oczekiwań i skalę wsparcia. Dotacje wpadające do wspólnego worka są niewidoczne i słabo motywują społeczność do zrywu i aktywniejszego finansowania. Na wpłatę po 1 dolarze stać chyba każdego, a uwidoczniona skala takich wpłat tylko spotęgowałaby ten efekt. Nie pomaga też brak klarownego przełożenia zgromadzonych środków na pojawienie się konkretnych rozwiązań. Dlatego Øyvind Kolås ma spore szanse by przeciągnąć społeczność na swoją stronę i uzyskać wsparcie które przełoży się na efektywny rozwój GIMPa.
14 komentarzy
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
OK, idea zacna, pozostaje tylko niepewność, czy środki owe pójdą na nieprzyczyniające się do żadnego rozwoju działania jak “interfejs jednookienkowy”, czy np. na implementację CMYK.
Tak, to prawda. Wspomniałem o tym – brak jasnych celów w określonym terminie i po uzyskaniu odpowiedniej kwoty dotacji. Może to też jest przyczyną, że GIMP do tej pory nie otrzymał sensownego zastrzyku gotówki.
Akurat interfejs jednookienkowy sobie bardzo chwalę i cieszę się bardzo ze zmian w interfejsie Gimpa (dawno to nastąpiło, ale zawsze). Obsługa CMYK to marzenie i dałbym na to grosza… mam nadzieję że nie posłuchają Wojtka
Właśnie o ten CMYK mi chodziło, może wyraziłem się niejasno…
I dlatego dotacje powinny być nie na deweloperów, tylko na określony cel – tzw. bounty, model który z powodzeniem od lat funkcjonuje w świecie amigowym, czy chociażby Haiku, a w open source chyba wciąż nie jest zbyt popularne gdzie panuje zasada róbma co chcema.
Po co wam praca w przestrzeni CMYK w Gimpie?
Do zastosowań drukarskich.
Od wielu lat zajmuję się projektowaniem graficznym, głownie na potrzeby druku. Chętnie korzystam z gimpa, uważam go za świetne narzędzie do pracy twórczej, Często wybieram go zamiast Photoshopa mimo braku możliwości obróbki niedestrukcyjnej. Przypadki, kiedy potrzebna jest jest mi możliwość pracy bezpośrednio w przestrzeni CMYK, są zasadniczo bardzo rzadkie i powiem szczerze, że obecnie bardziej przydatna wydaje mi się możliwość pracy z kolorami spotowymi. Dlatego nieodmiennie zastanawia mnie ciągłe narzekanie na brak CMYK-a w Gimpie. Softproof w Gimpie + konwersja do dowolnego profilu kolorystycznego umożliwia profesjonalne przygotowywanie obrazów do druku w przestrzeni CMYK.
Ja zajmuję się drukiem okazjonalnie, więc masz większe doświadczenie w przygotowaniu materiału do druku w pingwinie. Ale naprawdę nie wiem jak mam coś namalować pędzlem w gimpie w takim samym kolorze w jakim narysowałem wcześniej wektor. Nie wiem też jak równać czernie. W dodatku nie ma jakiegoś wygodnego narzędzia w Scribusie do porównywania wartości cmyk w projekcie, ala aktywna pipeta.
Dla osób okazjonalnie wykonujących projekty do druku to jest poważny problem. Drukarnie zawsze chcą prace w CMYK albo zastrzegają się, że nie ponoszą odpowiedzialności za konwersję. Więc robi się konwersję u siebie, a potem pozostaje jedynie korygować poszczególne zdjęcia lub grafiki metodą prób i błędów, znowu konwertować, ponownie poprawiać itd., co jest pracą gorszą niż przewożenie taczkami piasku tam i z powrotem. A ostatecznie i tak drukarnia wydrukuje po swojemu. Jeśli to jest np. jeden arkusz, to jeszcze jest to ewentualnie wykonalne, ale w przypadku folderu reklamowego albo albumu nie ma szans. Kiedyś przygotowywałem album i mimo że drukarnia wykonywała skład – wg moich wskazówek, wiele zdjęć nie wyglądało tak, jakbym sobie życzył, mimo dobrej woli drukarni. Po prostu nikt tam nie będzie konwertował pojedynczych ilustracji i porównywał ich z oryginałami. Wszystko się robi całościowo, automatycznie. Osoba, która miałaby od początku pogląd, jak dane zdjęcie lub grafika będzie wyglądać w CMYK, miałaby szansę przygotować ilustracje o wiele lepiej.
I tu się z Tobą zgodzę, to są rzeczywiste, praktyczne problemy, które można napotkać pracując z Gimpem. Jednak nie widzę ich zasadniczo więcej. Pierwszy z nich możesz rozwiązać wykorzystując Scribusa. W Gimpie tworzysz obraz RGB, malujesz kolorem czarnym, następnie import pliku do Scribusa, nałozenie efektu obrazu Coulorise i ustawienie w nim dowolnego koloru z aktywnej palety w Scribusie. Alternatywnie możesz skorzystać z Krity – pomijam niestandardowy i nieintuicyjny sposób wprowadzania wartości składowych koloru CMYK (zakres 0-255), ale rozmawiamy przecież o Gimpie. Co do drugiego problemu, nie wiem, co masz dokładnie na myśli. Jeśli dokładniej opiszesz problem, to być może zaproponuję Ci jakieś rozwiązanie. Faktycznie, wielką niedoróbką Scribusa jest brak pipetki, która pozwoliłaby łatwo sprawdzić skład koloru pod nią. Może zgłoś to w trackerze projektu?
Podchodzisz do tematu z niewłaściwej strony. Problem, o którym piszesz zupełnie eliminuje softproofing. Działa to także w Gimpie – pracujesz w RGB i jednocześnie symulujesz wydruk na ekranie używając profilu właściwego dla urządzenia wyjściowego (prosisz o profil w drukarni, albo używasz standaryzowanych profili ze strony ECI – oczywiście podstawą jest posiadanie skalibrowanego i sprofilowanego monitora). Gdy pracuję w Photoshopie przy materiale zdjęciowym nigdy nie działam bezpośrednio w CMYK-u. Po prostu nie ma takiej potrzeby. Poza tym praca w CMYK ma swoje wady – cześć operacji nie jest możliwa do przeprowadzenia w tej przestrzeni. Przy takim podejściu unikniesz niespodzianek przy konwersji RGB – CMYK. Dla pewności możesz wykonać ją sam, gdy zakończysz edycję.
Ja zostałem przy Gimpie 2.6. Nie chciało mi się użerać z nowym, dziwacznym sposobem działania funkcji Save i eksportem, a 2.8 nie wnosiło nic, czego bym naprawdę potrzebował.
pracuje z Gimpem (brak CMYKa, ale jest dostępny Sproof, który działa bez problemowo), Scribusem, Inkscape (brak CMYKa), Krita (od niedawna) od wielu lat pod Linuxem (czasem też używam Blendera, również Rawtherapee ;)). Mam zdecydowanie pozytywną opinię o w/w. Na tą chwilę nie widzę potrzeby korzystania z płatnych narzędzi typu PS (chyba, że otrzymam projekt w np PS, wtedy jestem zmuszony), generalnie nie mam większych problemów z plikami do drukarni, ale to “chwilę trwało” zanim wypracowałem odpowiednie “procedurki” generowania plików 😉 – czasem wręcz jestem zaskoczony mile wiernością druku papierowego :).
Co do Gimpa pod Linuxem (przy 6 core procesorze i 16GRAM) działa w miarę przyzwoicie przy nawet dość dużych plikach 200-300mb itp, co prawda są filtry, które potrafią faktycznie spowolnić pracę.
Z pewnością te narzędzia wymagają na początku większego nakładu pracy, ale później to procentuje.
Kiedyś pracowałem na Quarku – dzisiaj maiłbym problemy by coś w nim zrobić tak do ręki, to samo dotyczy Corela, czy PS – jak mam używać tych narzędzi to mnie zaczynają po chwili irytować bo nie pamiętam gdzie jak funkcje są – zabawne, a niby takie doskonałe he he…