06.03.2022 12:27
[#1]
DCTV
link
Udostępniam program do konwersji obrazków dctv do ilbm opartego na ReadDCTV. Tu chodzi o źródła, bo zrobiłem analizę dctv.library i odtworzyłem kod konwersji w C. Jest to wersja nieco uproszczona, przez co kod jest bardziej zrozumiały. Starą wersję bliższą oryginałowi, ale też bardziej skomplikowaną udostępniłem kilka lat temu na EAB, aby Toni W. zaimplementował emulację w WinUAE. Zrobił to, ale na odwal i źle, stwierdził, że niski priorytet i kiedyś może skończy. Udostępniłem źródła też autorowi RECOIL. Teraz udostępniam wszystkim. Program wymaga kick 2.0, 020+, iffparse.library.
Odnośnie emulacji DCTV. Nie jest całkiem możliwa, bo dctv.library nie zawiera wszystkich procedur konwersji. DCTVPaint korzysta z trybu luminacji bez koloru. Po zgrabowaniu takiego obrazu biblioteka dctv.library sobie nie radzi z konwersją. Niemniej wyświetlanie kolorowego obrazu jest ok.
Odwieczne pytanie od DCTV: jak to działa i ile to bitów? Przystawka działa w trybie digital composite video, czyli dane luminacji i chrominacji są zespolone. Luminacja ma zakres 64-224, a chrominacje teoretycznie +-127 (w rzeczywistości mniej). To jak widać 24-bity, choć tradycyjnie uważa się, że obraz composite jest 21-bitowy. DCTV pobiera z Amigi sygnał cyfrowy: 4 bity na piksel. Więc otwierając ekran hires mamy 8 bitów na piksel lores. Jest tutaj przesunięcie co linię o piksel hires co daje taki upscaling, czyli obraz trochę lepszy niż lores. To nadal różnica 24 do 8. Trzeba zrobić redukcję analogicznie do NTSC: chrominacje na przemian. Wtedy średnio na piksel potrzebujemy 16 bitów. To nadal za dużo. Konwersja do tego momentu daje bardzo dobry obraz. Redukcję z 16 do 8 bitów robi się dodając chrominację do luminacji ze zmiennym znakiem. To tutaj następuje znaczna utrata jakości. Obraz się rozmywa i traci na konturach. Fakty są takie: ilość danych jest identyczna jak w HAM8, ale jakość zdecydowanie gorsza. Znowuż jakość jest zdecydowanie lepsza niż HAM6 ze względu na większą głębię koloru.
Udostępniam program do konwersji obrazków dctv do ilbm opartego na ReadDCTV. Tu chodzi o źródła, bo zrobiłem analizę dctv.library i odtworzyłem kod konwersji w C. Jest to wersja nieco uproszczona, przez co kod jest bardziej zrozumiały. Starą wersję bliższą oryginałowi, ale też bardziej skomplikowaną udostępniłem kilka lat temu na EAB, aby Toni W. zaimplementował emulację w WinUAE. Zrobił to, ale na odwal i źle, stwierdził, że niski priorytet i kiedyś może skończy. Udostępniłem źródła też autorowi RECOIL. Teraz udostępniam wszystkim. Program wymaga kick 2.0, 020+, iffparse.library.
Odnośnie emulacji DCTV. Nie jest całkiem możliwa, bo dctv.library nie zawiera wszystkich procedur konwersji. DCTVPaint korzysta z trybu luminacji bez koloru. Po zgrabowaniu takiego obrazu biblioteka dctv.library sobie nie radzi z konwersją. Niemniej wyświetlanie kolorowego obrazu jest ok.
Odwieczne pytanie od DCTV: jak to działa i ile to bitów? Przystawka działa w trybie digital composite video, czyli dane luminacji i chrominacji są zespolone. Luminacja ma zakres 64-224, a chrominacje teoretycznie +-127 (w rzeczywistości mniej). To jak widać 24-bity, choć tradycyjnie uważa się, że obraz composite jest 21-bitowy. DCTV pobiera z Amigi sygnał cyfrowy: 4 bity na piksel. Więc otwierając ekran hires mamy 8 bitów na piksel lores. Jest tutaj przesunięcie co linię o piksel hires co daje taki upscaling, czyli obraz trochę lepszy niż lores. To nadal różnica 24 do 8. Trzeba zrobić redukcję analogicznie do NTSC: chrominacje na przemian. Wtedy średnio na piksel potrzebujemy 16 bitów. To nadal za dużo. Konwersja do tego momentu daje bardzo dobry obraz. Redukcję z 16 do 8 bitów robi się dodając chrominację do luminacji ze zmiennym znakiem. To tutaj następuje znaczna utrata jakości. Obraz się rozmywa i traci na konturach. Fakty są takie: ilość danych jest identyczna jak w HAM8, ale jakość zdecydowanie gorsza. Znowuż jakość jest zdecydowanie lepsza niż HAM6 ze względu na większą głębię koloru.
SUPER 
- dzięki 