zauważyłem, że prekalkulacja dither = knoll działa znacząco szybciej na winXP na słabszym kompie vs na win7 na kompie znacznie potężniejszym. brak związku z wątkiem, ale wtf?
yep. i to jest dziwne. win64 bit mnie zaszokował - same kalkulacje już są ok 3 razy szybsze niż na tym sprzęcie poprzednim które prekalk dithera robi w mgnieniu oka. może to kwestia jakiejś biblioteki zewnętrznej? nie wiem - taka "ciekawostka"
a dzisiaj w nocy (400 mln iteracji) wyszło to. nie ustawiałem masek, a zadziałał tak, jakby detale miały iść na tło, a postać ma niższy priorytet. ciekawe... pobawię się maskami tu.
W pliku wykonywalnym widać wciąż nie poprawiony błąd związany z repozycjonowaniem duszków (pozioma linia na wysokości ust).
Tu bez silnej maski detali się nie obejdzie (/details_val=10?). Obrazek jest niezłym przykładem, jak bardzo maska jest czasem konieczna. Dla komputera bardziej istotne jest tło, ponieważ jest tam więcej podobnych kolorów. Zatem lepsze jest tam umieszczenie większej liczby kolorów, aby suma odległości kolorów obrazka była mniejsza. Dla człowieka istotne są detale: - na pierwszym planie - na ludziach - na twarzach (tu najwięcej) - w centrum obrazka, szczególnie, gdy fotorealistyczny.
Tak. W dowolnym programie graficznym, najwygodniej w takim z warstwami. Ostatnio o maskach pisałem też tutaj: ->link<-
@xeen - im jaśniej, tym więcej detali tam chcemy. Ale i tak super efektów bym się przy tym obrazku nie spodziewał. Na same odcienie skóry potrzeba 3-4 kolory.
no ale zerknę z ciekawości i ustawię te maski - zobaczymy jak to wyjdzie. Obrazki lazura tracą najwięcej na konwersji rozdziałki, trudno coś z tego wyciągnąć....
Używa łagodnych przejść kolorów, a na każdy odcień potrzebny jest kolor. Pomógłaby może redukcja palety z silnym ditheringiem. Też zapuściłem konwersję z parametrami: CmdLine: lzr2-src.png /pal=laoo /dither=knoll /h=200 /details=lzr2-src-details.png /details_val=12 /s=20000
->link<- zrobiłem konwersję grafik z 8bit Atari na Plus/4. Tylko Ooz i Piesiu. W przypadku jednego z obrazków Ooza totalnie przerobiłem kolory (sory za to), ale chciałem zobaczyć jak to wyjdzie. jak ktoś chce to odpalać to tylko na yape albo plus4emu. na vice nie pójdzie.
Carrion, fajne eksperymenty. Czy na +4 sa to tryby solid czy interlace? Postuluje zalozenie nowego watku, bo pewnie jeszcze nie raz bedziesz chcial pokazac jakies eksperymenty tego typu.
I jeszcze prosba - czy mozesz zrobic zdjecia z prawdziwego sprzetu, masz taka mozliwosc? Ciekawi mnie, jak to naprawde wyglada, bo emulatory wiadomo - zawsze rzeczywistosc podkolorowuja :)
zrobię zdjęcia albo filmik na yt jutro. na monitorze wygląda nawet dużo lepiej niż na yape. 160x200 oczwyiście nie migają i są zbliżone do multicoloru z c64 tyle że masz 121 kolorów. do tego są oczywiście softwareowe tryby jak FLI gdzie masz co linię (albo dwie nie pamiętam) zmieniane kolory co daje w zasadzie swobodę pixlowania bez restrykcji... stąd te konwerty wychodzą idealnie jak na atari. przy żadnym konwercie nie spędziłem więcej niż 5 min. tylko przy tym ograzku ooza z c64 się trochę pobawiłem. btw można osiągnąć z tego co widzę max 248 lini w pioie. robi się to podobno łatwo a nie tak jak na c64. podobał mi się tekst w którymś chartari (#! chyba) gdzie jakiś grafik z atari prównywał tryby graficzne 8bitówek. wybrał +4 jako ten o największych możliwościach. i tak też jest IMO. załóż wątek - będzie mi miło, choć zamierzam chwilowo zrobić przerwę z tematami okołosceowymi.
ja zrobiłem trochę inną maskę - porównamy wyniki - właśnie zapuściłem z analogicznymi parametrami. a w nocy liczłem jeszcze coś co nie mogło się udać :) distance na poziomie 40 przy 0.5 mld iteracji :) ale w sumie coś widać .....
Obrazek z maską detali. Powinna być ciut inaczej zrobiona, bo zanikła zieleń między palcami przy tak dużym /details_val. Postać wygląda znacznie lepiej, ale brakuje na obrazku detali tła.
@xeen: W sumie wygląda podobnie. Obydwa obrazki wynikowe trzeba by poedytować w G2F... ;-)
Przy okazji inny obrazek, wykorzystujący nowy typ ditheringu, który pojawi się w następnej wersji:
oraz
Dithering nazwany przeze mnie liniowym przerzuca błąd piksela do piksela poniżej, przez co w aktualnej linii nie są generowane dodatkowe kolory. Znacznie lepiej odpowiada on możlwościom sprzętowym Atari i rozmyciu PAL.
Abstrahujac jednak od nowej metody ditheringu, to Twoje obrazki ilmenit zawsze sa najladniej przekonwertowane... Z czego wniosek, ze lepiej sobie radzisz z rozumieniem co i jak. Warto by chyba jakis poradnik trzasnac, bo 90% obrazkow konwertowanych przez osoby, ktore nie maja ksywy Ilmenit, jest znacznie gorsze.
I to tez jest istotna uwaga, ktora powinna sie znalezc w jakims zbiorczym FAQ :)
Jezeli bylbys laskaw przekleic wszystkie uwagi tego typu z wszystkich forum, na ktorych takie poradnikowe uwagi padaly, w jedno miejsce - to podejme sie opracowania tego w formie ladnej, ilustrowanej i strawnej dla amatora-nieprogramisty.
Chodzi tu chyba o FAQ w ojczystym języku i wszystko w jednym miejscu. Np.
Pyt. Czy trzeba jej jakoś wstępnie obrabiać obrazek (reskalować, obniżać ilość kolorów) aby program nieco szybko działał (przeliczał) ?
Odp. Zdecydowanie tak! I nie chodzi o szybkość działania, ale o efekt końcowy. Najlepiej sobie (ja tak przynajmniej robię) oryginalny obrazek przeskalować w jakimś programie graficznym do rozdzielczości 320x240 (nie 160x240!), zredukować liczbę kolorów do np. 256, wprowadzić ręcznie poprawki, i dopiero taką grafikę zapisaną w pliku BMP (JPG to stratny zapis i mogą pojawić się niechciane piksele) dać do obróbki przez RC. W RCGUI dobieramy paletę, skalowanie oraz parametry Preprocess, aby obrazek wyjściowy był najlepszy z możliwych (klikamy na Preprocess preview). Jak uzyskamy w miarę poprawne kolory i efekt, który nam odpowiada, to kopiujemy obrazek "output.png-dst.png" (to jest ten obrazek wyjściowy, który uzyskaliśmy przed chwilą) i zmieniamy mu nazwę na np. "input.png". Wczytujemy do programu graficznego, PIKSELUJEMY RĘCZNIE zwracając uwagę, żeby zmieniać dwa piksele obok siebie (Atari ma piksele prostokątne, a PC widzi je jak dwa kwadratowe obok siebie). Tak dopieszczony obrazek wczytujemy do RC, ale już jako obrazek wejściowy! Ustawiamy parametry (czasami warto zmienić "resize filter" na "box" i włączamy preprocess i jeśli nie ma uwag, to włączamy konwersję. I kto powiedział, że RC zabija proces twórczy?! ;)
Pyt. Czy można już konwertować "etapowo" czyli zapuszczę sprzęt na 2 godziny, później go wyłączam, po czym następnego dnia mogę kontynuować obliczenia bez powtarzania od początku?
Odp. Oczywiście, że tak. Jak musisz przerwać pracę RC, to zamykasz okienko (no i RCGUI) i już. Później uruchamiasz RCGUI i TYLKO klikasz na "Continue stopped conversion" - RC zacznie pracować od momentu przerwania (generuje ponownie jedynie obrazek wyjściowy, ale to nic nie zmienia).
Zawarłem tu swoje pytania i odpowiedzi Larka, mam nadzieję, że mi wybaczy... ;)
takie tam, w sumie jak się trochę pokonwertuje, to można wyczuć jaki, mniej więcej, będzie efekt końcowy. Tutaj jeszcze dodatkowo obczaiłem jakwychodza konwerty prac rysowanych ołówkiem / kredką.
kiedyś Piesiu popełnił fajny ekran tytułowy do gry apple invaders. byłem ciekawy jak n iskim nakładem pracy mozna osiągnąć coś podobnego, ale jednak ręka grafika to ręka grafika i żaden konwert nie oddaje tego klimatu:)
Aż nie wiem jak opisać, co ja się namęczyłem z tym obrazkiem... Z RC jest o tyle problem, że do pracy z nim trzeba zdobyć doświadczenie. Cóż, byłoby to znacznie prostsze, gdyby liczył obrazek choć kilkadziesiąt minut, a nie godzin (co w moim przypadku przekłada się na dni). Choć z drugiej strony lepsze godziny niż lata, stulecia, tysiąclecia, czy praktycznie nieskończoność...
Jeśli chodzi o obrazki typu FLI (bodaj), to nie ma lekko, tu niestety trzeba się liczyć ze stratami. Najlepiej by taki obrazek jakoś wstępnie ręcznie przerobić - tylko jak to zrobić? I jak na złość pod sam koniec wyskoczyła mi fatalna wizualna usterka - algorytm wsadził pieskowi "strzałę" w tyłek. Teraz pytanie co robić w takich sytuacjach? Czekać kolejny miliard iteracji aż się może samo naprawi - albo nie? Dodać trochę maski i znowu zacząć liczyć od nowa? Czekać na nowy G2F i spróbować poprawić ręcznie?
Zauważyłem, że maskę można korygować w przerwach między działaniem programu, ale czy to działa prawidłowo - naprawdę nie wiem.
Kończąc moje tradycyjne marudzenie, efekt końcowy można uznać za naprawdę zaskakujący. Choć - znowu zaczynam marudzenie - jestem niemal pewny, że da się to zrobić o wiele lepiej. A może ktoś spróbuje zrobić o wiele lepszą konwersję tego obrazka i podzieli się wiedzą jak to zrobił?
Uwaga! Obrazek najlepiej wygląda na palecie G2F. No ale o swoich problemach z paletami też już tu gdzieś marudziłem.
@xeen: Kolory za radosne - ta zieleń oczojebna plus lazurek w wodzie jak z reklamy hotelu na Malediwach :) Zrób z tego jakieś bagno z pnączami i nie biały dzień a wczesny świt plus mgła snująca się przy gruncie :)
