Jump to content
n-pigeon

Gimp 2.8 z trybem jednego okna!

Recommended Posts

@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

Share this post


Link to post
Share on other sites

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

Edited by Nezumi

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@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.

Edited by n-pigeon

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Edited by n-pigeon

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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ć).

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

Edited by mrys

Share this post


Link to post
Share on other sites
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ć :)

Edited by n-pigeon

Share this post


Link to post
Share on other sites

@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).

Share this post


Link to post
Share on other sites

@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 :>

Edited by n-pigeon

Share this post


Link to post
Share on other sites
@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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy