atarionline.pl RastaConverter by Jakub Dębski - Forum Atarum

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.

2. Grafika / Graphics  »   RastaConverter by Jakub Dębski

W dół

Od 151 do 200 z 911

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. ...
  11. 19
  12. >
    • 1: CommentAuthornosty
    • CommentTime25 Jul 2012
     
    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 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 zmieniony
     
    4 miliardy iteracji, ładnych parę dni na niezłym kompie


    • 4:
       
      CommentAuthorDracon
    • CommentTime25 Jul 2012
     
    @Xeen.
    Kolory niezle, ale az sie prosi aby zastosowac jakis (inny?) sprytny algorytm ditheringu albo wstepnie lekko zredukowac palete... :)
    • 5: CommentAuthorilmenit
    • CommentTime25 Jul 2012
     
    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.  
    Kto pomoże z konwersją obrazka z załącznika? Mi zawsze wyłazi cały niebieski :(
    • 7: CommentAuthorilmenit
    • CommentTime25 Jul 2012
     
    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 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 :)
    • 9: CommentAuthorilmenit
    • CommentTime25 Jul 2012
     
    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 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
     
    Ilu bitową masz ustawioną paletę barw w systemie?
    • 12: CommentAuthornosty
    • CommentTime26 Jul 2012
     
    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 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 ;)
  14.  
    @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 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
     
    Jak na konwersje ze spectrumowego "hires" na atarowski lowres calkiem niezle. Do pelni szczescia brakowaloby oczywiscie pewnej edycji koncowej...
    • 17:
       
      CommentAuthorxeen
    • CommentTime26 Jul 2012 zmieniony
     
    znana, świetna praca Piesia z ST (SV2K11)
    krótko to liczyłem, ale moim zdaniem wygląda nieźle



    • 18: CommentAuthorilmenit
    • CommentTime26 Jul 2012
     
    A gdzie xex? :)
    • 19:
       
      CommentAuthormgr_inz_rafal
    • CommentTime27 Jul 2012 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 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 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 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
     
    Nie widzę różnicy.
    • 24: CommentAuthorBluki
    • CommentTime30 Jul 2012 zmieniony
     
    Drobne różnice jednak są.

    • 25: CommentAuthorgorgh
    • CommentTime30 Jul 2012
     
    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 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.

    • 27: CommentAuthorcobra_c64
    • CommentTime31 Jul 2012
     
    teraz widać jak powstają niektóre grafiki na atari:) Convert is not good.
    • 28:
       
      CommentAuthorDracon
    • CommentTime31 Jul 2012 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 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:
    • 30:
       
      CommentAuthorMaW
    • CommentTime31 Jul 2012
     
    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
     
    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
     
    Czyli za każdą próbą może wyjść co innego?
    • 33: CommentAuthorilmenit
    • CommentTime31 Jul 2012
     
    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
     
    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 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
     
    ś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
     
    Te konwerty z ZX-a mają jakby commodorowską paletę..?(fiolety)
    • 38:
       
      CommentAuthorTheFender
    • CommentTime31 Jul 2012 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 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
     
    I od razu wszystko jasne :)
    • 41:
       
      CommentAuthorxeen
    • CommentTime2 Aug 2012 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....






    • 42: CommentAuthorcobra_c64
    • CommentTime2 Aug 2012
     
    Dracon:zgadzam się z tobą w zupełności!
    • 43: CommentAuthormono
    • CommentTime2 Aug 2012
     
    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 zmieniony
     
    Wstępna wersja FAQ:
    ->link<-
    • 45: CommentAuthorjury
    • CommentTime2 Aug 2012
     

    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
     
    xeen: daj binarki tego, co? :)
    • 47:
       
      CommentAuthorxeen
    • CommentTime2 Aug 2012
     
    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
     
    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
     
    ł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 zmieniony
     

Od 151 do 200 z 911

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10. ...
  11. 19
  12. >