14.03.2016 02:56
[#1]
Ham 8 na gołej 1200/cd32
Mikrobi
autor wątku
autor wątku
Witam.
Czy obrazek ham8 da się wyświetlić szybko i bez artefaktów na gołej a1200/cd32 ?
Czy jest jeszcze lepsza metoda dla takich maszyn np. .PNG?
Czy obrazek ham8 da się wyświetlić szybko i bez artefaktów na gołej a1200/cd32 ?
Czy jest jeszcze lepsza metoda dla takich maszyn np. .PNG?
15.03.2016 22:17
[#5]
Re: Ham 8 na gołej 1200/cd32
@Mikrobi, post #1
Czy obrazek ham8 da się wyświetlić szybko i bez artefaktów na gołej a1200
Nie.
Tryby HAM mają to do siebie, że "artefakty" (czy też tzw. efekt "rampy") występują zawsze. Czasem w mniejszym, czasem w większym stopniu. Dlaczego? Szczegóły tutaj. Co więcej - tryb ten jest zasobożerny. Jak jeszcze miałem klasyka z Apollo 040/40 to visage wyświetlający na AGA zdjęcia JPG w tym trybie + przyzwoita rozdzielczość = zdjęcie ładujące się kilka sekund. Na "golasie" będzie zdecydowanie gorzej. No ale zawsze możesz pociąć rozdzielczość, albo zrenderować obrazek do palety 256 kolorów, albo jedno i drugie...
16.03.2016 07:04
[#10]
Re: Ham 8 na gołej 1200/cd32
@Hexmage960, post #9
Jak ręcznie pikselujesz to masz kontrolę nad tym co robisz, a jak zapuścisz jakiś automat konwertujący do HAM to uzyskasz coś takiego jak na tym filmie.
16.03.2016 07:39
[#11]
Re: Ham 8 na gołej 1200/cd32
@Hexmage960, post #9
Photogenics ma male artefakty bo redukuje rozdzielczosc wyswietlanej grafiki. Kazdy "piksel" wyswietlany jest jako 2 (z tego co pamietam). Cos za cos.
Ogolnie wszystko zalezy. Jezeli mamy aplikacje okienkowa to trzeba robic tak jak photogenics czyli poswiecic rozdzielczosc albo robic rendering po kazdej operacji przesuniecia okna aby "naprawic" krawedzie. To samo przy przewijaniu grafiki wiekszej niz ekran przy wyswietlaniu pelnoekranowym. Trzeba "naprawic" lewa krawedz.
Ogolnie wszystko zalezy. Jezeli mamy aplikacje okienkowa to trzeba robic tak jak photogenics czyli poswiecic rozdzielczosc albo robic rendering po kazdej operacji przesuniecia okna aby "naprawic" krawedzie. To samo przy przewijaniu grafiki wiekszej niz ekran przy wyswietlaniu pelnoekranowym. Trzeba "naprawic" lewa krawedz.
16.03.2016 08:39
[#12]
Re: Ham 8 na gołej 1200/cd32
@] SKOLMAN_MWS ˇ agrEssOr [, post #8
Za starych czasów na gołej A1200 używałem głównie Visage (był w miarę szybki i miał spore możliwości).
Najlepiej ustawić bestbode + scalowanie do wielkości ekranu. Zyskamy na szybkości i pozbędziemy się artefaktów przy przesówaniu ekranu, no i oszczędzimy w przypadku "bardzo" dużych obrazów CHIP ram.
Mikrobi przyjacielu, HAM8 do oglądania obrazków naprawdę daje radę
Ostatnia aktualizacja: 16.03.2016 08:41:14 przez BULI
Najlepiej ustawić bestbode + scalowanie do wielkości ekranu. Zyskamy na szybkości i pozbędziemy się artefaktów przy przesówaniu ekranu, no i oszczędzimy w przypadku "bardzo" dużych obrazów CHIP ram.
Mikrobi przyjacielu, HAM8 do oglądania obrazków naprawdę daje radę
Ostatnia aktualizacja: 16.03.2016 08:41:14 przez BULI
16.03.2016 15:22
[#14]
Re: Ham 8 na gołej 1200/cd32
@Mikrobi, post #13
bo w demach na ocs ponoć wyciskają 15bit paletę.
Że te 4tysie wyciskają to jasne, ale żeby aż 32 tysiące?!- Chętnie bym to sprawdził/ zobaczył
W poście wyżej wkradła się literówka, miało być oczywiście "bestmode" dla VISAGE
Ostatnia aktualizacja: 16.03.2016 15:24:07 przez BULI
16.03.2016 20:03
[#17]
Re: Ham 8 na gołej 1200/cd32
@Mikrobi, post #16
Myślałem że te "artefakty" czyli jak rozumiem takie poziome kreski w dziwnym kolorze wyświetla tylko gdy obrazek stworzony na Overscan wyświetlasz w trybie z tak samo dużymi pikselami, ale bez overscanu i możesz wtedy oglądać i przesuwać przez okienko standardowej rozdzielczości choć obrazek jest szerszy i momentami zwłaszcza przy gładkich powierzchniach po lewej stronie ekranu widać takie dziwne kreski. I jest tak w obu HAMach. No chyba że nasz "pokazywajka" skaluje go do aktualnej rozdziałki, ale wtedy wyświetla się wolniej. Choć nie aż tak wolno jak jpg.
16.03.2016 20:50
[#18]
Re: Ham 8 na gołej 1200/cd32
@ZbyniuR, post #17
Poziome kreski to jest eskalacja. Rampa to jedno/kilkupikselowa "obwódka" szczególnie widoczna na kontrastowych kolorach, sprawiająca że obraz wygląda na dziwnie "zblurowany". Zobacz sobie ten obrazek:
Na krawędzi "kartki", na oku, na piórach, na ziemi... Popatrz zresztą na paletę. Większość kolorów (w tym wybrany kolor "tła") ma tam rampę.
Na krawędzi "kartki", na oku, na piórach, na ziemi... Popatrz zresztą na paletę. Większość kolorów (w tym wybrany kolor "tła") ma tam rampę.
17.03.2016 09:11
[#19]
Re: Ham 8 na gołej 1200/cd32
@recedent, post #5
Absolutnie się z tym nie zgadzam. Artefakty istnieją zawsze, ale trzeba je odpowiednio rozróżnić.
Na początek tzw. rampa. Jest to efekt, który ciągnie się za Amigą od samego początku, urósł do rangi mitu, a wieki temu został wyeliminowany. Występował przy rysowaniu archaicznymi programami typu Diamond czy PhotonPaint. TrueBrilliance oraz DPaint pokazały, że można rysować bez rampy, nieco wolniej, ale jednak.
Pozostałe artefakty występują w wyniku kwantyzacji kolorów, występują one jednak we wszystkich trybach indeksowanych, jednak dobrze wyrenderowany HAM8 zawsze będzie bardziej przybliżał 24-bitowy oryginał niż obrazek z 256 kolorami.
Kluczem jest tu słowo dobrze. Dobry rendering do HAM wymaga stworzenia dobrej palety podstawowej, ale też można wyświetlać HAM nie tworząc żadnej palety. Tutaj kroczymy na krawędzi szybkość i jakość renderingu. Z wyniku tego otrzymujemy ostatni rodzaj artefaktów występujący głównie na ostrych krawędziach. Jak pokazuje doświadczenie, większość wyświetlaczek renderuje HAM źle. Faktycznie najlepiej robi to v meynafa, ale można wyświetlić HAM jescze lepiej kosztem szybkości, za to bez tego typu artefaktów.
Wg mnie jedynie wybór algorytmu determinuje występowanie artefaktów, które można całkowicie wyeliminować za wyjątkiem błędów kwantyzacji.
W czym HAM8 jest bardziej zasobożerny od 256 kolorów zwłaszcza przy wyświetlaniu jpegów?
Na początek tzw. rampa. Jest to efekt, który ciągnie się za Amigą od samego początku, urósł do rangi mitu, a wieki temu został wyeliminowany. Występował przy rysowaniu archaicznymi programami typu Diamond czy PhotonPaint. TrueBrilliance oraz DPaint pokazały, że można rysować bez rampy, nieco wolniej, ale jednak.
Pozostałe artefakty występują w wyniku kwantyzacji kolorów, występują one jednak we wszystkich trybach indeksowanych, jednak dobrze wyrenderowany HAM8 zawsze będzie bardziej przybliżał 24-bitowy oryginał niż obrazek z 256 kolorami.
Kluczem jest tu słowo dobrze. Dobry rendering do HAM wymaga stworzenia dobrej palety podstawowej, ale też można wyświetlać HAM nie tworząc żadnej palety. Tutaj kroczymy na krawędzi szybkość i jakość renderingu. Z wyniku tego otrzymujemy ostatni rodzaj artefaktów występujący głównie na ostrych krawędziach. Jak pokazuje doświadczenie, większość wyświetlaczek renderuje HAM źle. Faktycznie najlepiej robi to v meynafa, ale można wyświetlić HAM jescze lepiej kosztem szybkości, za to bez tego typu artefaktów.
Wg mnie jedynie wybór algorytmu determinuje występowanie artefaktów, które można całkowicie wyeliminować za wyjątkiem błędów kwantyzacji.
W czym HAM8 jest bardziej zasobożerny od 256 kolorów zwłaszcza przy wyświetlaniu jpegów?
17.03.2016 11:16
[#21]
Re: Ham 8 na gołej 1200/cd32
@cholok, post #19
W tym wątku na http://eab.abime.net/showthread.php?t=50417 jest mowa o tym v meynafa, przyznam, że nie słyszałem o nim- trzeba sprawdzić
Ja pisałem o artefaktach, które pamiętam pojawiały się przy przewijaniu obrazków (chociaż pamięć lubi płatać figle, jak teraz o tym myślę to mogły chodzić o artefakty związane z zmianą palety w momencie wywoływania menu, co było by w tym przypadku uzasadnione).
Ostatnia aktualizacja: 17.03.2016 11:21:31 przez BULI
Ja pisałem o artefaktach, które pamiętam pojawiały się przy przewijaniu obrazków (chociaż pamięć lubi płatać figle, jak teraz o tym myślę to mogły chodzić o artefakty związane z zmianą palety w momencie wywoływania menu, co było by w tym przypadku uzasadnione).
Ostatnia aktualizacja: 17.03.2016 11:21:31 przez BULI
17.03.2016 11:36
[#22]
Re: Ham 8 na gołej 1200/cd32
@BULI, post #21
Otwieranie menu to dokladnie ten sam przypadek co przewijanie calego ekranu. Po prostu pojawia sie kolumna pikseli ktore psuja obraz przez to, ze piksel n zalezy od piksela n-1. Jedyne wyjscie to odrysowanie obrazu 'po prawej stronie' po kazdej takiej modyfikacji.
Oczywiscie to jest sytuacja kiedy chcemy miec ham w dobrej jakosci/rozdzielczosci. Mozna zrobic tak jak photogenics ktory po prostu generowal szerokie piksele (poswiecal rozdzielczosc) w taki sposob, ze piksel o kolorze branym z palety byl najdalej 2 (albo 3, nie pamietam) piksele w lewo przez co maksymalna rampa miala dlugosc 2(3) pikseli.
Ostatnia aktualizacja: 17.03.2016 11:38:46 przez kiero
Oczywiscie to jest sytuacja kiedy chcemy miec ham w dobrej jakosci/rozdzielczosci. Mozna zrobic tak jak photogenics ktory po prostu generowal szerokie piksele (poswiecal rozdzielczosc) w taki sposob, ze piksel o kolorze branym z palety byl najdalej 2 (albo 3, nie pamietam) piksele w lewo przez co maksymalna rampa miala dlugosc 2(3) pikseli.
Ostatnia aktualizacja: 17.03.2016 11:38:46 przez kiero
No, ale nie ta kobieta.