şükela:  tümü | bugün
  • http://www.timetechnology.us/ adresinde ikamet etmekte olan gavurlarin yaptigi isikli saat.
  • masa saati versiyonu icin (bkz: binary clock)
  • zamani ikilik sistemde, yani sadece 1 veye 0 kullanarak, gosteren saat turu. en cok rastlanan orneginde, saatler ve dakikalar yanip (1) sonen (0) ledler yardimiyla gosterilir. saat icin 4, dakikalar icin ise 6 tane led kullanilir.
  • thinkgeekten temin edilebilir.
  • şu anda sol bileğimde takılı bulunan hede. her geek'in rüyası.
  • 2013’te almışım saatimi. zaman tutma sorumluluğunda cep telefonları “uyanma alarmı” görevini de üstlenince, kol saatlerinin aksesuardan öteye gitmeyeceği tescillendi zaten. kimi için bu aksesuar gösteriş, kimisi için rüşvet malzemesiyken, kimisi için "sadece aksesuar". benim için de saatim öyle. madem bir aksesuar, eğlenceli bir şey olsun di mi?

    2013’te hem günlük kullanabileceğiniz, hem de takım elbiseyle gidebilecek kadar “şık” bir binary watch bulmak sanırım daha zordu. yine de o ara denk geldiğim en ideal model the one markasının şu modeli oldu. alırken okuduğum yorumlardan birisi “it is a great conversation starter” şeklindeydi. bunun ne demek olduğunu o zaman anlamamıştım, ama yazan adam haklıymış.

    binary watch’ler malumunuz saati ikilik sistemde göstermektedir. genellikle iki “kadran”ı vardır. saat kadranı 4 tane ışıkla temsil edilir (1, 2, 4, 8) ve dakika kadranı 6 ışıkla temsil edilir (1, 2, 4, 8, 16, 32). “bunun neresi ikilik?” derseniz, az önce parantez içinde yazdığım sayıların tamamı 2^x ile ifade edilebilir, ve bu rakamlara karşılık gelen ışıklar ya yanar, ya da yanmaz… bu yüzden ikilik sistemle ifade edilebilir.

    mesela saat 9’u 7 geçiyorsa, saat tarafında şu ışıklar yanmalı: (8, 1) dakika tarafında da şunlar yanmalı (4, 2, 1). şunun gibi bir görüntü sağlar. saat 9’u 8 geçtiğindeyse, (4,2,1) hepsi birden söner, sadece 8 yanar dakika kadranında.

    insanların düştüğü yanılgılardan birisi, daha çok ışık yandığında saatin daha ilerlediğidir, ama gördüğünüz üzere, 09:07’de daha fazla ışık yanarken 09:08’de daha az ışık yandı. 09:32’de de az ışık yanacak…

    bir diğer nokta, 09:32 ve 21:32 farkını yapamıyoruz. en azından benim örneğini verdiğim saat 12’lik sisteme uygun, bazı binary saatler 24’lük sistemi destekliyor, ama tahmin edeceğiniz üzere “gereksiz”, çünkü “eh, günün hangi yarısında olduğunu bilelim bir zahmet!”

    çektiğim dandik fotoğrafta dikkatinizi çeken bir nokta hangi ışığın hangi rakamı temsil ettiğinin çok rahat anlaşılmaması olabilir. zaten bu saatlerin en büyük dezavantajı karanlık (ve sarhoşken) ışıkların birbirine girmesi. yine de insan zamanla alışıyor bu sürece. alışırken de çeşitli okuma teknikleri geliştiriyor. başta mal gibi rakamları tek tek toplarken zamanla "toplamdan çıkarma" methodunu geliştirebiliyorsunuz. örneğin çok fazla ışık yanıyorsa, yanmayanların değerlerini toplayıp 63'ten çıkarmak çok daha pratik oluyor. ve evet, bu sırada fark ediyorsunuz, dakika kadranının toplamı 60 değil, 63 yapıyor.

    sonra simetrik bir takım şekiller alışıldık olabiliyor. örneğin tam 30 dakika geçerken sadece en üst ve en alt ışıkların yanmaması (1, 32) veya 45 geçerken 101101 simetrisi yakalayabiliyorsunuz (2 ve 16 hariç hepsi yanıyor) gibi...

    aradan azıcık daha zaman geçince baktöriyel kuralını fark ediyorsunuz (evet ben uydurdum, binary faktöriyel, yaman matematikçiyimdir). eğer ardışık ışıklar yanıyorsa, tamamını toplamakla uğraşmak yerine, bir sonraki "yanmayan" elemanın bir eksiği size sonucu veriyor. mesela 1,2,4,8 yandığında, ama 16 ve 32 yanmadığında, 16-1=15 size sonucu veriyor. 1+2+4+8 ile uğraşmadık, baktöriyelini aldık.

    bunlar iyi hoş teknikler de, aslında binary watch'lar aracılığıyla programcılıkla uğraşan ancak bitwise operationlar, least significant bit (lsb) most significant big (msb) ne işe yarıyor, "gerçek hayatta" bunları nerede kullanıcaz anlamayan arkadaşlara güzel anlatım imkanı tanıyor. hatta dur bak gaza geldim iki satır kod yazayım…

    (~yarım saat sonra)

    malumunuz bir sayıyı 8bit binary halinde temsil etmek için örneğin 37 yazacaksak 00100101 yazıyoruz. 1+4+32 şeklinde hesaplıyoruz. kısacası 1 decimal'ını temsil eden bit, sonda yazıldı. yani en küçük değeri olan bit sonda. bu en küçük değeri olan bit'e (içi dolu olsun olmasın) least significant bit diyoruz, çünkü toplam sayıya etkisi en az olan arkadaş bu. yani oradaki 1'i 0 yapsak, sayımız 37 yerine 36 olacak. ama tutup baştan 3. bit olan 1'i 0 yapsak? o zaman sayımız 37 yerine 5 olacak. yani ikisi de "aynı miktarda yer" kaplıyor ekranımızda (memory?), ancak her birinin etkisi farklı. bu yüzden en "sol"daki most significant bit, en "sağ"daki de least significant bit oldu. bilgisayar da bunları okurken hangi taraftan başlıyorsa ona göre big-endian veya little-endian oluyor. eğer en küçük değerden okumaya başlarsa, tahmin edeceğiniz gibi little endian. yukarıdaki 37 sayısının 00100101 halini okumaya kalkan bir arap aslında little endian davranacaktır çünkü sağdan sola okur. (hatta farkına da varmaz, farklı rakam okumuş olur)

    öyleyse least significant bit'lerdeki (lsb) hata aslında çok da etki etmeyebilir değerimize? gerçekten de böyle. diyelim ki bir görüntü dosyanız var. her bir pixeli 0-255 arasında (yani 1 byte ile) beyazdan-siyah'a tonlarla ifade ediyorsunuz. diyelim bir pixel değerimiz 215. bunu 11010111 diye yazıyoruz binary olarak. lsb'yi umursamazsak eğer, değer alt tarafı 214'e düşecek. 214 ile 215 arasındaki farkı gözümüz ne kadar seçiyor ki zaten? peki 2 lsb'yi de umursamazsak, değerimiz 212'ye düşecek. eğer 3 lsb'yi de umursamazsak? 208 olacak. 4 lsb'yi de umursamadık? değerimiz 1101[0000] oldu. hala 208. al sana ultra ilkel bir kayıplı sıkıştırma yöntemi. lsb'lerden gözümü rahatsız etmeyecek seviyede olanları silebilirim. derim ki "her 1 byte'ın ilk 4 bit’ini (nibble) dikkate alayım. böylece eskiden 2 byte ile temsil ettiğim veriyi 1 byte ile temsil edeyim." yani bir byte'ın ilk 4 bit'i bir piksel olsun, son 4 bit'i diğer piksel olsun.

    nasıl bir şey olduğunu merak ediyorsanız sizin için şurada yaptım. burada ilk fotoğraf (sol üst) orijinal lena. ikinci (sağ üst) ise sadece 1 lsb'nin dikkate alınmadığı durum. bizim yukarıda yaptığımız örnek 5. görüntü (alttan ikinci, sol) neredeyse hiçbir problem yok görüntüde, daha fazla bit kaybettiğimizde bozulmaya başlıyor... burada yaptığımız şey şu: veriyi yazarken her piksel için son 4 bit'i yazmadık. ama okuyup görüntülerken bunların "0" olduğunu farzettik. öte yandan, uydurduğum bu "görüntü formatı"na öyle bir özellik eklerim ki: orijinal görüntüdeki piksellerin son 4 bit'i çoğunlukla dolu ise, dosyamın başına "sen bunu okurken sondaki bitleri 0 olarak değil de 1 olarak farz et" anlamına gelen bir flag eklerim. bak uyduruk formatım azıcık akıllanmaya başladı.

    e ben bunu iletişimde de kullanabilirim. eğer önce msb'yi gönderiyorsam, karşı tarafa lsb henüz ulaşmadan iletişim koptuysa bile, en azından kopan kısmın 0 (ya da 1) olduğunu farz ederim, zaten çok significant olmayan şeyler kaybetmişsem ciddi bozulma olmamalı.

    "iyi de eğer görüntü gönderiyorsak, bu sefer karşı tarafa son pikselleri gönderememiş oluruz, ama ilk pikselleri tam göndeririz" demeniz normal. bunun önüne geçmek için de data structure'ımızı değiştiririz: önce bütün piksellerin msb'sini yazarız, sonra bütün piksellerin 2. msb'sini... böylece karşı taraf veriyi topladıkça bütün pikseller için gerekli bitler yavaş yavaş dolar… yani resim “yüklenirken” 1. pixel’in bütün bitleri dolduktan sonra 2. pixel’e geçmez… 1. pixel’in msb’sindan sonra 2. pixel’in msb’si yüklenir, sonra tekrar 1. pixel’in diğer bitleri şeklinde gider...

    şimdi bunları okuyup günümüzdeki kayıplı sıkıştırma formatlarının veya iletişim mekanizmalarının böyle çalıştığını falan düşünmeyin. örneğin jpeg daha ziyade görüntüyü (sinyali) discrete cosine transformation'dan (dct) geçirip spectral resolution'da "küçük" olan kısmı atıyor. ama veri yapısını “biraz” deminki örneğe benzetebiliriz. çok yavaş internet bağlantınız olduğunda (dialup günleri?) bazı sitelerdeki jpeg görüntülerin yukardan aşağıya piksel piksel yüklendiğini, bazılarınınsa tamamının berbat çözünürlükle yüklenip giderek netliğinin arttığını görmüşüzdür. buna jpeg dünyasında baseline scanning vs progressive scanning deniliyor. demin uydurduğumuz görüntü formatında da eğer her bir pikselin verisini tamamen “gönderip” sonra diğerine geçiyorsak aslında baseline scanning yapıyor oluyorduk. yok “bit significancy’e göre yükleme yapalım” dersek de progressive scanning taklidi yapmış oluyorduk. (aslında jpeg’de progressive scanning daha ziyade dct’deki düşük frekanslı bilginin önce yüklenip sonra yüksek frekanslı bilginin yüklenmesiyle yapılır ancak bit seviyesinde de significant bitleri önce yükleme işlemi de yapar) meraklısına şu makale güzel anlatmış, tamamını okumadım ama videoları da iyi, fikir vermesi bakımından: https://cloudinary.com/…ve_jpegs_and_green_martians

    madem görüntülerde least significant bit’in pek de bir halta yaramadığını öğrendik, bu bitleri farklı işler için kullanalım?

    steganography denilen bir şey var. örneğin cryptography dediğimde hepiniz “bir şeyi gizleme amaçlı şifreleme” gibi bir şeyler anlarsınız. mesela şuraya as9d8a0sd8 diye bir sözcük bıraksaydım onun bir “crypto” olduğunu anlayacaktınız, bakıp bakıp kırmak isteyecektiniz. steganography ise “bu bilginin gizlendiğinin de gizlenmesi” mevzusunu kapsar. yani açık açık “burada crypto var” demiyoruz ki, milletin dikkatini çekmesin.

    işte bu tekniği uygulamanın en güzel yönlerinden birisi, gizlemek istediğimiz bilgiyi başka verilerin içine gömmek. görüntü dosyaları da bunun için birebir. alıyoruz deminki monochromatic -grayscale- görüntümüzü, 0-255 arasındaki piksel değerlerinden lsb’lere pikseller boyunca veri gömüyoruz. yani her pikselin değeri +/- 1 değişiyor, bu yüzden göz pek algılamıyor, ancak o son lsb’leri sıralayıp okuyan bir kişi bir veri elde etmiş oluyor.

    ne diyorduk, heh binary watch. evet saat okurken de eğer dakika kadranında çok fazla ışık varsa ve kafanız karışıyorsa least significant bitleri boşverin, önce most significant olanlara bakın, size yaklaşık olarak saatin kaç olduğunu söyleyecektir, gerisi teferruat.

    amma çenem düştü. “it’s a great conversation starter” demiş miydim? baktöriyel sizinle olsun.