sonraki »

[eins]

Bence de çok kötü değil, en azından benim kullanım amaçlarım için bir sorun teşkil etmiyor. Ama hazır geliştirme aşamasındayken elimizdeki donanım ile alabileceğimiz en kaliteli sonucu almak için elmizden geleni yapıyor olmamaız doğru olan...

[appiah4]

Sadece küçük bir test yaptım. Normalde bir satırı 720 pixel olarak sample ediyordum. x2 oversampling yaparak, satır başına 1440 sample alıp, bunları peş peşe gelen iki pikseli ortalayarak 720 piksele dönüştürdüm. Bu şekilde biraz iyileşme var.

Özellikle aşağıdaki fotoda, kırmızı okla gösterilen çizgilere bakacak olursak, 720 normal sampling yapıldığında, çizgiler aynı kalınlıkta olduğu halde, bazıları daha kalın, bazıları daha ince görünüyordu. Bu durum kırmızı yuvarlak içine aldığın çizgilerde de belirgin.



x2 oversampling yapıp ortala alınca bu durum büyük ölçüde düzeldi. Ama hala bir aliasing sorunu var. Zira sample edilen pikseller LCD'de aynı sayıda native piksele karşılık gelmiyor. Zoom yapıp bakabilirsiniz. Bizim her bir piksel, LCD'de 3 yada 4 piksele karşılık geliyor. Bu udurumda bazıları daha keskin (3 piksele denke gelenler), bazıları daha bulanık görünüyor.

Bunun tam bir çözümü asla olmayacaktır?  Oversampling (sanırım benim bildiğim adı ile supersampling aslında bu?) bir çözüm, ama bunu yapmanın getirdiği bir latency olacaktır, onu da ölçüp tartmak lazım.  Belki de en iyi seçim tüm ekranı kaplamaya çalışmayıp ilgili görüntü modunu yatay ve dikey olarak 1:2 1:3 vb. ekrana oturtabilecek en uygun katsayıda büyüterek ortalayarak vermek olacak, bunu düşünür müsünüz?

[eins]

Terminolojiyi ben de PDF de okuduğum şekilde yazdım.

The ADCs are configured to run in 4X oversampling mode when decoding composite and S-Video inputs; 2X oversampling is performed for component 525i, 625i, 525P and 625P sources. All other video standards are 1X oversampled. In oversampling the video signals, a reduction in the cost and complexity of external anti aliasing filters can be obtained with the benefit of increased signal to noise ratio
(SNR).

Composite ve S-Video için X4 e kadar oversample yapılabiliyor, ama bizim kullandığımız mod için maksimum x2...

İkinci öneriye ilişkin olarak, düşeyde bir oturtma yapma şansı yok. (strech veya compress anlamında) Çünkü board üzerinde bir RAM olmadığı için bufferlama şansı yok.

Amay yatayda bu yapılabilir. Tabiki bu durumda kullanıcının kendi elindeki monitöre göre manuel bir ayar yapması gerekir. Çünkü şu andaki durum tamamen LCD pikselleri ve video çıkışı arasındaki aliasing sorunu. Yani mesela belkide bu çıkış 4K bir LCD de daha doğru görüntülenebilir.

Benim elimdeki ekran 1920 native çözünürlükte. Her bir Amiga hires pikseli 2.6 LCD pikseline denk geliyor olmalı. Eğer 720x2=1440 şeklinde düşünürsek ve her satıra 1920-1440=480/2=240 piksel sağdan ve soldaqn boşluk bırakılırsa ve biraz ince ayar yapılırsa benim elimdeki ekrana oldukça düzgün oturabilir. Her iki native LCD pikseli bir Amiga pikseline karşılık gelmiş olur.

Bunu da deneriz...

[eins]

Yazmayı unuttum. Tabiki bu durumda piksel aspect ratio bozulmuş olacak. Pikseller daha ince uzun olacaktır.

Bir de latency demişsiniz ama bu oversampling bir latency kaynağı değil. Çünkü iki piksel sample edilip, tek piksel basılıyor. Latency bir piksel zamanı kadardır. (100 nanosaniyeden daha az. Farkedilmesi imkansız)

[eins]

Latency Test

@Alpyre, mümkün olur mu bilmiyorum ama hazırladığın test yazılımına bir ek rica etsem. Ekranın ortasındaki yatay çizgi üreinde soldan sağa doğru hareket eden, kırmızı bir top sprite eklemen mümkün mü?

Örneğin ekranı soldan sağa doğru tam olarak bildiğimiz bir sürede kat ediyor olsun, mesela 1/2 saniyede. İki ayrı ekrana hem orjinal composite çıkıştan hem de HDMI-520 ile çıkış alıp, aynı anda kaydedip aradaki farka bakacağım.

Topun yeri arasındaki farka göre kaç ms latecy olduğunu hesaplamak niyetindeyim...

Teşekkürler.

EDIT: Hatta şimdi aklıma başka bir fikir geldi. Ekranda bir köşeye timer ekleyebilirsen daha net olur aslında. Örneğin frame sayısını yazabiliriz. Gibi...

[Gökçe Bozkurt]

Ohoo
bunlarıda ekleyince bildiğin ekran kartı  benchmark testi gibi olacak..

Çok güzel şeyler oluyor 2017 de

[appiah4]

Yazmayı unuttum. Tabiki bu durumda piksel aspect ratio bozulmuş olacak. Pikseller daha ince uzun olacaktır.

Bir de latency demişsiniz ama bu oversampling bir latency kaynağı değil. Çünkü iki piksel sample edilip, tek piksel basılıyor. Latency bir piksel zamanı kadardır. (100 nanosaniyeden daha az. Farkedilmesi imkansız)

Tabi bu doğal bir sonuç, piksel geometrileri farklı..  İkisi arasında bir tercih yapmak gerekecek, ya bir miktar görsel artifact, ya da en/boy oranı farklı pikseller..

Oversampling algoritması supersampling'den farklıymış, zaten benim düşündüğüm şekli ile bir buffer gerektirirdi  (düşünemedim, devrede RAM olmadığını unutmuşum).  RAM koymama tercihi tahminen maliyet odaklıydı ama sayesinde benim latency takıntıma uygun bir cihaz olacak gibi görünüyor (piyasadaki ucuz halli tüm scandoubler'larda bu sorun var..)

[appiah4]

EDIT: Hatta şimdi aklıma başka bir fikir geldi. Ekranda bir köşeye timer ekleyebilirsen daha net olur aslında. Örneğin frame sayısını yazabiliriz. Gibi...

Genelde bu şekilde yapılıyor bildiğim, belirli bir süre geçmesi beklenerek bir noktada tek düğme ile iki ekran birden dondurularak aralarındaki farka bakılıyor..  Donanımla bunu yapmaya gerek yok tabi, fotoğrafları da çekilebilir.

[eins]

RAM koymama tercihi sadece maliyet odaklı değil. Tabiki maliyet de bir unsur.
Kullandığımız FPGA çok minimal. DRAM interface'i yok. Olsa bile yeterli pin yok zaten. RAM'li bir çözüm için muhtemelen Cyclone IV tarzı bir FPGA kullanmak gerekecekti. Ayrıca RAM demek latency demek...

[appiah4]

Çok güzel bir proje oluyor..  Merakla sonunu bekliyorum.

[witchdoktor]

Bence ikinci sonuç gayet güzel. Aksi taktirde tüm görüntüyü frame olarak alıp çeşitli algoritmalarla oversample & scale etmek gerekir ki en iyi ihtimalle 1-2 frame'lik bir lag ortaya çıkar. TV'de de 'game' modları gibi postprocessing efektlerini kapatan bir mod ayarlamak iyi olacaktır. 640x512'de pixsel art yapmayacaksanız (ki pixel art'çılar da genelde 320x200 + zoom yardımıyla düzenleme yaparlar) farkı hissetmezsiniz.

[Alpyre]

Tatile çıktım. Eve çok uzağım. Işin kötüsü kaynak kodlar evde.
Dur bakayım uzaktan erişimle WinUAE imajıma erişebiliyor muyum?

Erişebilirsem hallederim.

[eins]

FlickerFixer in action  

Normalde iş yapmam lazım ama hastalık gibi bulaştı, bırakamıyorum. Son bir test daha yapmak için kolları sıvadım. Daha önce sözüne ettiğim pseudo flicker fixer teorisini test ettim.

Normalde flicker fixer yapabilmek için 1 field'lık datayı ramde tutarak, bir sonraki field'i bu ramdeki satırların arasına sokup, progressive olarak LCD'ye atmak gerekiyor. Ama bizim elimizde RAM yok. Ne yapacağız?

Teorim şu idi, görüntüyü HDMI'a basarken, içerisine interlaced synch bilgileri eklersem, TV bunun interlaced onlduğunu anlayacak ve odd ve even fieldları kendisi iç içe geçirecekti. Tam da düşündüğüm gibi çalıştı... Tabi bunu ancak HDMI ile uygulayabiliriz, yani VGA scandoubler yapıyor olsaydık böyle bir lüksümüz olmayacaktı.

Önce flickerfixer dan önceki görüntü. Aslında bu görüntü zangır zangır titriyor. Ama telefon çekerken sanırım filtrelemiş. Videoda çok anlaşılmıyor:



Şimdi de flickerfixer devredeyken ki durum. Heykel gibi sabit. Titreme falan yok.



Bu arada ufak bir bilgi. Normalde HDMI üzerinden veri basarken bazı minimum ve maksimum bandwidth limitleri var. Maksimum kısmı bizi ilgilendirmiyor çünkü zaten bu elimizdeki FPGA ile ancak 576p görüntü oluşturabiliyoruz. Daha yüksek çözünürlükler için bir HDMI chipi gerekiyor.

Ancak minimum kısmı önemli. Zira 25MHz alında veri iletimi yasak. Burada uyguladığımız yöntem ile 576p yerine 576i verisi gönderince, yani aslında scandoubling yapmayınca, 13.5MHz ile veri aktarmamız gerekiyor ki mümkün değil. Buna çözüm olarak pixel doubling denilen bir yöntem var. Yani bandwidth'i minimum seviyeye çekebilmek için, her bir pikseli iki kere gönderiyoruz. (İhtiyacımız olmadığı halde veri iletim hızını yükseltiyoruz.)

Daha açık söylemek gerekirse, 576p de iken, 720x576 piksel gönderiyorduk. 576i de ise normalde 720x288 piksel göndermemiz gerekiyor. Ama bu limitin altında kaldığı için 1440x288 piksel gönderiliyor. Ben de bunu avantaja çevirdim. Nasılda ADV7181C ile x2 oversample yapıyorduk. Zaten elimizde 1440 piksel sample edilmiş data var. İşte bunu hiç ortalama almadan doğrudan basınca, düşey çizgilerdeki keskinlik biraz daha iyileştirilmiş oldu.

Son olarak bu videolarda FPGA ile scanline efekti uyguluyorum. Bunu rahatsız edici buluyorsanız merak etmeyin, final üründe kapatılabilecek yada seviyesi ayarlanabilecek...

[ibo1973]

belki saçma ve gereksiz bir soru ama 640x512 gibi çözünürlükler sorunsuz olduğuna göre amiga 1200 dede çalışıcak bu scandoubler doğrumu ?

[eins]

Muhtemelen evet. 500 600 ve 1200 de calismasini bekliyorum. 1200 um yok. Bir iki arkadas testler icin odunc vermeyi teklif etti. 500 ve 600 de duzgun calistiktan sonra 1200 konusunu degerlendirecegim.