Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

RastaConverter by Jakub Dębski

Od 151 do 200 z 919

- 1: CommentAuthornosty
- CommentTime25 Jul 2012 01:07
Dracon - to zalezy od obrazka.
Mialem takie (jak np obrazek ktory wkleilem w 6 poscie wątku: ->link<- ktore wygladaly dobrze i praktycznie jak obrazek docelowy juz po 2-3mln iteracji.
Ale wiekszosc skomplikowanych wymaga np 50mln, a jak zostawisz do 70 albo 100 to tez zobaczysz roznice. A jak jeszcze dluzej to pewnie tez. Moj komp robi 10mln iteracji na godzine, wiec 1 obrazek = 1 noc + pare godzin w pracy ;)

Patrz na to czy zmienia sie LastBest i czy spada jeszcze Norm. Dist. Hostorie zmian masz w pliku csv.

Ja mialem taki obrazek (robiony ze zdjecia!) w ktorym ta wartosc spadla mi do 1.16 po 54mln iteracji.

Ale w miare kolejnych iteracji zmiany sa coraz delikatniejsze. Zauwazylem, ze jak algorytm "postanowi" ze cos zrobi na duszkach i np. po 5mln wstawi chamsko wygladajace "bloki" na poczwornych duszkach, to juz sie z tego nie wycofa. Ale moze sie okazac ze po 50mln te chamskie przejscia zostana zlagodzone pixelami i wyglada duzo duzo lepiej.
- 2: CommentAuthorilmenit
- CommentTime25 Jul 2012 09:07 zmieniony
"Nie bardzo zrozumialem idee - skoro program po uruchomieniu dosc szybko pokazuje jak moze wygladac obrazek "docelowo" po ustawieniach (okienko z prawej strony)"

Obrazek docelowy to nie obrazek, który będzie wynikiem, ale obrazek, do którego dąży proces optymalizacji. Jest przeskalowany do 160*wysokość, w wybranej palecie Atari, z naniesionymi poprawkami typu kontrast oraz z naniesionym ditheringiem podczas redukcji palety obrazka źródłowego do palety Atari.

Btw, beta 6 prawie gotowa. Dodana między innymi możliwość wyboru użycia rejestrów w poszczególnych liniach. Czyli można np. wyłączyć duszki w liniach 20-200.
- 3:
  
  CommentAuthorxeen
- CommentTime25 Jul 2012 11:07 zmieniony
4 miliardy iteracji, ładnych parę dni na niezłym kompie
- output.png-src.png
- output.png
- 4:
  
  CommentAuthorDracon
- CommentTime25 Jul 2012 12:07
@Xeen.
Kolory niezle, ale az sie prosi aby zastosowac jakis (inny?) sprytny algorytm ditheringu albo wstepnie lekko zredukowac palete... :)
- 5: CommentAuthorilmenit
- CommentTime25 Jul 2012 13:07
Kiedyś kombinowałem z konwersją tego obrazka, gdy nie było w RC jeszcze maski detali i efekty uzyskałem podobne. Spróbuję jeszcze raz :)
- 6:
  
  CommentAuthormgr_inz_rafal
- CommentTime25 Jul 2012 15:07
Kto pomoże z konwersją obrazka z załącznika? Mi zawsze wyłazi cały niebieski :(
- automapa.png
- 7: CommentAuthorilmenit
- CommentTime25 Jul 2012 16:07
Opis co dokładnie robisz, podaj parametry albo najlepiej załącz wszystkie pliki źródłowe i wynikowe.
- 8:
  
  CommentAuthormgr_inz_rafal
- CommentTime25 Jul 2012 19:07 zmieniony
Wydaje mi się, że jestem trochę bliżej... Jeśli jednak nie uda mi się uzyskać dobrego efektu, zaraz zapodam więcej szczegółów.

Na razie jednak chciałbym zgłosić problem: przy przetwarzaniu obrazka, który załączyłem do poprzedniego postu i wykonaniu takiej linii poleceń program wywala się.

Wysłałem raport do Microsoftu, może coś znajdą ;-)

RastaConverter.exe automapa.png /pal=Default /dither=knoll /filter=box /picture_colors /predistance=euclid /preprocess

Sygnaturka błędu:
AppName: rastaconverter.exe AppVer: 0.0.0.0 ModName: allegro-4.4.2-mt.dll
ModVer: 4.4.2.0 Offset: 00001694

======= EDIT: =======
OK, udało mi się dobrać parametry tak, żeby wyglądało to całkiem nieźle. Poniżej obrazek z bieżącym progressem. Dwa lamerskie pytania:
1. Kropki na górnym, fioletowym pasku - dlaczego tak się uwidoczniły? Na obrazku źródłowym też one występują, ale są w kolorze mocno zbliżonym do otoczenia.
2. Dlaczego zielone łąki zrobiły się żółto-czerwone? :) Na innych paletach jest jeszcze większa masakra z kolorami :)

Za parę godzin wrzucę efekt końcowy.

Aha, zapomniałbym o najważniejszym: serdeczne gratulacje, soft jest niesamowity, a obserwacja działania rzeczywiście wciągająca ;) I mówi to ktoś, kogo absolutnie nie kręci grafika na Atari :)

======= Inny EDIT: =======
Kurde, ale output.png wygląda trochę inaczej niż bezpośrednio w RC - znowu jakiś taki niebieski... No nic, zostawiam go tak na parę godzin i idę na obiad :)
- automapa_progress.png
- automapa_progress_wtf.png
- 9: CommentAuthorilmenit
- CommentTime25 Jul 2012 21:07
Chyba Nosty zgłaszał błąd, że gdy Windows ma ustawioną rozdzielczość z mniejszą niż 24bitowa paletą barw, kolory są złe. Nie masz tak czasem?
- 10:
  
  CommentAuthormgr_inz_rafal
- CommentTime25 Jul 2012 22:07 zmieniony
Hmm... Czegoś dalej nie rozumiem...

Oryignalny obraz:

Poniżej jest output.png - niebieski jak smerf :)

A tutaj zrzut z Atari800Win - bardzo ładny, choć brak czerwonego :)
- 11: CommentAuthorilmenit
- CommentTime25 Jul 2012 22:07
Ilu bitową masz ustawioną paletę barw w systemie?
- 12: CommentAuthornosty
- CommentTime26 Jul 2012 00:07
No dokladnie tak mialem pod windows server:
- obrazek docelowy widoczny w RC byl bardzo "oczojebny" i nieprzystajacy do zrodlowki.
- podgladany bezposrednio poza RC byl wylacznie w tonacjach niebieskich

Uznalem ze podglad moze byc zly, ale jesli zapisany png tez jest zly to nie ma co czekac i przerwalem zabawe. Nie generowalem xex'a.
- 13: CommentAuthorGonzo
- CommentTime26 Jul 2012 01:07 zmieniony
i stało się, dopiero anliza tego zdjęcia na a8 dowiodła, że na księżycu istniała starożytna cywilizacja. proszę zwrócić uwagę na prawy dolny róg - przecież to jest piramida (taka sama jak te w egipcie, tylko trochę mniejsza) tego nie mogła stworzyć natura. żeby to zbadać musimy wysłać swoją ekipę z a8 na księżyc, bo ja już nie wierzę nasa ;)
- moon.xex
- 14:
  
  CommentAuthormgr_inz_rafal
- CommentTime26 Jul 2012 08:07
@ilmenit, nosty
Racja, że też nie skojarzyłem po przeczytaniu wcześniejszych postów Nostego... Mam XP z 16 bitowym kolorem :) Nie spodziewałem się po prostu, że taka słaba paleta jest jeszcze "ustawialna" w XP :)

Dobrze, że coś mnie jednak podkusiło, żeby wygenerować na próbę xexa :)

OK, dzięki za pomoc i wyjaśnienia. Ze spokojem mogę się brać za kolejne obrazki.
- 15:
  
  CommentAuthorxeen
- CommentTime26 Jul 2012 09:07 zmieniony
tym razem scenowy "jeleń na rykowisku" - czyli smok + cycki. Konwert z zx spectrum, brak czerwonego koloru sprawił, że konwert zyskał commodoreowy klimat :)

od góry - żródło, co wyszło i cel do którego dążyliśmy, 1.5 mld iteracji, distance ponad 15 - nie widać.
dither - chess.
- 16:
  
  CommentAuthorDracon
- CommentTime26 Jul 2012 13:07
Jak na konwersje ze spectrumowego "hires" na atarowski lowres calkiem niezle. Do pelni szczescia brakowaloby oczywiscie pewnej edycji koncowej...
- 17:
  
  CommentAuthorxeen
- CommentTime26 Jul 2012 15:07 zmieniony
znana, świetna praca Piesia z ST (SV2K11)
krótko to liczyłem, ale moim zdaniem wygląda nieźle
- ghoul.jpg
- output3.png
- 18: CommentAuthorilmenit
- CommentTime26 Jul 2012 15:07
A gdzie xex? :)
- 19:
  
  CommentAuthormgr_inz_rafal
- CommentTime27 Jul 2012 08:07 zmieniony
Oto wynik po całej nocy z dither=chess i nic więcej.

ilmenit, czy planujesz adresować buga związanego z kolorami? Okazuje się, że nie uzyskam więcej niż 16-bit na desktopie, a gdybym od razu widział, że zmierzamy w kierunku niebieskiego, to oszczędziłbym całą noc pracy śmigła nad procesorem :)

Źródło:

Output:

Xex w załączniku.
- 20:
  
  CommentAuthorxeen
- CommentTime27 Jul 2012 10:07 zmieniony
i ja też liczyłem - tym razem na tapetę wziąłem demko Batman Forever z CPC. Co ciekawe te rysunki na Amstradzie to mózgotrzepy - jakby trochę dobrać parametry to na A8 mogłyby wyglądać lepiej bez interlace'u.

Sorki z brak xex - w robocie liczę to nie generuję xexów ;)

Fajnie RC odwzorował JPG'owe artefakty ;) Dzięki temu powietrze w drugim rysunku jest jakby naelektyrzowane - side effect
Oba rysunki z rangem powyżej 12.
- 21: CommentAuthorurborg
- CommentTime29 Jul 2012 06:07 zmieniony
Tez postanowiłem wypróbować ów genialny program. Oto pierwszy przeliczony obrazek. Nic nie gmerałem w parametrach uruchomiłem na domyślnych zdefiniowanych w pliku test.bat. Efekt obliczeń wygląda tak:

żródło:

Obrazek wynikowy:
- 22: CommentAuthorilmenit
- CommentTime30 Jul 2012 10:07 zmieniony
W ramach dyskusji o wykorzystaniu przez grafików konwerterów do uproszczenia pracy...
Próba konwersji Oozowego obrazka w 5 kolorowym trybie znakowym z duszkami do 4 kolorowego graficznego używanego aktualnie przez RC.

Wejście:

Wyjście:
- 23:
  
  CommentAuthorjhusak
- CommentTime30 Jul 2012 15:07
Nie widzę różnicy.
- 24: CommentAuthorBluki
- CommentTime30 Jul 2012 15:07 zmieniony
Drobne różnice jednak są.
- anigif.gif
- 25: CommentAuthorgorgh
- CommentTime30 Jul 2012 15:07
oj tam, naprawde drobne roznice. IMO jesli ten program tak dobrze konwertuje grafike w oryginalnej rozdzielczosci, to jest to wrecz swietne narzedzie do konwersji wypixelowanej grafiki w jakims programie pecetowym, z uwzglednieniem ograniczen RC. Korci mnie,zeby cos przygotowac na sv przy uzyciu tego programu
- 26: CommentAuthorilmenit
- CommentTime31 Jul 2012 11:07 zmieniony
Nie licząc wciąż nie poprawionego błędu z repozycjonowaniem duszków w RC (widoczne czarne piskele w kilku miejscach na ekranie na obrazku Egg w wynikowym xex), to efekt konwersji nowej pracy Piesia jest zaskakująco niezły. Konwersja była na podstawie obrazka zamieszczonego pierwotnie w palecie innej niż g2f.act. Nie byłem w stanie określić jaka to była dokładnie paleta, więc wybrałem paletę z Altirry, która ma m.in. bardziej soczystą zieleń.

CmdLine: egg.png /filter=box /predistance=euclid /s=10000 /distance=ciede
Evaluations: 306 497 122

I jeszcze skonwertowany Witraż. Też nie wiedziałem w jakiej palecie jest oryginał, więc kolory wygenerowane są inne.
- egg.png
- egg.xex
- witraz.png
- witraz.xex
- 27: CommentAuthorcobra_c64
- CommentTime31 Jul 2012 11:07
teraz widać jak powstają niektóre grafiki na atari:) Convert is not good.
- 28:
  
  CommentAuthorDracon
- CommentTime31 Jul 2012 13:07 zmieniony
Kasiu, mi wyglada na to, ze Piesiu zrobil to jak zwykle - wypikslowal ladnie na edytorze lores pod PC (GrafX2), dorzucil dodatkowe kolory w G2F i voila. :)
Haslo "convert is not good" pasuje bardziej do naszych braci commodorowcow, bo jesli prawda jest jakoby mieli oni w obecnych czasach operowac na gotowych zdjeciach (jakby na bazie tego wgranego dorysowywali cos od siebie co daje ponizej 50% wlasnego wkladu) to wlos sie jezy...

A o sile i doskonalosci RC mowia pokazywane tu wyniki - algorytm jest naprawde dobrze wymyslony skoro tak wiernie potrafi oddac pliki zrodlowy (jak na mozliwosci Atari w trybie bez migania). :)
- 29: CommentAuthorilmenit
- CommentTime31 Jul 2012 13:07 zmieniony
A najlepiej RC oddaje obrazki takie, które można wyświetlić na Atari, czyli np. przygotowane w G2F ;)

GIFowa animacja z różnicami:
- aS2oqZ1343733974.gif
- 30:
  
  CommentAuthorMaW
- CommentTime31 Jul 2012 13:07
A jak oddaje obrazki skonwertowane przez konwerter? Jeżeli tylko takie są bez różnic, to w prosty sposób można by weryfikować, które są wieloetapowymi konwersjami :).
- 31: CommentAuthorilmenit
- CommentTime31 Jul 2012 13:07
Pomysł dobry, ale algorytm optymalizacji wykorzystany w konwerterze z założenia jest niedeterministyczny, więc tym sposobem się nie da :)
- 32: CommentAuthormono
- CommentTime31 Jul 2012 13:07
Czyli za każdą próbą może wyjść co innego?
- 33: CommentAuthorilmenit
- CommentTime31 Jul 2012 14:07
A nawet powinno wyjść co innego. Chyba, że ustali się ten sam /seed dla generatora liczb pseudolosowych, ale wtedy wystarczy zmienić choć jeden piksel obrazka i znów uzyskamy co innego.
- 34:
  
  CommentAuthorDracon
- CommentTime31 Jul 2012 14:07
Czy jest tu gdzies na forum czy stronie FAQ ze wskazowkami czy sugestiami ustawien dla danych grafik/zdjec? Chodzi o jedno takie miejsce gdzie uzytkownicy podaja swoje ulubione... parametry a czas cenny czas poswiecony takiej konwersji.
Program szybko ewoluuje a nie wszystko da sie zalapac od razy przy takim bogactwie ustawien. :|

Jak sobie RC radzi z konwersja czegos na hires?
- 35: CommentAuthorilmenit
- CommentTime31 Jul 2012 14:07 zmieniony
1. Warto przeczytać help.txt
2. FAQ nie ma. Najwięcej informacji było w wątku ->link<- na AtariAge.
3. Parametry trzeba dobierać eksperymentalnie, bo zależą od obrazka. Warto zacząć z "number of solutions" 1, a gdy zobaczymy, że program osiąga niezłe efekty, to warto go uruchomić z np. /s=10000 - po ok. 100 mln iteracji efekt będzie znacznie lepszy niż dla /s=1.
4. Obsługi innych trybów (np. hires) nie ma. Żródła są na GitHubie, więc będzie, jak ktoś doda :-) Aby konwerter działał dobrze musi mieć zaimplementowaną perfekcyjnie emulację ANTICa w danym trybie. Plus jeżeli konwerter ma działać szybko, to wykonanie programu rastra trzeba bardzo optymalizować.
5. ->link<- :)
- 36: CommentAuthorvega
- CommentTime31 Jul 2012 17:07
śledzę ten wątek na bieżąco i jestem pod wrażeniem nie sądziłem, że da się stworzyć tak doskonałe narzędzie konwersji..niby jest te 128kolorów(256 czasami) i inne fajne rzeczy na ATARI ale jest mnóstwo ograniczeń..obejście ich pozwala na tworzenie nawet lepszej grafy niż na C64...ale zabiera to tyle czasu, że masakra...a teraz można to szybko i ekspresowo skonwertować...no i jeszcze jakby dało się dopracować szczegóły pod G2F..to już miazga będzie...
- 37: CommentAuthorSamarexus
- CommentTime31 Jul 2012 18:07
Te konwerty z ZX-a mają jakby commodorowską paletę..?(fiolety)
- 38:
  
  CommentAuthorTheFender
- CommentTime31 Jul 2012 21:07 zmieniony
No wyglądają komodziarsko. Pewnie przez fiolety, ale najpewniej przez ten seledynowy żółty ;)

@vega: szybko i ekspresowo powiadasz. A czytałeś wątek od początku ? :)
- 39: CommentAuthorilmenit
- CommentTime1 Aug 2012 10:08 zmieniony
Co do szybkości, to chyba tylko inny programista zrozumie jak złożony obliczeniowo jest to problem... Wciąż mam więcej pomysłów na przyspieszenie do przetestowania niż czasu na ich realizację. Najsensowniejsze wydaje się próbowanie modyfikacji obrazka tam, gdzie jest największy błąd, ale wykonane już próby zwiększenia prawdopodobieństwa wyboru linii do mutacji na podstawie błędu powodowały, że algorytm bardzo zwalniał. Aby poprawić jedną linię często trzeba poprzestawiać rejestry wiele linii wcześniej.

O ile dobrze szacuję ->link<- podejście sprawdzające wszystkie możliwe ustawienia kolorów i duszków za pomocą 3 rejestrów w programie rastra ma 805^4080 kombinacji. Bez komputera kwantowego czas potrzebny na to byłby znacznie większy niż długość istnienia wszechświata, zatem jak chodzi o szybkość szukania rozwiazania to nie jest źle :-)

"Te konwerty z ZX-a mają jakby commodorowską paletę..?(fiolety)"

Fiolety są z powodu wybranej odległości kolorów /predistance=ciede ->link<- . Dla obrazków ze Spectruma, które mają duże nasycenie barw znacznie lepsze efekty da /predistance=yuv lub /predistance=euclid.

Poniżej jak wygląda konwersja z wybranymi poszczególnymi odległościami kolorów. Dla CIEDE widać, że przy konwersji do palety Atari jest spory zasięg kolorów pokrywanych fioletem (lewy-dół obrazka).

CIEDE2000 sprawdza się nieźle dla większości obrazków z palet ponad 8bit, ponieważ podbija nasycenie zbyt szarych kolorów przy redukcji palety do palety Atari (prawa-góra obrazka).

Oryginał:

CIEDE:

EUCLID:

YUV:
- 40:
  
  CommentAuthorjhusak
- CommentTime1 Aug 2012 12:08
I od razu wszystko jasne :)
- 41:
  
  CommentAuthorxeen
- CommentTime2 Aug 2012 09:08 zmieniony
fajny opis, Ilmenit, trzeba to chyba przenieść do jakiegoś FAQ.

A to moje zabawy z macro zdjęciami
Jakby ktoś mi pokazał takie obrazki w latach 80-90 huh....
- mak-src.png
- mak.png
- dot-src.png
- dot.png
- ins-src.png
- ins.png
- 42: CommentAuthorcobra_c64
- CommentTime2 Aug 2012 11:08
Dracon:zgadzam się z tobą w zupełności!
- 43: CommentAuthormono
- CommentTime2 Aug 2012 15:08
Genialnie wyszły oczy tej małej! Bardzo szczegółowo. Ale to w sumie nie powinno dziwić, gdyż Insert i Irwin pokazywali w swoich pracach jakie detale da się wycisnąć na Atari.
- 44: CommentAuthorilmenit
- CommentTime2 Aug 2012 16:08 zmieniony
Wstępna wersja FAQ:
->link<-
- 45: CommentAuthorjury
- CommentTime2 Aug 2012 17:08
xeen:
Jakby ktoś mi pokazał takie obrazki w latach 80-90 huh....

No raczej marnie to widzę aby RastaConverter z jednym obrazkiem wyrobił się w ciągu miesiąca na komputerach z lat 80tych czy nawet 90tych ;)
- 46:
  
  CommentAuthormiker
- CommentTime2 Aug 2012 20:08
xeen: daj binarki tego, co? :)
- 47:
  
  CommentAuthorxeen
- CommentTime2 Aug 2012 21:08
jury - no jasne, ale w latach 80/90 jakiś mega cyborg mógłby napisać taki program ręcznie ;)

miker - sorki, ni mom - kasuje bo to tylko takie próby:(
ja w robocie to liczę bo takiego kompa tam mam, że się proc nudzi to mu zapuszczam konwersje i nie generuję xexów z tego

następnym razem chociaż zachowam źródła dla zainteresowanych...
- 48:
  
  CommentAuthormiker
- CommentTime2 Aug 2012 21:08
No to po konwersji skopiuj do podkatalogu "Generator" pliki "output.png" oraz "output.png.*" i odpal build.bat. Jak wyszło - sprawdzisz już potem w domciu. :)
- 49:
  
  CommentAuthorjhusak
- CommentTime3 Aug 2012 03:08
łatwo policzyć. Komputery w 90 latach miały megaherce, teraz gigaherce. Wówczas rządził 386 amigi i esteki. 386 miał dajmy na to 25-40 MHz, to przy dzisiejszych I7 jest 1000 razy wolniej.

Czyli jeśli programik dziś działa godzinę, wtedy by to samo liczył 1000 godzin, a to jest 6 tygodni. A jeśli miałby liczyć 2 godziny dzisiaj, to już bity kwartał wtedy. Oczywiście, c++ raczkował, któlował c, i w takim języku ktoś by to napisał.

Z kolei lata 80 to xteki. o podobnej szybkości, co Z80, łątwo wyliczyć, że już by szło w lata.

Pomijając fakt, że wtedy komputer xt miał max 640 kb pamięci. Teraz dowolny komputer ma 5000 razy więcej :)

Z czego 50% tej pamięci zajmuje system operacyjny, wtedy zajmował zdecydowanie mniej, niż połowę.

Trochę naginam :P
- 50:
  
  CommentAuthorxeen
- CommentTime3 Aug 2012 10:08 zmieniony
i kolejne

Od 151 do 200 z 919