sonraki »

[Skate]

Bunu anlamaya çalışıyorum ama sanırım tam olarak anlayamadım. csdb deki screen shotta hiç scanline etkisi göremiyorum. Bana gerçek bir 1084'ü olan bu gtafiğin çekilmiş bir fotosunu gönderebilir mi? Tam olarak istenilen etki ne anlamak istiyorum açıkçası.

CSDB'deki screenshot büyük olasılıkla Vice'ın PAL Emulation özelliğiyle alınmıştır.

Buradaki asıl olay şu. Eski tip tüplü televizyon ve monitörlerde olay pixeli pixeline net biçimde görüntülenmez biliyorsunuz. Renkler doğal olarak, tüplü sistemin teknolojisi nedeniyle birbirine karışır. Aslında bu hem dez avantaj hem de avantaj sağlar. Örneğin eski analog kamera sistemleri düşük çözünürlükte video kaydederler. Tüplü 37 ekran bir TV'de görüntü cillop gibiyken LCD/LED tipi monitörlerde fullscreen yaptığında iğrenç bir görüntü oluşturur.

Commodore 64'de grafikerler bir çok farklı şekilde renk karışımı kullanırlar. Bunlardan biri interlaced grafiklerde kendiliğinden oluşan renk karışımıdır. Burada üst üste gelen ve sürekli renk değiştiren pixeller LCD/LED monitörlerde de aynen karışım olarak görünürler. Ancak Mermaid'in grafiği interlaced değil. Yine de renk karışımı var. Buradaki olayın sırrı şu.

CRT emülasyonu açık


CRT emülasyonu kapalı


Görüldüğü gibi normalde even odd linelar açık yeşil, açık kırmızı, açık yeşil, açık kırmızı gibi gidiyor. Ancak bu monitörlerde her scanline'ın rengi biraz komşularıyla karıştığı için kirli sarı gibi bir renk oluşturuyor. Resmin geri kalanında da dikkat ederseniz kırmızı, mor tonları böyle elde edilmiş. O renkler normalde C64'deki 16 rengin dışına çıkıyor. Ama bunu filtresiz biçimde LCD/LED ekranlardan görmek mümkün değil.

Vice open source biliyorsunuz. Tüm repo'yu çekmek çok uzun sürüyor, benim saatlerimi almıştı. Ama repo'yu browse edip ilgili bölümü indirip CRT emülasyonu incelenebilir. Benim tahminim blur'a çok benzer ama görüntüyü o derece flulaştırmayan ara bir karışım algoritması kullandıkları yönünde. Blurdaki gibi pixellerin ortalama değeri değil de orjinal pixelin rengini koruyacak ağırlıklı ortalama gibi bir şey kullandıklarını tahmin ediyorum ama algoritmayı tam olarak incelemedim. Dilerseniz bu kısmı biraz araştırıp, daha net bilgiler paylaşabilirim.

Edit: Source codelara çok bakmadan CSDB forumlarındaki ilgili başlıklara göz attım. Sanırım luma kanalına bildiğin blur çekiyorlar ama sadece bundan ibaret olmayabilir tabii ki. bu durumda RGB > YUV dönüşümü yapıp, efekti YUV olarak uygulayıp tekrar RGB space'e çevirmek gerekebilir. En azından ben öyle anladım. Kamera programı yazdığım dönemde sık sık yaptığım bir dönüşümdü YUV dönüşümü. Çok karmaşık ya da aşırı işlemci gücü yiyen bir şey değildir ama çok optimize yazılması lazım, her frame'de uygulanacak sonuçta.

[eins]

Benim tasarladığım sistemde zaten gelen videoyu öncelikle YCbCr olarak dijitize edip FPGA içerisine alacağım. YCbCr de zaten bir çeşit dijital YUV representasyonu. Dolayısı ile FPGA içerisinde YUV > RGB dönüşümü yapacaktım. Bu aşamada Luma ve Chroma compoenetleri elde zaten var olacak. Bu aşamada efekt uygulanabilir.

Yukarıdaki örnek resim ile ilgili açıklama için teşekkür ederim şimdi daha net anladım.

[Skate]

Ben kabaca YUV dedim, YCbCr sanırım C64 için daha uygun bir color space tanımı. Elinde luma, chroma kanalları olduktan sonra bir daha başka dönüşüm yapman gerekmez, doğrudan lumaya blur çekip, geri kalan kısım normal seyrinde devam edebilir her şey. Ama bunu CSDB'deki tek bir yoruma dayanarak söylüyorum, incelediğimizde Vice'da çok farklı işlemler de çıkabilir ortaya.

[eins]

Buna benzer bu tarz bir projeye referans olacak örnek fli vb resimler var mı test amaçlı kullanabileceğim? Ben çok uzak kaldım C64'e, hiç takip edemedim açıkçası...

[Skate]

Tek tek grafik linkleri göndermem zor, benim de araştırmam lazım. Bir çok grafikerin nadiren kullandığı bir teknik çünkü. Ancak Radwar'ın 1987'de yayınladığı bir demo var bu tekniği kullanan ki Vice bile çok iyi emüle edemiyor bu renkleri. Gerçek monitörde ancak güzel görünüyorlar. Bu demodaki renk karışımlarını ve CSDB'deki screenshot'ı esas alabilirsin. Zaten her kombinasyonda renkler karışmıyor, karışanları özel olarak seçmişler bu demoda.

http://csdb.dk/release/?id=31784

[Gokhan Ozkan]

Selam,
 Bu proje Amıga için de geçerli olabililirse harika olur.

Teknik bilgi  açıdan konunun içeriğine tam hakim olamasam da detaylı olarak takip ediyorum

İyi çalışmalar dilerim.

[ibo1973]

bence renk karışım işi baya bir zor 16 renklik cihazda 46 renk elde etmiş monitördede bu renkleri görmüş insanlar anladığım kadarı ile.

Bunu formilize nasıl edilebilir diye düşünüyorum ama çıkış yok gibi . Gelen veriyi R G B olarak alıcak R=100 g=80 B=255 geldi diyelim nasıl bir formül ile bunu monitörde farklılaştırmak mümkün olucaktır ? gelen verinin hangi kordinatta geldiğine bakarak + yada - değer mi eklenicek yani temelde 16 renk üreten ve 16 renk veren bir makinanın verdiği 16 renk bence 46 renge çıkarmak zor olur ?

ancak şöyle olabilir belki orjinal monitördeki görünen renklerin hangi sıra ile dizildiğine bakılarak 2 belki 3 hatta belkide 4 pixeldeki renklerin yan yana gelme durumuna bakarak olmayan bir renk üretilebilir yani orjinal monitör aynı anda sarı ve açık sarı görüyorsak ve açık sarı eğer c64 ün renk skalasında yoksa orjinal monitörde açık sarı için yanına gelen renkler incelenir ve bu iki renk yan yana geldiğinde bunun açık sarı olduğunu hdmi64 'e algılatıp açık sarı bastırılabilir

[EMREZ]

aynen katılıyorum, 46 renk dediklerinde bile bu sadece 16 renk, kalanı crt nin karıştırması. dijital bir alette biz yine 16 renk görürüz :(

bence renk karışım işi baya bir zor 16 renklik cihazda 46 renk elde etmiş monitördede bu renkleri görmüş insanlar anladığım kadarı ile.

Bunu formilize nasıl edilebilir diye düşünüyorum ama çıkış yok gibi . Gelen veriyi R G B olarak alıcak R=100 g=80 B=255 geldi diyelim nasıl bir formül ile bunu monitörde farklılaştırmak mümkün olucaktır ? gelen verinin hangi kordinatta geldiğine bakarak + yada - değer mi eklenicek yani temelde 16 renk üreten ve 16 renk veren bir makinanın verdiği 16 renk bence 46 renge çıkarmak zor olur ?

ancak şöyle olabilir belki orjinal monitördeki görünen renklerin hangi sıra ile dizildiğine bakılarak 2 belki 3 hatta belkide 4 pixeldeki renklerin yan yana gelme durumuna bakarak olmayan bir renk üretilebilir yani orjinal monitör aynı anda sarı ve açık sarı görüyorsak ve açık sarı eğer c64 ün renk skalasında yoksa orjinal monitörde açık sarı için yanına gelen renkler incelenir ve bu iki renk yan yana geldiğinde bunun açık sarı olduğunu hdmi64 'e algılatıp açık sarı bastırılabilir

[Skate]

@ibo1973: Yok, karışım işi renklere özel olarak yapılan bir şey değil. nasıl bir resme blur çeker, flulaştırırsın, aynısını parlaklık kanalına yapıyorsun, renkler birbirleriyle karışıyor. O söz konusu 46 renk de özel olarak elde edilmiyor. Toplam renk karışım ihtimali 136 renk aslında. Ancak adamlar mevcut durumdaki renk karışımlarına bakıyorlar, birbirlerinden çok uzak parlaklıktaki renkler iyi karışmıyor tabii ki, açık açık satır satır görünüyor onlar. Bu demoda güzel görünen 46 rengi seçmişler. İşin espirisi bu kadar. Yani karışım işi renklerden bağımsız olarak yapılacak, tüm piksellere uygulanacak genel bir formülden ibaret.

[EMREZ]

c64 ile LCD tv de güzel bir görüntü alayım, o demo gerekirse 16m renk bassın benim için önemli değil. gerçekten LCD de görüntü berbat ya. zaman kaybetmeden bir çözüm olur. yazılım güncelleme işi sonradan da olur.

[ibo1973]

@ibo1973: Yok, karışım işi renklere özel olarak yapılan bir şey değil. nasıl bir resme blur çeker, flulaştırırsın, aynısını parlaklık kanalına yapıyorsun, renkler birbirleriyle karışıyor. O söz konusu 46 renk de özel olarak elde edilmiyor. Toplam renk karışım ihtimali 136 renk aslında. Ancak adamlar mevcut durumdaki renk karışımlarına bakıyorlar, birbirlerinden çok uzak parlaklıktaki renkler iyi karışmıyor tabii ki, açık açık satır satır görünüyor onlar. Bu demoda güzel görünen 46 rengi seçmişler. İşin espirisi bu kadar. Yani karışım işi renklerden bağımsız olarak yapılacak, tüm piksellere uygulanacak genel bir formülden ibaret.

bu söylediğin duruma göre renkler rasgele çıkar yani sayısal bir veride bu efek işi ne kadar güzel olabilir tam emin değilim deneyip görmek lazım sanırım bence çokta iyi sonuç vermiyicektir ancak hiç olmamasından daha iyi sonuç vericektir tahminimce

Sayısal veride kesin veriler üzerine hareket etmek daha iyi sonuç vericektir diye düşünüyorum oda şu olabilir hangi rengi hangi renk dizilmi sonucunda orjinal monitörde görüyor isek orjinal monitörde oluşan renk dizilimlerini inceleyip aynı dizilimler oluştuğunda gördüğümüz rengi hdmi64 e bastırmak ama buda çok çok uğraştırıcak bir işlem ancak eğer düzgün yapılırsa 16 renklik c64 136 renk gibi çalışabilir diye düşünüyorum.

[Skate]

bu söylediğim zaten yapılmış bir şey, deneysel değil. Vice emülatörünün içinde yer alan CRT emülasyonu birebir bu işi yapıyor ve son derece başarılı yapıyor. Zaten benim önerdiğim şey Vice'ın kodlarının incelenip yakın bir algoritmanın uyarlanması yönünde. Önceki mesajları okuyacak olursan çok derinlemesine olmasa da detaylar da konuşuldu. Örneğin efekt RGB color space'de değil YCbCr katmanında uygulanıp sonra RGB'ye çevriliyor. yani algoritma ve örnek kodlar hazır, sonucu da Vice'dan görebiliyoruz.

[ibo1973]

evet farkındayım zaten demo var olduğuna göre tabiki yapılmış denenmiş bişeydir okadarını anlıyorum zaten benim yaklaşımım daha farklı bir yaklaşım başkalarının yaptığından çok daha yeni bir yaklaşım daha uğraştırıcı daha kesin sonuçlar vericek bir yaklaşım.

[LW3D]

@ibo19973: 46'dan daha fazla renk elde edilmesi gerek. 16 rengin kombinasyonu söz konusu... RGB mantığıyla bu işin içinden çıkmak zor...Analog üzerinden herhalde gidilmesi gerekiyor.

Luminance'a blur atılarak renkler nasıl karışıyor kısmını anlamadım... Yani biraz düşününce her rengin Luminance seviyesi farklı. Bu ağırlığa göre, mevcut rengin komşularına etkisi gibi bir şey formuluze edilebilir belki diye düşünüyorum. Salt (Y) Luminance'ın blur edilmesi bana çok mantıklı gelmedi. @Skate'in örneğinde, renklerde ciddi bir kayıpta söz konusu (parlaklıkta), Luminance'ı blur ettikleri için mi acaba?

[Skate]

luma'ya blur olayını sadece CSDB'de gördüğüm bir yoruma istinaden yazdım. Vice'ın kodlarını inceleyince ya da uygun bir tutorial bulunca detaylar netleşir.

Bakın bu topic'de tartışılmış olay, güzel linkler de var.

http://csdb.dk/forums/?roomid=7&topicid=66295

Groepaz'ın son yorumu şöyle.

thats also a PAL effect luma is "blurred" for ~1 pixel (black/white transitions arent perfectly sharp with pal either)

Tabi bu bir çok konuşulan şeyin sonunda söylenen bir laf sadece. Dediğim gibi detaylar Vice'ın source codelarında.