A co do analizy obrazu, to jest to dość proste - dla obrazów cyfrowych istnieje ok. 200 różnych cech (tych użytecznych, bo w ogóle jest ich nieskończenie wiele). Katalogując obrazy należy te cechy wyodrębnić (robi się to odpowiednią obróbką) i przechować razem z nimi (z reguły cechy mają charakter liczbowy).
Dzieląc wartości cech na zakresy można zbudować klasy obrazów - do jednej klasy należą te obrazy które określoną cechę mają zbliżoną do siebie. Ważne aby przy definiowaniu klas, pozostałe wybrane cechy miały dla danej klasy wartości rozbieżne (a różne klasy nie miały zbieżnych tych samych wartości cech).
Dalej to już bułka z masłem; przeciągnięty (przeładowany) obraz obrabia się, wyodrębnia cechy i wyszukuje w katalogu obrazy tej samej klasy. Jeśli cechy są dobrze skalibrowane to znajdzie te same obrazy poddane różnej obróbce.
Tak działa np. uniwersalne rozpoznawanie pisma tzn. litera A napisana arialem, timesem czy inną czcionką, wg odpowiednich cech nadal będzie należeć do tej samej klasy.
To co, chłopaki? Koniec z małą ilością prac na atarowskie gfx-compo? ;) Tylko trochę dopieścić i wioooo... publika się ucieszy, że toto kolorowe i nie miga... :D
Ciekawe, czy ten obrazek z fortyfikejszyn był "przejechany" czymś w stylu Rasty: ;)
hmmm.... sredniawka niewiadomo co o tym myslec, oko z netu + dolozona golaska przejechane na bitmape mono i ? .... troche kapa ... ... ten obrazek tez raz dwa mozna wyswietlic na atari bez problemu
tak, to jest mix prac HJB, które były pierwotnie przez niego malowane .... pędzlami; dopiero potem konwertowane do formatu "Atari". Druga praca HJB z Forta była robiona od zera bez szkicu na papierze. Ciekawy jestem Waszej opinii czy to jest ok - pierwsza praca. Prace są autora ale ich powstanie jest niestandardowe jak na scenę. Teściu (HJB) najprawdopodobniej namaluje obraz z tej łączonej pracy - czyli historia zatoczy koło. A sam dopiero stara się opanować ograniczenia Atari...dlatego na razie hires.
z tego co gadałem "oko" było malowane miesiąc z tzw. przerwami technologicznymi, konwersja to 2 dni bo teściu trochę musiał jednak dopieszczać dither ręcznie.
teraz męczy się w 16 kolorach (ST) - zobaczymy. Rasta trochę była uzywana - ale nie bylo dobrych wyników - stąd hires. na płotnie pewnie by coś wygrał ale to nie scena;) - ale ograniczenia platform retro to dla niego spore wyzwanie - próbuje róznych technik: od zera (pixel art) i konwersje prac malowanych przez siebie w różny sposób. Za bardzo stawia na merytorykę prac (ile sie nasłuchalem nt walki demonów - np. o cios w serce który byl zadawany w tai właśnie sposób aby ominąć tarczę) ,a jednak takie kompo wygrywa się chyba techniką która wymaga doświadczenia i warsztatu.
właśnie kila razy zadawałem pytanie o np. Rastę/konwersje swoichprac i tego typu sposób podejścia do kompo i jestem ciekawy opinii. Może ona wpłynąć na wycofanie prac z SV2k13.
W kolejnych compo trzeba będzie chyba dołożyć warunek sprawdzenia "systemem antyplagiatowym". No chyba, żeby RC było odrębną kategorią dla prac własnych przenoszonych na Atari z innych środowisk...
@Anonymus: no właśnie o wyszukiwaniu obrazkiem pisałem, że się naszukałem.
Rasta trochę była uzywana - ale nie bylo dobrych wyników - stąd hires. na płotnie pewnie by coś wygrał ale to nie scena;)
I to teraz dopiero wychodzi na jaw? Trzeba było dać wcześniej znać przy okazji takiej pracy, że to tylko *kolaż* z dwóch innych obrazów, w dodatku niescenowych a nie jeden obrazek zrobiony specjalnie na to gfx-compo! :> Trochę nie fair, ludzie mogli być w błędzie...
Patrząc na niektóre obrazki wydaje mi się, że RC "mógł lepiej". Jeżeli będziecie robić konwersje i efekty będą średnie, to dajcie znać (najlepiej załączając oryginalny obrazek i parametry konwersji). Postaram się odpowiedzieć co można było zrobić inaczej.
Chyba znalazłem główną zasadę pracy z RC. Jeżeli obrazek wygląda dobrze w rozdzielczości 160x240 po redukcji ilości kolorów do 16 (bez ditheringu), to jest spora szansa, że będzie wyglądał dobrze po konwersji :) Obrazki wielokolorowe jak np. Philsana ->link<- też wyglądają nieźle, ale to już bardzo zależy od ustawienia elementów na ekranie: - mało kolorów w linii - duże poziome powierzchnie jednego koloru - pionowe powierzchnie jednego koloru - detale obrazka tworzone za pomocą mniej niż 5 kolorów.
co do moich obrazków na górze- większość robiona do 1-2 mln iteracji, potem poprawki w g2f, dlatego efekty sa marne. nie wiem, czy warto czekac np do 100 milionów? czy to nada detale obrazkowi który przy 1 mln wygląda przyzwoicie? ustawienia standardowe, dither=line2, maski na drobne elementy lub na cala postac. Czasem korekta obrazka przed konwersją poprzez zwiększenie nasycenia i kontrastu, w przypadku pani w wannie- znaczne zmniejszenie kontrastu tla.
@gorgh Tak, ja zwykle czekam kilkaset milionów iteracji, ale warto wtedy dać /s=1000 , /s=5000 lub nawet /s=10000 (gdy chce się mieć najlepszy możliwy obrazek). Porównaj obrazki po 4mln iteracji i po 400mln. W standardowych ustawieniach jest używany jeden wątek. Zwiększysz szybkość programu używając /threads=liczba core'ów w Twoim systemie. W kolejnej wersji dodam, aby RC zużywał całą dostępną moc procesora domyślnie.
o dzięki, rzeczywiście jest poprawa. Mam przy okazji mały user request: czy można by w przyszłej wersji zaimplementować zmniejszenie zużycia procesora, tak aby zostawić czas dla innych programów? obecnie przy procesorze 2.2 Ghz nie mogę nic innego wykonywać, do tego nawet rozłącza mi się internet :) Gdyby RC mógł pracować w tle, powiedzmy na 50 % zużyciu procesora wtedy byłby dużo wygodniej. A tak w ogóle to program bardzo w porządku, widze duże możliwości dla np. slideshow, albo nowych trybów migających
I to teraz dopiero wychodzi na jaw? Trzeba było dać wcześniej znać przy okazji takiej pracy, że to tylko *kolaż* z dwóch innych obrazów, w dodatku niescenowych a nie jeden obrazek zrobiony specjalnie na to gfx-compo! :> Trochę nie fair, ludzie mogli być w błędzie...
być może tylko jak? :) przecież nie ma żadnych zapowiedzi i informacji podczas kompo :|
gfx compo w Polsce to ogólnie jakaś tajemnica i sprowadzanie rzeczu do absurdu - niekiedy nawet ksywy i gmyrki są zabronione. jakby było tak - że jest opis obrazka, potem obrazek - to info by na bank poszło. Tak jest np. na Revision i to jest ok.
a co to jest praca niescenowa? że najpeirw malowana? moim zdaniem tak jest chyba trudniej ;) - no ale ja się nie znam...
Prace HJB na SV2k13 na XL/XE - te obecne co już poszły też są tak tworzone, że są najpierw malowane a potem wciągane z ręcznie korygowanym ditherem (ale wstępnie filtry są używane). Nie ma tych rysunków jednak na stronie HJb (to nowe rzeczy, które najpier będą prezentowane w formacie JIL na SV) - ja je widziałem bo akurat miałem okazję. Daje zatem znać zawczasu, tylko nie wiem czy w dobrym miejscu :) Dzięki Dracon za info zwrotne - tak czy siak.
Chyba znalazłem główną zasadę pracy z RC. Jeżeli obrazek wygląda dobrze w rozdzielczości 160x240 po redukcji ilości kolorów do 16 (bez ditheringu), to jest spora szansa, że będzie wyglądał dobrze po konwersji :)
@ilmenit: Ja używam amigowskiego Hamlaba v2.1.0 i konwertuję do 3 lub 4 bitplanów (8/16 kolorów) ze zmianą przeważnie 7 kolorów co linię. Jak ładnie wychodzi to potem konwersja na RC zajmuje już tylko chwilkę.
Apropos pracy HJB; uważam, że jeśli praca na Atari do compo jest stworzona na podstawie swojego własnego dzieła - czyli tak jak w tym wypadku - to jest jak najbardziej OK i nie ma mowy o plagiacie. Nie skojarzyłem :)
Tym niemniej sprawdzanie przez google images to fajny pomysł. I oczywiście dla większości amigowych "prac" z wiadomego okresu wyskoczyłby Borys Valejo :)
Tak, UAE Oprócz bootowania systemu z HDD zakładam voluma GFX do katalogu na pulpicie żeby łatwo mieć dostęp do plików z grafikami.
Ustawienia Hamlaba Bit Planes - 4 (16 kolorów) Palette - Sliced 7 (7 kolorów będzie zmieniane co linię) Można jeszcze majstrować ditherem ale można przekombinować. Printscreenem wrzucam do painta a potem to Rasta. Ot cała filozofia.
Do autora: Jedna bardzo ważna rzecz by się przydała. Mianowicie, aby przy wywoływaniu z param. /continue działała opcja zmiany wątków /threads. W chwili obecnej, przy kontynuacji wygląda na to że jest to zablokowane (tzn jak ustawimy na początku zabawy tak jest do końca).
Command line przy /continue jest pobierany z pliku output.png.rp i tam można go zmienić. Ale to dobry pomysł, żeby można było nadpisać niektóre parametry.
@Eagle Wrzuciłem ten obrazek do RC i wygląda naprawdę nieźle po 50mln iteracji przy /dither=line2 i /predistance=euclid. Biorąc pod uwagę jak działa tryb HAM to rzeczywiście zwiększa on szansę dobrej konwersji za pomocą RC.
Może warto by było dodać (w samym RC albo UI) opcję redukcji kolorów w pojedynczym wierszu - wtedy nie trzeba by ograniczać się do 16 kolorów z hamlaba.
Nie chodzi o samą redukcję kolorów (to już było próbowane). Rzecz w tym, że w trybie hold-and-modify kolory zmieniane są co kilka pikseli, podobnie jak w RC.
Mi te obrazki HJB nie dawały spokoju już bezpośrednio na party, właśnie z daleka trąciły jakimś prostym zabiegiem na istniejących już obrazkach. Wrzuciłem więc już w domu ową pracę z okiem w gogla i znalazłem - myślę HA! Idę więc na stronę zawierającą pracę, a to strona Henryka Jana Bacy, a na compo autor to HJB. Ki czort? poszukałem i stwierdziłem, że to musi być właśnie ktoś namówiony przez jakiegoś atarowca do przetworzenia i przeniesienia kilku obrazków na Atari.
nie namawiałem na konwersję. to decyzja HJB co do, na razie, jednej pracy . druga praca z Forta stworzona jest "tradycyjnie" (podobnie jak obie z SV2K12 to też prace tylko pixelowane) Traktuje to jako zabawe, wyzwanie i ćwiczenie umysłu na emeryturze:) - osobiście trzymam kciuki. Zaintrygowało go to, że trzeba mierzyć się głównie z ograniczeniami - przy warsztacie malarskim, czy też obecnych narzędziach te ograniczenia praktycznie nie istnieją. Wiem, że planuje jeszcze wystartować w kompo.
@Xeen Coby nie zaśmiecać wątku otwórz może nowy i pogadajmy na ten temat. Konkluzji nie będzie, organizator party sam zadecyduje, czy takie prace zakwalifikować, a jeśli tak, to czy w oddzielnej konkurencji jak onegdaj RayCompo na scenie.
Wcześniej stanęło w tym temacie, iż powinny być dołączane dwa etapy tworzenia pracy wyświetlone przed ostateczną wersją. Jak ktoś obliczył zajmie to w gfx compo od 5 do 10 min więcej czasu.
Wątek pozwoli ludziom wyrobić sobie zdanie na ten temat. Będą wiedzieć dla czego warto na coś głosować lub nie warto, docenić pisel art lub niezależnie talent grafika. W tym celu przydałyby się dwa przykłady robienia takiej pracy polegające na pokazaniu wcześniejszych etapów z podaniem zabiegów i stosowanych narzędzi. Na przykład wyżej pokazana praca HJB i zwycięska praca Inserta z SV2k10 w zestawieniu z pracami Piesia czy Odyńca pikslowanymi od podstaw plus jeden przykład zwykłej foty przepuszczonej przez filtr np ołówek z Photo Shopa i skonwertowany do A8.
Był Ford Mustang, teraz pora na niezłą d.. ekhm dziewczynę :) Wyszło tak (ok 330 mln iteracji): Starałem się uzyskać efekt pixelartu na Atari. Nie jest doskonale, niemniej jak to ocenicie ? :) Może ktoś spróbuje uzyskać lepszy efekt ?(obrazek źródłowy nietrudno znaleźć wiadomą metodą)
Gorgh ja już pracują nad tą Twoją policjantką. Zobaczymy co wypluje RC za jakieś min. 300 mln iteracji :)
Co do slideshow. Myślałem już o tym, że fajnie byłoby mieć jakiś slide-show maker. Jako param. skrypt z plikami xex obrazków i muzyką z rastera. Łączy, pakuje i robi xexa. Rozmarzyłem się, nie ? Może któryś koder coś takiego stworzy :) Wiem, że to nie takie hop-siup, ale spowoduje to że w krótkim okresie czasu będzie więcej slide-showów przyzwoitej i wybitnej jakości na małe Atari jak wersji Robbo. Dodatkowo rozrośnie się wśród konwertujących obrazki wiedza na temat możliwości RC, co i jak najlepiej wychodzi itd itp. A to przecież chodzi, czyż nie? :)
Akurat mam teraz dostęp do AMD x4 965 i próbuję rendering na 4 wątkąch (ale zasuwa!). Szkoda, że nie ma skompilowanej wersji RC pod 64bit bo może byłoby jeszcze szybciej. Sprawdzałem też /dither=knoll pod Win7 64bit - faktycznie obrazek Destination renderuje się pomału jak ślamazarny żółw. Da się coś z tym zrobić? Bo dither wygląda ciekawie.
