Gimp 2.8 z trybem jednego okna!

[n-pigeon]

Niezwykle wyczekiwane wydanie programu Gimp, oznaczone numerkiem 2.8, ujrzało światło dzienne. Wyczekiwane, ponieważ jest to pierwszy krok dawno wyczekiwanych zmian.

 

Zapraszam do przeczytania krótkiego artykułu o nowym Gimp'ie, na naszej stronie: http://www.max3d.pl/article.php?id=187

 

 

Niestety wersja binarna dla systemu Windows nie została jeszcze przygotowana, ale dostępna jest wersja 2.8RC1, pod adresem: http://gimp-win.sourceforge.net/stable.html

 

Aktualne wydanie powinno pojawić się na tej samej stronie niebawem.

Edytowane 4 Maj 2012 przez Adek

[Lucas]

W końcu:). Te latające okna doprowadzały mnie do szału. Pod Windowsa na razie jest tylko wersja RC - sprawdziłem u siebie i na razie działa w porządku. Bardzo dużą zmianę widać po przepisaniu części narzędzi na Cairo - można ich używać precyzyjniej i chyba też szybciej działają (perspektywa, obracanie, skalowanie itp.)

[Leleń]

nareszcie można gimpa nazwać programem. Jeszcze jakieś 5lat i będzie można go nazwać programem graficznym, sądząc po tempie w jakim zrobili split okienek..

[Nezumi]

Juz myslalem, ze jest pelna wersja na winde :( RC1... Blah... :P

W nastepnym wydaniu juz zapowiadane sa 16 i 32 bity kolorkow, robi sie konkretnie. Oczywiscie jesli nastepna wersja nie wyjdzie za 3 lata ;) Musze potestowac jak sobie GIMP radzi z duzymi formatami... Jak sie juz jakis spolecznik zlituje i skompiluje ostatnia wersje.

[n-pigeon]

@Leleń

@Nezumi

 

Spoko następny cykl wydawniczy ma być znacznie krótszy :P

[Skoti]

sądząc po tempie w jakim zrobili split okienek..

Split to według twórców gimpa najmniej ważna sprawa była i się z nią nie spieszyli, bo nie czuli się odpowiedzialni za to, że Windows nie potrafi dobrze zarządzać oknami. Photoshop też tylko w wersji dla Windowsa, jest jedookienkowy, a dla MacOS X jest wielookienkowy tak jak GIMP.

[ikkiz]

mnie wkurza ta idiotoodporność nowego gimpa, że nie pozwala zapisać w jpg (zapisać można tylko w xcf, akcja pod ctrl+s, a do jotpega trzeba eksportować ctrl+e) Baaardzo to wygodne, jak się skanuje jakiś dokument na szybko, bo mylę się 10/10 razy - znaczy wciskam ctrl s, muszę dać anuluj, eksportować, a potem jeszcze raz przy zamykaniu muszę przekonać gimpa, że wiem co robię. Jak by nie to, to nowa wersja jest w pytę i dynamiki fajne dla tabletu... Ale chyba na razie bedzie zainstalowany "obok" 2.6, a dokładniej tego http://gimp-painter.softonic.pl/ forka.

[szczuro]

ikkiz: skróty chyba można zmienić

[imprecis]

Skoti - PS CS6 na Mac OS X jest już jednookienkowy :)

[n-pigeon]

@ikkiz

To nie jest funkcja dla idiotów, tylko usprawnienie workflow z plikami :)

 

Teraz możesz wygodnie zapisywać i exportować jednocześnie, nie musząc zmieniać rozszerzenia za każdym razem :)

Dodatkowo dzięki temu, jest możliwa opcja szybkiego exportu z nadpisaniem wcześniej wyexportowanego pliku.

 

Skróty są konfigurowalne jakby co.

[narwik]

No, trochę się naczekałem na kolejną wersję, ale co tam : ) Dwa kciuki w górę.

[mrys]

Split to według twórców gimpa najmniej ważna sprawa była i się z nią nie spieszyli, bo nie czuli się odpowiedzialni za to, że Windows nie potrafi dobrze zarządzać oknami.

 

Dla mnie jednookienkowość jest zwyczajnie wygodniejsza, niezależnie od tego czym Windows potrafi zarządzać a czym nie.

 

Mnie to przypomina dyskusje na forum Blendera parę lat temu, gdy na pytanie: czemu okno wyboru plików do otwarcia (czyli: open file) jest takie pogmatwane a nie tak proste jak chociażby standardowe windowsowe padała odpowiedź: jest lepsze, bo nie jest windowsowe.

[Skoti]

Dla mnie jednookienkowość jest zwyczajnie wygodniejsza, niezależnie od tego czym Windows potrafi zarządzać a czym nie.

Jednookienkowość jest zdecydowanie wygodniejsza... pod Windowsem ;p. Pod innymi systemami masz znacznie większe pole manewru z okienkami i możesz każde okno pinować, ustawiać zawsze na wierchu (aby się nie chowały), dowolnie przesuwać, grupować z dowolnymi innymi oknami i masz te okna jako karty w jednym oknie itp. Dzięki temu możesz ustawić sobie interface tak jak chcesz, ale jeśli nie ma dobrego zarządzania oknami w systemie, to wygodniejsze jest jedno okienko.

[Nezumi]

Na macu dodano opcje jednookienkowosci do PSa. Ja w ogole nie wiem jak latajace swobodnie okienka moga byc wygodne. Jesli mam otwarty jeden program a pulpit mam po to zeby ladnie tapeta wygladala to jeszcze jakos (choc i tak sobie te latajace okienka ludzie ukladaja i koniec koncow jest to samo co na jednookienkowym tylko mniej wygodnie. No ale nie jest windowsowo wiec jest PRO :D Ale wlasnie - jak mam pulpit pelen przeroznych ikonek i rozne programy pootwierane to latajace okienka... No nie wiem - mnie nie pomagaja w niczym.

[ikkiz]

chyba się przyzwyczajenie jak do 23% vat i rosnących cen benzyny, ale puki co - szewska pasja :) Zmiana skrótu nic nie da, bo czasem chcę zapisać, do xcf, a czasem do wynikowego pliku. Było by odwrotnie, ale równie nie wygodnie. To, że nie można w innym formacie (Komunikat: Można użyć tego okna dialogowego do zapisu w formacie XCF programu gimp. należy użyć polecenia plik -> wyeksportuj) To nie usprawnienie, tylko typowy bacik na użytkownika. Jak by tam dodali dodatkowy guzik "wiem co robię, pozwól mi zapisać jak chcę" to by ne zaszkodziło. Mogło by na przykład automatycznie przeskoczyć w tryb eksportu po takim czymś, żeby, skoro mogłem wskazać plik do nadpisania (inny niż xcf), albo jeśli już wymyśliłem i wpisałem nazwę, żebym mógł bez trzykrotnego klikania i wpisywania od nowa, normalnie zapisać.

[imprecis]

Nezumi - dokładnie. Odkąd przesiadłem się na Mac OS X to była w zasadzie jedyna rzecz, która mi się nie podobała. Nie wiem jaka tutaj wygoda - dla mnie to rozprasza w pracy i PS'a zawsze wolałem pod Windowsem.

[ikkiz]

w wielookienkowym gimpie pod windą dało się pracować na pełnym ekranie i ukryć palety tabem i w jednookienkowym da się tak samo. Na plus, ale ja nie narzekałem na wielookienkowy. Inne zmiany są dla mnie ważniejsze, zwłaszcza dynamiki z tabletu.

[mrys]

Nadal nie widzę warstw dopasowania (w PS od ok. 12 lat).

[Dobrotek]

Oprócz dynamiki pędzla, niech żyją grupowania warstw, cage-tool-transformation - taki jakby mały odpowiednik PSowego Free Transform. Może nie jest dokładnie to samo, ale coraz lepiej to wygląda :)

Trochę szerzej można poczytać na blogu gimp.edu.pl

http://gimp.edu.pl/2024-gimp-2-8-ostatecznie-wydany.html

(co prawda nie jest to perfekcyjne tłumaczenie, ale mamy nadzieję, że jest w pełni zrozumiały i w miarę zgodny z oryginałem :))

Dodam tylko, że maski i pozostałe aspekty związane z warstwami zostaną dodane już wkrótce (o ile dobrze wyczytałem).

Have fun! :D

[n-pigeon]

@Dobrotek

Maski dla grup prawdopodobnie trafią do 2.10. Filtry i efekty warstw + nieliniowa edycja, są zaplanowane na 3.2.

 

@mrys

Auto-skalowanie warstw również, jeśli o to Ci chodzi.

 

Choć te założenia, są elastyczne, może być później może być wcześniej. 16 i 32 bit głębia miały być w 3.0, a trafią do następnej wersji.

[muody]

Mrys'owi chodzi o osobny rodzaj warstw, które dynamicznie nakładają efekty z menu Image > Adjustments. Na przykład Levels, Curves, Hue/Saturation. Nie zawierają same w sobie grafiki, co najwyżej maskę. Dzięki temu konkretna warstwa albo kilka warstw poniżej może mieć zmienioną kolorystykę, i można z tym eksperymentować w dowolnym momencie. To o to chodzi z tą nieliniową edycją w 2.10? Oby

[Mortom]

No wreszcie jedno okno! No to za 2 lata kolejny UP :) jak końca świata nie będzie rzecz jasna ;)

[mrys]

@Dobrotek

Maski dla grup prawdopodobnie trafią do 2.10. Filtry i efekty warstw + nieliniowa edycja, są zaplanowane na 3.2.

 

Noo, to jeszcze z 10 lat czekania w takim tempie. Gimp odstrasza mnie między innymi właśnie brakiem wiarygodnych perspektyw rozwoju.

[n-pigeon]

@muody

Aha, nie znalem tej nazwy, dla mnie to zawsze były filter layers, albo filtry warstw. No czyli tak samo planowane na 3.2.

 

@Mortom

@mrys

 

Nowy cykl wydawniczy ma być znacznie krótszy, choć przy 2.10 będzie dużo pracy, ale 2 lata to już na pewno nie będą.

 

Co do perspektyw rozwoju, to już się pojawiły, od kiedy na pokładzie, w końcu, znalazł się GEGL.

[Nezumi]

Mnie szczerze mowiac zniecheca w GIMPIE (i innych projektach OS) jedno - olewanie windowsa. "wez se skompiluj", "poczekaj", "moze ktos zrobi", "nie narzekaj jak masz za darmo" "jak cie bylo stac na winde to kup se Photoshopa", "to sie przesiadz na linuksa" i caly ten syf (tak, mam zly dzien :P). Jakos Blender moze sie bez calej tej linuksowo-wolnosciowej dramaturgii ukazac na raz na wszystkie platformy. Nie wierze, ze ktos moze umiec napisac program ale jednoczesnie jego kompilacja to taki wielki problem. Wkurza mnie to tak samo jak ta bzdura z wydawaniem gier na PC pozniej niz na konsole bo... bo co? Konsoli nie kupie a piractwo i na konsolach i na PC jest niezaleznie od tego kiedy gre wydadza. W przypadku GIMPa czuje sie olewany i o ile tworcy faktycznie maja do tego pelne prawo to przestaje mnie pasjonowac czekanie na laske badz nielaske. Blender moze - mogli by i inni. A tak to ja to pieprze - odpalam shopa i juz nie sprawdzam czy komus sie dzis zachcialo czy nie.

 

Ale mam zly dzien no zesz kurna chata :P

[n-pigeon]

@Nezumi

 

Może i masz zły dzień, ale nie odwracaj kota ogonem ;] Nie chce by powstał jakiś brzydki mit, który nie ma nic wspólnego z rzeczywistością.

Programiści Gimpa nie olewają Windowsa, ani Maca:

 

1. Programiści Gimpa nie robią binarek, nawet na Linuksa, kompilują jedynie dla siebie. Właściwie to programiści Blendera tak samo :P

 

2. Zarówno w przypadku Gimpa jak i Blendera, binarki dla systemów operacyjnych przygotowują ochotnicy, którzy nawet nie muszą być progamistami. Facet zajmujący się binarkami na Win właśnie nad niemi pracuje, ale tak samo facet który przygotowuje binarki dla Fedory :D, koleś robiący dla Ubuntu już to zrobił i jest dostępna :)

 

3. Wielu, jeśli nie większość, użytkowników Linuksa nie umie kompilować programów, zazwyczaj poddają się jak skrypt konfiguracyjny wyrzuci brak zależności i nie wiedzą co dalej robić :D

 

4. W zespole Gimpa nie ma nawiedzonych fanboyów Open Source, robią Gimpa na wszystkie platformy, a zgłaszane błędy traktują jednakowo, nie ważne jakiego systemu używa użytkownik. Pracują nad Gimp'em ponieważ to lubią :D

 

5. Kompilowanie programu pod Windowsem jest znacznie trudniejsze i bardziej upierdliwe, dlatego dobrze, że w ogóle znalazł się ochotnik by to robić. Oczywiście można zrobić cross-compilacje, ale patrz punkt 1.

 

Równie dobrze można powiedzieć, że olewają użytkowników każdej dystrybucji Linuxa :D co oczywiście było by śmieszne xD

[Nezumi]

A instalki jak nie mialem tak nie mam. Szlag by to...

 

;););)

 

Wiesz, moja frustracja wynika stad ze 2.7 nawet mi podszedl i chetnie bym sie pobawil 2.8 a chwale sobie stabilny system i nie instaluje co 20 minut nowego programu tylko po to zeby za dwa dni wersje zmieniac.

Z tym ogloszeniem ze cos sie ukazalo to Adobe robi podobnie - najpierw robi wielki show ze oto ukazuje sie nowy pakiet a potem mowi ze bedzie dostepny jakos za miesiac :D Luz. Rozumiem o czym do mnie rozmawiasz - moja wina. Nikogo nie olewaja, po prostu mam slaby dzien i mi sie cierpliwosc skonczyla na ten tydzien...

 

Tutaj to przynajmniej jest usprawiedliwione bo jak tworcy oglosza ze juz jest to i ochotnicy sie latwiej znajda do kompilacji. Cokolwiek by ten proces nie mial oznaczac :D

Edytowane 5 Maj 2012 przez Nezumi

[Dobrotek]

Windowsowa binarka już jest dostępna

[Nezumi]

Dzieki Dobrotku ;) Zasysam zatem.

[mrys]

Nowy cykl wydawniczy ma być znacznie krótszy, choć przy 2.10 będzie dużo pracy, ale 2 lata to już na pewno nie będą.

 

Pytałem o WIARYGODNE perspektywy ;) Obietnic w wykonaniu ekipy Gimpa to ja się już nasłuchałem - zobaczę to uwierzę. Szkoda, bo program niczego sobie, chociaż do PS startu nie ma. O warstwy dopasowania pytałem, ponieważ jak czytam jakie to ficzery w tym 2.8 umieścili to mam wrażenie deja-vu blenderowego: najpierw wodotryski a potem baza. Ludzie o to ( i o CMYK chociażby) pytają przy każdej edycji Gimpa i ciągle nic.

[Skoti]

Mnie szczerze mowiac zniecheca w GIMPIE (i innych projektach OS) jedno - olewanie windowsa.

...

Jakos Blender moze sie bez calej tej linuksowo-wolnosciowej dramaturgii ukazac na raz na wszystkie platformy.

To nie jest olewanie windowsa co często jego brak i nieznajomość jego oraz jego narzędzi - i wbrew temu co mówisz blender ma podobne problemy.

Problem polega na tym, że programiści OS zazwyczaj sami korzystają z systemu i narzędzi OS (Linux, Eclipse, GCC, Valgrind...), i Windows jest im bardziej obcy niż tobie Linux (przykładem mogę być ja, ostatnio dłużej niż kilka godzin na rok używający Windowsa na przełomie 1999/2000). Pod Windowsem, którego nie znają, muszą przebudować w Microsoft Visual Studio masę bibliotek, które się z nim gryzą, i całą aplikacje, oraz zrobić pakiet instalacyjny. To wszystko trwa - podobnie byłoby gdyby używali Windowsa i musieli robić na Linuksa.

Blender jakiś czas temu miał podobny problem i szukali osoby, która będzie robić buildy na Windowsa, bo nikt się tego nie chciał podejmować. Obecnie jest osoba odpowiedzialna za buildy na Windowsa, ale nawet mimo to te buildy wychodzą 1-2 dni po linuksowych (jedyna różnica to to, że Blender nie ogłasza na stronie zanim nie będą gotowe wszystkie pakiety - czytaj użytkownicy Linuksa muszą czekać mimo gotowej wersji na wersję Blendera dla Windows).

 

Nie wierze, ze ktos moze umiec napisac program ale jednoczesnie jego kompilacja to taki wielki problem.

Problemem jest czas - kiedy pod linuksem wszystkie biblioteki ma bo używa ich, dodatkowo w każdej dystrybucji dostaje je w gotowej formie, to pod Windowsem musi je sam budować, często pod kompilatorem pod którym nie zadziałają (przykładowo kod jest kompatybilny z GCC i Mingw32 (GCC pod windowsa), ale kompilator Microsoftu już nie jest w stanie go skompilować (bo żaden kompilator nie wspiera dobrze standardów C/C++ i każdy w inny sposób, więc dobry kod w jednym nie działa w innym), a inna biblioteka znowu pod Windowsem zadziała tylko i wyłącznie z kompilatorem Microsoftu (kod wykrywa, że to _WIN32 i daje kod specyficzny dla kompilatora Microsoftu i nie zadziała z Mingw32)). Rozwiązywanie takich problemów i konfliktów bibliotek z różnymi kompilatorami w kodzie którego nie znasz i w narzędziach, których nie używasz, może potrwać (chociaż nie więcej niż właśnie kilka dni).

 

Wkurza mnie to tak samo jak ta bzdura z wydawaniem gier na PC pozniej niz na konsole bo... bo co? Konsoli nie kupie a piractwo i na konsolach i na PC jest niezaleznie od tego kiedy gre wydadza.

Gry są wydawane na konsole pierwsze, bo to jest priorytet. Konsole przynoszą więcej zysku z gier i to jest fakt. Wymaganie, aby gry wychodziły równocześnie na Windowa i Konsole, lub nawet wcześniej na Windowsa, to mniej więcej tego typu wymaganie jak od firmy produkującej gry i zarabiającej na nich wymagać, aby równocześnie z Windowsem wychodziły wersje na MacOS i Linux, albo na nie wcześniej. Dodatkowo nie prawdą jest to co pisałeś o piractwie, bo konsole mimo wszystko mają mocniejsze zabezpieczenia, a ich łamanie nie jest takie łatwe i powszechne. Wydanie równocześnie jest niekorzystne bo:

- Spowalnia wydanie na konsole... o czas w której robiona jest wersja na Windowsa,

- Wydanie na Windowsa, który nie ma praktycznie żadnych zabezpieczeń antypirackich, zmniejsza zyski nawet z konsoli (bo gracze mają dylemat: kupić grę na konsolę, czy ściągnąć pirata na Windowsa).

[n-pigeon]

@mrys

Właśnie w Gimpie jest najpierw baza potem wodotryski, dlatego wszystko tyle trwało :) z naciskiem na trwa_ło_.

Jeśli wrócimy do historii programu, Gimp już dawno miałby większość z funkcji o których mowa, ale tylko gdyby przyjęli model bazarowy taki jak Blender i dodawali nowe elementy core kiedy była by potrzeba. Problem w tym, że programistów Gimpa jest znacznie mniej, więc postanowili, że GEGL będzie biblioteką ogólnego użytku, nie tylko Gimp miał jej używać. Wybrali takie podejście, by przyciągnąć potencjalnych koderów którzy nie są zainteresowani samym Gimpem. Niestety zaprojektowanie i napisanie takiej poważnej, zaawansowanej biblioteki programistycznej, nie jest pracą na rok. Potem jeszcze praca integracji GEGLa w samym Gimpem, które ciągnęło się od 2.5.

 

Jednak spokojnie, teraz to naprawdę się dzieje GEGL jest na pokładzie i prace idą w niesamowitym tempie, dawno nie widziałem takiego CODE RAGE.

To cieszy ponieważ pracy jest dużo przy tym wydaniu, to jeszcze nie jest wydanie typu: dodajemy kilka nowych narzędzi. To poważna zmiana.

 

W moim artykule przeczytasz, jakie kroki podjęto by skrócić cykl wydawniczy. Dodatkowo można spodziewać się, że każda następna wersja będzie wydawana w krótszym czasie ponieważ będzie mniej poważnych ingerencji w program, a jedynie napisanie i implementacja nowych narzędzi na tym co już jest.

 

Jeśli chodzi o 3.0 przykładowo, port na GTK3 jest prawie gotowy, leży w branchu, ale odłożono ostateczną implementacje by całkowicie skupić się na GEGL i dostarczyć go jak najszybciej użytkownikom. Jest to pierwszy znak zmiany polityki rozwoju.

 

Wcześniej dodawano wszystko do mastera i na tym pracowano, potem okazywało się, że jakaś funkcja ma poważne wady i trzeba przedłużyć cykl, mimo, że większość nowych funkcji była gotowa. Tego już nie będzie, do mastera trafiają teraz tylko GOTOWE, w miarę stabilne gałęzie rozwojowe.

 

GEGL jest znacznie potężniejszy i lepiej zaprojektowany niż taki poszerzany core, zatem tworzenie narzędzi przy jego wykorzystaniu, trwać będą znacznie krócej niż by to było w innym przypadku.

Więc GImp ma szanse szybko nadrobić stracony czas.

Za jakiś czas posiadać będzie funkcje których nie ma w PS, np. całkowicie nieliniowa edycja.

[natas]

Czasem sobie googluję nie zrozumiałe dla mnie zwroty by w miarę wiedzieć o czym czasem mówicie i trafiłem na zapis ,że GEGL nie obsługuje CMYK-a to w końcu jak z tym jest http://pl.wikipedia.org/wiki/GEGL

[n-pigeon]

@natas

 

Z CMYK'iem sprawa jest złożona. Może rozpisze w punktach dla czytelności...

 

1. CMYK nie jest zaimplementowany w GEGLu, jest możliwy, ale nie był priorytetem, ponieważ.

 

2. Zarówno programiści GEGL jak i Peter Sikking (szef projektantów GUI), nie są za tym by CMYK był trybem koloru, jak Lab, XYZ, RGB itd. Ponieważ nigdy nim nie był, wszystkie operacje i tak są wykonywane w RGB.

Zatem trzeba znaleźć inne bardziej rozsądne rozwiązanie.

 

3. Powstały plany innego prawdopodobnego workflow z CMYK dla Gimpa, ale też nie jest priorytetem, to raczej projekt, dla kogoś kto bardzo chce CMYK.

http://blog.mmiworks.net/2009/05/gimp-enter.html

http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html

 

4. CMYK nie jest priorytetem ponieważ, twórcy gimpa chcą się skupić całkowicie na foto-manipulacji i tworzeniu obrazu. Jeśli ktoś potrzebuje widzieć jak zdjęcie, czy grafika, będzie wyglądać po wydrukowaniu, to sam Gimp od bardzo dawna ma narzędzia, soft proofingu i color menagement, bez których i tak samo użycie CMYKa nie pokazało by, jak zdjęcie wyjdzie w druku.

Same przygotowanie do druku w CMYKu, powinno być wykonywane narzędziem do tego przeznaczonym, jakimś DTP np. Scribus: http://www.scribus.net/canvas/Scribus

 

Dlatego CMYK nie jest w planach, ale zdaje się nikt nie postawił na nim kreski, chyba, że coś mnie omineło :D

Jednak, nie jest i nie będzie, na liście rzeczy do zrobienia, głównych programistów Gimpa.

 

PS

 

Zapomniałem napisać, przy nowoczesnych drukarkach, przy druku w domu nie jest potrzebna konwersja do CMYK. Nowoczesne drukarki same to doskonale robią. Samo Adobe forsuje workflow z RGB.

CMYK jest potrzebny tylko przy zaawansowanych drukach masowych w drukarni, a tam albo są specjalne narzędzia dostarczone przez producenta sprzętu, albo wykorzystywane są narzędzia DTP.

Edytowane 5 Maj 2012 przez n-pigeon

[mrys]

Za jakiś czas posiadać będzie funkcje których nie ma w PS, np. całkowicie nieliniowa edycja.

 

A co oznacza dokładnie ta nieliniowa edycja? Bo jeżeli chodzi o to, że edytując obraz mogę ingerować w każdym momencie w każdy etap tej edycji (np pod koniec zmienić coś, co było na początku, albo wręcz przeprowadzić dodatkową edycję początku) to PS ma to właśnie od 12 lat w formie chociażby warstw dopasowania, które na takie ingerencje pozwalają.

 

Bazą z punktu widzenia użytkownika nie jest GEGL, CEGL czy DEGL czy jak go tam nazwiecie. Bazą dla niego są dostępne narzędzia. Owszem, user widzi być może pozytywne efekty tego GEGLA (poza CMYK-iem jak widzę, co jest dość dziwne, biorąc pod uwagę charakter programu) ale szczerze to mało go obchodzi, jak to jest realizowane od strony programistycznej.

 

Jeżeli oceniać Gimpa w kontekście konkurencji dla PS (a tak zwykle bywa on pozycjonowany, abstrahując od ceny) to na razie Gimp ma do nadrobienia kilka lat. I nigdy ich nie nadrobi bo PS tez nie stoi w miejscu, a ostatnie wersje przynoszą naprawdę znakomite rozwiązania ważne właśnie dla użytkowników (np. wykorzystanie mocy GPU do "realtimowego" nakładania filtrów). Życzę Gimpowi jak najlepiej, ale bardzo wątpię, czy ta legendarna Generic Graphic Library wiele zmieni. Może się pomylę :)

 

PS

 

CMYK jest potrzebny tylko przy zaawansowanych drukach masowych w drukarni, a tam albo są specjalne narzędzia dostarczone przez producenta sprzętu, albo wykorzystywane są narzędzia DTP.

 

Mylisz się. CMYK jest bardzo często wykorzystywany przy zaawansowanej edycji zdjęć. Np. kolorowanie czarnobiałych fotografii odbywa się przeważnie poprzez manipulowanie składowymi CMYK. jest jeszcze cały szereg innych zastosowań tego formatu - nie tylko druk.

[n-pigeon]

Słowem klucz jest CAŁKOWICIE, PS ma tylko częściowo nieliniową edycje. Reszta to jest dokładnie jak mówisz, możesz wrócić do wszystkiego, nawet do skopiowanego i wklejonego fragmentu, do transformacji, operacji na kanale, nie tylko do filtrów jak w PS.

 

Użytkownika tak, ale mówiliśmy o "perspektywach", sam o tym pisałeś, to o nich właśnie pisze. Charakterem programu jest fotomanipulacja i tworzenie obrazu. Druk należy do innego segmentu. Czymś namacalnym jest 16 i 32 bit w następnym wydaniu już dostępne w 2.9.0.

 

Gimp jest konkurencją na polu fotomanipulacji. Edycje video, 3D i druk zostawia innym programom, specjalizującym się w tych zadaniach.

 

 

Co do CMYKa, nie jest on, jak już pisałem trybem koloru, nic co w nim robisz, jeśli mowa o edycji koloru, nie dało by się zrobić z RGB lub Lab, a softproofing przytnie Ci niewykorzystane kolory. Po za tym użycie CMYK, jako trybu koloru, wyłączy wiele narzędzi, które nie mogą z nim działać, więc jaki ma to sens?

 

PS

Co do pierwszego akapitu, nie, nie jest to super długa historia, zmodyfikowanie czegoś z początku lub środka edycji nie zniszczy edycji wykonanych później.

Edytowane 5 Maj 2012 przez n-pigeon

[mrys]

Ale perspektywy są oceniane właśnie z punktu widzenia użytkownika - chyba, że to poligon doświadczalny dla programisty. A użytkownik widzi, że odstępy pomiędzy kolejnymi wersjami są kilkuletnie a obietnic było już bardzo wiele, stąd nie dziw się, że dla mnie wiarygodność gimpa jeżeli chodzi o rozwój jest niska.

 

Nadal traktujesz CMYK wyłącznie jako kwestię druku. Pomijam fakt, że wielokrotnie byłem zmuszony właśnie w tej formie przygotować ilustrację dla wydawnictwa to powtarzam: CMYK pozwala na operacje trudne lub niemożliwe w innych trybach i bywa wykorzystywany właśnie jako sposób na edycję obrazu. Tłumaczenie Sikkinga dlaczego CMYKA nie będzie zupełnie mnie nie przekonuje, bo on podobnie jak Ty sprowadza wszystko do kwestii drukarskich.

 

A tego nie rozumiem...

PS

Co do pierwszego akapitu, nie, nie jest to super długa historia, zmodyfikowanie czegoś z początku lub środka edycji nie zniszczy edycji wykonanych później.

[Skoti]

Jeżeli oceniać Gimpa w kontekście konkurencji dla PS (a tak zwykle bywa on pozycjonowany, abstrahując od ceny) to na razie Gimp ma do nadrobienia kilka lat. I nigdy ich nie nadrobi bo PS tez nie stoi w miejscu, a ostatnie wersje przynoszą naprawdę znakomite rozwiązania ważne właśnie dla użytkowników (np. wykorzystanie mocy GPU do "realtimowego" nakładania filtrów). Życzę Gimpowi jak najlepiej, ale bardzo wątpię, czy ta legendarna Generic Graphic Library wiele zmieni. Może się pomylę :)

To dotyczące ostatnich wersji PS i przykład jest świetny, z tego względu, że GEGL przynosi naprawdę w Gimpie dużo usprawnień i cały kod jest odpowiedzialny za canvas i operacje na nim (łącznie z przekształceniami, filtrami, pędzlami) jest przenoszony do GEGL i jest wykorzystywane API GEGL przy pisaniu nowych narzędzi i filtrów. Dzięki takiemu wszystkie nowe narzędzia, zależą od implementacji GEGL... który już częściowo jest w wersji OpenCL (gsoc2011 w którym pomagało AMD) i można wykorzystać moc GPU (nie w najnowszej wersji, bo uznano, że jeszcze nie jest rozwiązanie na etapie wydania, ale w 2.8 RC1 można było testować ustawiając zmienną środowiskową GEGL_USE_OPENCL=yes) - OpenCL będzie zapewne oficjalnie w 2.10 lub 3.0. W przyszłości również dodanie CUDA czy innych nowych API to nie będzie przepisywanie wszystkiego, a napisanie backendu dla API, a wszystkie narzędzia będą bez zmian w kodzie (bo API się nie zmienia). GEGL wygląda na solidną dobrze zaprojektowaną robotę, która może dać gimpowi kopa takiego, że każde przyszłe zmiany będą wymagały przykładowo tygodni zamiast roku pracy (podobnie jak u Adobe, które ma przemyślaną i dobrze zaprojektowaną podstawę PS i jest na tyle elastyczna, że pozwala dalej się szybko rozwijać).

[n-pigeon]

@mrys

Chciałeś perspektywy to Ci je przedstawiłem, to co opisujesz to historia, a historia nie jest przyszłością. Więc nie widzę związku. Wytłumaczyłem też dlaczego tak było w przeszłości. Jak mieli co chwila dodawać nowe bajerki, jak pracowali nad czymś innym, by potem mogli zrobić to czego oczekują użytkownicy, ale lepiej.

 

CMYK.

Tylko jakich operacji, nie zmienisz waloru, saturacji, barwy? Czy nie przygotujesz czerni, albo CMY tak by ładnie się drukowała, jak nakazuje tego profil drukarki, bo to już wykorzystanie drukarskie. Scribus świetnie to zrobi i wygodnie sobie ustawisz zdjęcie na formacie do druku, a też jest za darmo.

 

Co do cytatu, jak napisałem, możesz cofnąć operacje która była wcześniej, nie niszcząc tego co zrobiłeś potem i nie chodzi tylko o filtry jak edycja koloru czy blur.

[mrys]

OpenCL będzie zapewne oficjalnie w 2.10 lub 3.0. W przyszłości również dodanie CUDA czy innych nowych API to nie będzie przepisywanie wszystkiego, a napisanie backendu dla API, a wszystkie narzędzia będą bez zmian w kodzie (bo API się nie zmienia).

 

Różnica pomiędzy "będzie zapewne" a "jest" sporo znaczy. Mnie nie martwi kierunek rozwoju Gimpa (znacznie bardziej przemyślany niż Blendera, chociaż brak kilku rzeczy do tej pory jest denerwujący) tylko fakt, że jego tempo optymizmu nie budzi.

 

@mrys

Chciałeś perspektywy to Ci je przedstawiłem, to co opisujesz to historia, a historia nie jest przyszłością. Więc nie widzę związku. Wytłumaczyłem też dlaczego tak było w przeszłości. Jak mieli co chwila dodawać nowe bajerki, jak pracowali nad czymś innym, by potem mogli zrobić to czego oczekują użytkownicy, ale lepiej.

 

CMYK.

Tylko jakich operacji, nie zmienisz waloru, saturacji, barwy? Czy nie przygotujesz czerni, albo CMY tak by ładnie się drukowała, jak nakazuje tego profil drukarki, bo to już wykorzystanie drukarskie.

 

Ja tam widzę związek przeszłości z przyszłością. Skoro w przeszłości pewne rzeczy trwały ile trwały to teraz nie mam wielkiej wiary, że się to zmieni - ale, może się pomylę i też się będę cieszył.

 

Nie chodzi o to czy się da bez CMYKA czy nie (pewnych rzeczy nie), tylko jak jest łatwiej i efektywniej. W 256 kolorach też się da. Mimo wszystko jest to pewien standard, którego użytkownicy oczekują i rezygnowanie z niego jest błędem a sądząc z najczęściej wymienianych oczekiwań wobec Gimpa użytkownikom jest widocznie ten CMYK do czegoś potrzebny.

 

Mnie to przypomina historię znakomitego eksportera NURBS do mesha Power NURBS. Robił swoją robotę rewelacyjnie poza tym, że produkował tylko siatki złożone z trójkątów. No i na jakiejś konferencji szefowi firmy w której Power NURBS powstał zadano pytanie, dlaczego nie czworokąty? Odpowiedział: bo myśleliśmy, że nikt tego nie będzie potrzebował.

 

A co do CMYKa jak już wspomniałem najlepsza (według mnie) metoda kolorowania czarnobiałych fotografii wymaga wstępnej konwersji na CMYK. To tylko jeden z przykładów i zauważ - nie mający nic wspólnego z drukiem.

Edytowane 5 Maj 2012 przez mrys

[n-pigeon]

Różnica pomiędzy "będzie zapewne" a "jest" sporo znaczy. Mnie nie martwi kierunek rozwoju Gimpa (znacznie bardziej przemyślany niż Blendera, chociaż brak kilku rzeczy do tej pory jest denerwujący) tylko fakt, że jego tempo optymizmu nie budzi.

 

No i to już wytłumaczyliśmy z Skotim. :) Dlaczego tak było i dlaczego w przyszłości już tak nie będzie.

 

W skrócie.

 

Było tak, ponieważ nie było czym to zrobić.

 

Już tak nie będzie, ponieważ, narzędzie zostało zrobione i podrasowane tak, że pozwala na znacznie więcej, niż by pozwalało uproszczone rozwiązanie. Co więcej, samo narzędzie jest znacznie bardziej podatne na udoskonalenia.

 

 

 

Oh dopisałeś posta, pierwsza część zawiera się w tym co wyżej.

 

CMYK

Jakie kolorowanie fotografii może być wygodniejsze w CMYK, możesz pokazać przykład?

Co do użytkowników, większośćużytkowników go chce - jeśli nie wszyscy - ponieważ chce drukować :)

Edytowane 5 Maj 2012 przez n-pigeon

[Skoti]

@mrys: są 2 podejścia do rozwoju oprogramowania:

- robienie wszystkiego od podstaw w dobrze przemyślany sposób,

- robienie wszystkiego na raz, nie myśląc o dobrym zaprojektowaniu.

pierwszy sposób to mozolny początek, bez szybkich efektów, ale tępo nabiera rozpędu i rośnie wykładniczo (są solidne podstawy i dobrze zaprojektowany kod i zarządzanie nim to przyjemność), a drugi sposób daje duże efekty na początku, ale czym później tym wolniej i gorzej się rozwija lub wręcz rozwój jest niemożliwy (bo nikt nie wie gdzie co i jak, a wszędzie widać tylko zgliszcza).

Z tego powodu ostatnio znacznie bardziej boję się o tępo rozwoju blendera niż gimpa.

W rozwoju blendera coraz bardziej widać jednak, że widzą co się stało z kodem i zaczyna się przepisywanie (Brecht przyznał, że Blender Internal już nie da się rozwijać, bo kod jest tak napisany, że aby coś z rendererem zrobić trzeba napisać wszystko od nowa (Cycles), system zarządzania siatką też ssał i wreszcie po wielu latach wszedł bmesh... ale problemem jest to, że jeśli spojrzy się prawdzie w oczy to cały program jest do przepisania i do przeprojektowania (od viewportu po symulacje fizyki) i wszystkie nowe rzeczy z X ostatnich lat powinny iść do kosza i zamiast czekać na nowe możliwości użytkownicy będą czekać, aż będzie przepisane i odzyska dawne możliwości).

GIMP wcześniej niż Blender wpadł na to, że trzeba całe jądro aplikacji przepisać i cofnąć się wstecz aby iść do przodu... jednak jeśli chodzi o tępo to blender wcale nie ma takiego tempa - przepisywanie blendera już trwa około 3 lata i do tej pory tak podstawowych narzędzi nie było jak bevel (który dalej nie działa jak powinien), dodatkowo mimo 3ch lat prac nad "nowym blenderem" w większości kod jest taki jaki był... nie wiem czy to tempo jest faktycznie takie szybkie (tempo wydań tak bo raz na 2 miesiące to szybko, ale nie rozwoju).

 

PS. różnica pomiędzy będzie a jest... jest spora, tylko to już jest napisane, a zapewne będzie dotyczy udostępnienia (wsparcie dla GPU wyszło zaraz po zamknięciu listy nowinek w Gimpie i przyjmowane były tylko bugfixy do tego co się znajdzie z tego co pamiętam, dlatego wsparcie dla GPU opuściło to wydanie).

[n-pigeon]

@Skoti

 

Każdy projekt, ma inne podejście w zależności od zasobów, więc spoko. Blender ma dużo ludzi do pracy, Gimp nie. Przepisali renderer, mesh system, UI, przepisują compositor, cząsteczki, view-port i pewni coś jeszcze, ale chodzi o to że ma kto to robić, a patrząc realistycznie, ilu użytkowników i programistów miałby Blender gdyby robili takie GEGLe? Blender ma za dużo tych systemów, by każdy ładnie zaprojektować.

Gimp był w gorszej sytuacji, nie organizowali opłaconych projektów bo niby jak, Open Album Project? Po za tym mają kasę, ale nie mają, co z nią zrobić, nie ma ochotnika który zostałby menadżerem jak Ton. Nie interesują ich pieniądze, wydają je na meetingi gdzie, razem, wspólnie kodują dla przyjemności. Zupełnie inny ekosystem niż Blendera i raczej się nie zmieni.

 

Core Gimpa starczy na dłuuugo, systemy Blendera nawet super zaprojektowane szybko by się zestarzały.

Przesadzasz też z bałaganem, gdyby było jak mówisz, ważyłby 900MB i nikt nie chciałby przy nim pracować.

 

PS

A przypomniało mi się przepisali system animacji, sculpt i przepisują nurbsy oraz modyfikatory <: d pewnie nied przyjdzie pora na system fizyki :>

Edytowane 5 Maj 2012 przez n-pigeon

[mrys]

@mrys: są 2 podejścia do rozwoju oprogramowania:

- robienie wszystkiego od podstaw w dobrze przemyślany sposób,

- robienie wszystkiego na raz, nie myśląc o dobrym zaprojektowaniu.

 

Ależ ja się z Tobą zgadzam i, jeżeli pamiętasz moje uwagi dotyczące Blendera, zawsze uważałem, że właśnie skupianie się na drugorzędnych elementach a zostawianie na koniec modułów podstawowych (b-mesh) było błędem. W przypadku Gimpa jest to robione bardziej z głową, ale niestety czas nie stoi w miejscu i jak bardzo przemyślany i potrzebny nie byłby rozwój bazy jeżeli trwa zbyt długo zniechęca do programu, Tak to przynajmniej wygląda od strony użytkownika, dla którego naprawdę nie ma żadnego znaczenia czy GEGL jest na baterie czy na krasnoludki. Jeżeli teraz rzeczywiście tempo rozwoju Gimpa wzrośnie to takie niedowiarki jak ja uznają że ok, warto było. Jeżeli nie, bo się okaże że teraz znowu trzeba to czy tamto poprawić zanim pójdziemy dalej to zapóźnienie programu tylko się pogłębi. No i na pewno optymizmowi nie służy takie podejście jak chociażby do kwestii CMYKa (wiem, wiem) bo wolałbym, żeby developerzy nie decydowali za użytkowników czego potrzebują (w końcu Colladą też się oburzałeś, a to IMO mniejszy kaliber "zaniedbania").

 

A co do Blendera... Osobiście uważam, że robiąc rewolucję 2.5/26 zmarnowano okazje na rzeczywisty i perspektywiczny rozwój programu. Akcyjna developerka od open movie do open movie to nie jest dobra droga. Ja to widze jako uzytkownik. Ty jako programista masz pewnie jeszcze bardziej dokładny ogląd tego, co zmarnowano.

[ikkiz]

CMYK w gimpie się przyda, rzadko bo rzadko, ale się przyda, choćby większość filtrów miała nie działa, ale:

Miałem sytuację, że przygotowywałem ilustrację do druku i jej częścią był biały napis na czarnym tle (rich black, czyli czarny wzbogacony CMY), i jeszcze drobny czarny napisik na białym tle. Gdybym automatowi powierzył konwersję, albo niekompetentnemu dtpowcowi, to by było tak, że przy minimalnym niespasowaniu na granicy czarnego i białego miał bym kolorowe obwódki, albo czarne tło było by blade. Malowałem w gimpie, ale potem musiałem to otworzyć w corel photopaint, żeby poprawić (usunąć CMY z małych czarnych literek, i z tła po obwodzie białych dużych liter) - nie mam Szopa, to się szarpałem z tym głupim photopaintem. podobnie się ma sprawa z szarością - automaty są mądre i starają się pomieszać kolor tak, żeby uzyskać kolor z jak najmniejszej ilości farby, ale jak mam małe czarne litery na szarym tle zrobionym z samego czarnego, to przez raster tła będą miały poszarpane brzegi. w tym momencie można zrobić szary z triady CMY a litery czarne i nie będzie tego efektu. Może developerzy gimpa nie zdają sobie do końca sprawy z tego, że nawet program nie będący programem DTP czasem potrzebuje CMYKa bardzo. żadko, ale bardzo i to nie tylko kwestia prestiżowa, żeby już nikt nie wypominał braku...

Pojawił się eksport do PDF, tekst ma być z czcionek, a elementy wektorowe mają być wektorami, gdy to możliwe. ok, jaki to ma sens jak ten pdf będzie w RGB, czyli często konwersja do CMYK będzie w trybie random i literki będą tęczowe?