Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
Yazılımlar / Diğer Programlar 
Jan Sloot - Dijital Kodlama / Dna Sıkıştırma Yöntemi Jan Sloot - Dijital Kodlama / Dna Sıkıştırma Yöntemi
-
entropi nin ne oldugunu bilen bu konuya inanmaz.
-
FireX bunu yazdı
Siteye biraz baktım. Şahsen bana güven vermedi. Bence olay asparagas duruyor. Data sıkıştırma üzerine detaylı bir çalışmam olmadı. Ama şunu söyleyebilirim. Bir datanın mümkün olan en kısa halinin uzunluğu Kolmogorov complexity ile hesaplanabilir. Ancak sonsuzluk söz konusu olduğundan hesaplanabilir bir fonksiyon değil. Yani oturup bunun programını yazamayız. Ancak yaklaşım yapılabilir. İşin özünde rastgelelik yatıyor. Rastgelelik denildiğinde akla entropi gelir. Shannon'ı belki duymuşsunuzdur. Bilgi teorisi bugünlerde popüler.
En temel haliyle, elimizdeki string
aaaaaaaaaaaaaaaaaaaaaaaaa
ise bunu sıkıştırması çok kolay. Düzensizlik söz konusu değil. Çok kısa bir şekilde ifade edilip bir döngü ile açılabilir. Ama
abcdfabdnedbandns
gibi karışık bir şey ise bunda sıkıştırılabilirlik haliyle daha düşük. Belki hiç sıkıştırma imkanı dahi olmayabilir.
"10 kb'lık veriydi içinden 40 mb çıktı. Bu nasıl oluyor" diyorsanız sebebi bu. Bir notepad dosyası açıp içine megabyte'larca "aaaaaaaaaaaaaaa..." yapıştırırsanız ve sonra bu dosyayı sıkıştırırsanız muazzam düzeyde sıkıştırıldığını göreceksiniz ancak entropisi yüksek bir exe dosyasını sıkıştırdığınızda ise çok da sıkışmadığını...Bu açıdan "şu kadarlık" veriyi "bu kadar" yapmış denilmesi de bir şey ifade etmiyor. Önemli olan entropi arttığında ne düzeyde başarılı olduğu.
Hocam ben makine mühendisiyim yazılım konularından da çok anlamam merakımdan ve cahilliğimden soruyorum. "aaaaa" diyorsun ya, yazılımlar ve programlama dillerinin temelinde "1010001...."lerden oluşuyorlar ya, bunları sıkıştırmakla "aaaaa"ları sıkıştırmak aynı şey gibi geliyor bana teoride. sence de öyle değil mi? belki çok fazla bir düz mantık ama merakımdan soruyorum sadece :)
-
Dryrock bunu yazdıFireX bunu yazdı
Siteye biraz baktım. Şahsen bana güven vermedi. Bence olay asparagas duruyor. Data sıkıştırma üzerine detaylı bir çalışmam olmadı. Ama şunu söyleyebilirim. Bir datanın mümkün olan en kısa halinin uzunluğu Kolmogorov complexity ile hesaplanabilir. Ancak sonsuzluk söz konusu olduğundan hesaplanabilir bir fonksiyon değil. Yani oturup bunun programını yazamayız. Ancak yaklaşım yapılabilir. İşin özünde rastgelelik yatıyor. Rastgelelik denildiğinde akla entropi gelir. Shannon'ı belki duymuşsunuzdur. Bilgi teorisi bugünlerde popüler.
En temel haliyle, elimizdeki string
aaaaaaaaaaaaaaaaaaaaaaaaa
ise bunu sıkıştırması çok kolay. Düzensizlik söz konusu değil. Çok kısa bir şekilde ifade edilip bir döngü ile açılabilir. Ama
abcdfabdnedbandns
gibi karışık bir şey ise bunda sıkıştırılabilirlik haliyle daha düşük. Belki hiç sıkıştırma imkanı dahi olmayabilir.
"10 kb'lık veriydi içinden 40 mb çıktı. Bu nasıl oluyor" diyorsanız sebebi bu. Bir notepad dosyası açıp içine megabyte'larca "aaaaaaaaaaaaaaa..." yapıştırırsanız ve sonra bu dosyayı sıkıştırırsanız muazzam düzeyde sıkıştırıldığını göreceksiniz ancak entropisi yüksek bir exe dosyasını sıkıştırdığınızda ise çok da sıkışmadığını...Bu açıdan "şu kadarlık" veriyi "bu kadar" yapmış denilmesi de bir şey ifade etmiyor. Önemli olan entropi arttığında ne düzeyde başarılı olduğu.
Hocam ben makine mühendisiyim yazılım konularından da çok anlamam merakımdan ve cahilliğimden soruyorum. "aaaaa" diyorsun ya, yazılımlar ve programlama dillerinin temelinde "1010001...."lerden oluşuyorlar ya, bunları sıkıştırmakla "aaaaa"ları sıkıştırmak aynı şey gibi geliyor bana teoride. sence de öyle değil mi? belki çok fazla bir düz mantık ama merakımdan soruyorum sadece :)
Sıkıştırmanın limitleri ve entropi hakkında konuşursak, ascii ve binary için de aynı şeyleri söyleyebiliriz. Düzensizlik artarsa sıkıştırması o kadar zor olur. Ancak binary ya da text sıkıştırmak istiyorsak o durumda daha fazla verim almak için yol ayrımına gitmek gerekir. Örneğin a'nın karşılığı 01100001'dır. Bunu, 0, 1, 1, 0, ... şeklinde bit bit ele almak var. Bir de ascii karşılığı üzerinden 01100001 şeklinde blok halinde ele almak var. İhtiyacımıza bağlı olarak, elimizdeki kümenin özelliklerinden faydalanabilir, bunların sayesinde, spesifik konular için daha başarılı algoritmalar üretebiliriz. Bu sebeple, farklı konular için pek çok farklı sıkıştırma algoritması vardır. Yazıları sıkıştıranlar, genel amaçlı kullanılan binary data sıkıştırma algoritmaları, resim, ses dosyası, video dosyası sıkıştıranlar vs.
Ha tabii şunu da not düşeyim. Her sıkıştırma algoritması da, düzensizlikten etkilenmez. Yani, sıkıştırma kapasitesi entropiden etkilenen algoritmalardan daha düşüktür ama hep belli bir düzeyde sıkıştırma sağlar. Örneğin elimizde 1024x1024 resim dosyası varsa 10 mb ise bunu hep 5 mb yapar. İçindeki resim isterse dümdüz simsiyah olsun, isterse de her pixel'i farklı renk olsun. Bunun amacı (kayıplı bir sıkıştırma algoritması olarak) hem boyutu belli bir düzeyde düşürüp hem de rastgele bellek erişimini hızlandırmaktır. Çoğunlukla oyunlar için texture sıkıştırmada kullanılır. Sağda solda kullandığımız JPEG, vb. resim dosyası formatlarında böyle bir kaygı yoktur ve yaklaşımlar farklıdır.
Bir de video dosyası sıkıştırmadan bahsedersem, videolarda framelerin değişen kısımları en temel haliyle videonun sıkıştırılmasına etki eder. Yani 1000 frame'i olan bir video düşünün. Sabitlenmiş bir kamera, gökyüzünde uçan balonu çekmiş olsun. Bu durumda ne olur? Her karede sadece balonun olduğu kısım değişiklik gösterirken, bu alanın dışındaki gökyüzü aynen olduğu gibi kalır. Bu durumda, balonun dışında kalan koskoca bir sabit arkaplanı ayrı ayrı framelerde tekrar tekrar tutmanın da anlamı yoktur. O kısım 1. karede de aynıdır. 10. karede de aynıdır. Gereksiz yere aynı şeyi tekrar etmiş oluruz. Ha tabi bu şekilde düşünmenin de bir bedeli olacaktır. Gözümüze çok da farklı görünmeyen ama, kamera hassasiyetine bağlı olarak sabit dediğimiz frame kısımlarında ışığa bağlı olarak çok ufak değişimler olmuş olabilir. Bu değişimlerden ne kadar fedakarlık edersek videonun kalitesini o kadar düşürmüş oluruz. Ama en temelde baktığımızda yine farklılık, düzensizlik konusu söz konusudur. 10 frame'i tamamen aynı bir videoyu sıkıştırmak "aaaaaaaaaa" yı sıkıştırmak gibidir. Yöntemler çok farklıdır ama en temelde yatan gerçeklik aynıdır. Nasıl "abfkrjdjsj" şeklinde bir yazıyı sıkıştırmak çok başarılı olamayacak ise, her frame'inin pixelleri değişen bir videoyu sıkıştırmak da aynı şekilde başarılı olamayacaktır.
-
FireX bunu yazdıDryrock bunu yazdıFireX bunu yazdı
Siteye biraz baktım. Şahsen bana güven vermedi. Bence olay asparagas duruyor. Data sıkıştırma üzerine detaylı bir çalışmam olmadı. Ama şunu söyleyebilirim. Bir datanın mümkün olan en kısa halinin uzunluğu Kolmogorov complexity ile hesaplanabilir. Ancak sonsuzluk söz konusu olduğundan hesaplanabilir bir fonksiyon değil. Yani oturup bunun programını yazamayız. Ancak yaklaşım yapılabilir. İşin özünde rastgelelik yatıyor. Rastgelelik denildiğinde akla entropi gelir. Shannon'ı belki duymuşsunuzdur. Bilgi teorisi bugünlerde popüler.
En temel haliyle, elimizdeki string
aaaaaaaaaaaaaaaaaaaaaaaaa
ise bunu sıkıştırması çok kolay. Düzensizlik söz konusu değil. Çok kısa bir şekilde ifade edilip bir döngü ile açılabilir. Ama
abcdfabdnedbandns
gibi karışık bir şey ise bunda sıkıştırılabilirlik haliyle daha düşük. Belki hiç sıkıştırma imkanı dahi olmayabilir.
"10 kb'lık veriydi içinden 40 mb çıktı. Bu nasıl oluyor" diyorsanız sebebi bu. Bir notepad dosyası açıp içine megabyte'larca "aaaaaaaaaaaaaaa..." yapıştırırsanız ve sonra bu dosyayı sıkıştırırsanız muazzam düzeyde sıkıştırıldığını göreceksiniz ancak entropisi yüksek bir exe dosyasını sıkıştırdığınızda ise çok da sıkışmadığını...Bu açıdan "şu kadarlık" veriyi "bu kadar" yapmış denilmesi de bir şey ifade etmiyor. Önemli olan entropi arttığında ne düzeyde başarılı olduğu.
Hocam ben makine mühendisiyim yazılım konularından da çok anlamam merakımdan ve cahilliğimden soruyorum. "aaaaa" diyorsun ya, yazılımlar ve programlama dillerinin temelinde "1010001...."lerden oluşuyorlar ya, bunları sıkıştırmakla "aaaaa"ları sıkıştırmak aynı şey gibi geliyor bana teoride. sence de öyle değil mi? belki çok fazla bir düz mantık ama merakımdan soruyorum sadece :)
Sıkıştırmanın limitleri ve entropi hakkında konuşursak, ascii ve binary için de aynı şeyleri söyleyebiliriz. Düzensizlik artarsa sıkıştırması o kadar zor olur. Ancak binary ya da text sıkıştırmak istiyorsak o durumda daha fazla verim almak için yol ayrımına gitmek gerekir. Örneğin a'nın karşılığı 01100001'dır. Bunu, 0, 1, 1, 0, ... şeklinde bit bit ele almak var. Bir de ascii karşılığı üzerinden 01100001 şeklinde blok halinde ele almak var. İhtiyacımıza bağlı olarak, elimizdeki kümenin özelliklerinden faydalanabilir, bunların sayesinde, spesifik konular için daha başarılı algoritmalar üretebiliriz. Bu sebeple, farklı konular için pek çok farklı sıkıştırma algoritması vardır. Yazıları sıkıştıranlar, genel amaçlı kullanılan binary data sıkıştırma algoritmaları, resim, ses dosyası, video dosyası sıkıştıranlar vs.
Ha tabii şunu da not düşeyim. Her sıkıştırma algoritması da, düzensizlikten etkilenmez. Yani, sıkıştırma kapasitesi entropiden etkilenen algoritmalardan daha düşüktür ama hep belli bir düzeyde sıkıştırma sağlar. Örneğin elimizde 1024x1024 resim dosyası varsa 10 mb ise bunu hep 5 mb yapar. İçindeki resim isterse dümdüz simsiyah olsun, isterse de her pixel'i farklı renk olsun. Bunun amacı (kayıplı bir sıkıştırma algoritması olarak) hem boyutu belli bir düzeyde düşürüp hem de rastgele bellek erişimini hızlandırmaktır. Çoğunlukla oyunlar için texture sıkıştırmada kullanılır. Sağda solda kullandığımız JPEG, vb. resim dosyası formatlarında böyle bir kaygı yoktur ve yaklaşımlar farklıdır.
Bir de video dosyası sıkıştırmadan bahsedersem, videolarda framelerin değişen kısımları en temel haliyle videonun sıkıştırılmasına etki eder. Yani 1000 frame'i olan bir video düşünün. Sabitlenmiş bir kamera, gökyüzünde uçan balonu çekmiş olsun. Bu durumda ne olur? Her karede sadece balonun olduğu kısım değişiklik gösterirken, bu alanın dışındaki gökyüzü aynen olduğu gibi kalır. Bu durumda, balonun dışında kalan koskoca bir sabit arkaplanı ayrı ayrı framelerde tekrar tekrar tutmanın da anlamı yoktur. O kısım 1. karede de aynıdır. 10. karede de aynıdır. Gereksiz yere aynı şeyi tekrar etmiş oluruz. Ha tabi bu şekilde düşünmenin de bir bedeli olacaktır. Gözümüze çok da farklı görünmeyen ama, kamera hassasiyetine bağlı olarak sabit dediğimiz frame kısımlarında ışığa bağlı olarak çok ufak değişimler olmuş olabilir. Bu değişimlerden ne kadar fedakarlık edersek videonun kalitesini o kadar düşürmüş oluruz. Ama en temelde baktığımızda yine farklılık, düzensizlik konusu söz konusudur. 10 frame'i tamamen aynı bir videoyu sıkıştırmak "aaaaaaaaaa" yı sıkıştırmak gibidir. Yöntemler çok farklıdır ama en temelde yatan gerçeklik aynıdır. Nasıl "abfkrjdjsj" şeklinde bir yazıyı sıkıştırmak çok başarılı olamayacak ise, her frame'inin pixelleri değişen bir videoyu sıkıştırmak da aynı şekilde başarılı olamayacaktır.
Teşekkürler hocam güzel bir açıklama olmuş.
-
şimdi çıkıyorum, sonra okucam. ^^)/
RitmFarbRacourci tarafından 21/Mar/16 16:49 tarihinde düzenlenmiştir -
Yapabilecek babayiğidi ne paralar bekler bir bilseniz. Random veriyi bu kadar sıkıştırabilen bir adam bize çağ atlatır. Başka da birşey demem herkes yeterince yazmış.
-
@Firex hocam, son mesajın 2. paragraf flu kaldı bende. ha neresini anlamadın dersen :2. paragrafın geneli. ama özellikle işleyişi. ve şurası
": Her sıkıştırma algoritması da, düzensizlikten etkilenmez "
3. paragrafla alakası yok herhalde.
RitmFarbRacourci tarafından 21/Mar/16 19:14 tarihinde düzenlenmiştir -
Fasafiso bunlar beyler inanmayin. Veri tipini iyi bilirsen ona ozel cok verimli compression algoritmalari yazabilirsin, ancak her turlu veride o oranda compression yapan bir algoritmanin olmasi mumkun degil.
Pi compression olayi gercek, pi sayisiyla alakasi yok gerci, e sayisi da olabilir, her hangi bir irrasyonel sayi olabilir. Sorun pratik kullanim icin verimli olmamasi.
Mantik suna dayaniyor, compress etmek istedigin datanin byte larini pi sayisinin virgulden sonraki haneleri arasinda ariyorsun. Mesela 10 baytlik bir stream'i pi'nin virgulden sonraki 232435. hanesinde buldun, o 10 byte yerine bu lokasyonu yaziyorsun.
Acmak isteyen adam, ayni 10 byte i elde etmek icin pi sayisinin 232435. hanesini kendisi de hesaplamasi gerekiyor, bu nedenle zaten pek verimli degil, fazla islem gucu gerektiriyor. Ancak teoride dogru ve bence yaratici bir compression yontemi.
-
HarmOniYa bunu yazdı@Firex hocam, son mesajın 2. paragraf flu kaldı bende. ha neresini anlamadın dersen :2. paragrafın geneli. ama özellikle işleyişi. ve şurası
": Her sıkıştırma algoritması da, düzensizlikten etkilenmez "
3. paragrafla alakası yok herhalde.Evet. Üçüncü paragraf farklı konu.
Düzensizlikten etkilenmemeden kastettiğim şu,Örneğin, elimizde kayıplı bir sıkıştırma algoritması var ve elimizde şöyle bir veri var.
"a1a2a3a4a5"
Diyelim ki, çift sırada olanlara gerek yok. (0'dan değil 1'den numaralandırırsak) Sıkıştırırsak elimizde şu kalır."aaaaa"
****Bir diğer örnek, "a1b2f3c4t5" olsun.
Bu durumda sıkıştırılırsa,
"abfct" olur.
****Şimdi üsttekilere bakarsak, girişler 10 karakterli, çıkışlar ise 5 karakterli. Yani verinin düzensizliğinden bağımsız olarak bir sıkıştırma yapılmış. Hepsinin "a" olması ya da karışık olması, sıkıştırma oranını değiştirmiyor. Bu formatta, 10 karakterli hangi veriyi verirsen ver, çıkış her zaman 5 karakterli olur.
anonim6918524 tarafından 21/Mar/16 19:42 tarihinde düzenlenmiştir -
@Firex hocam, şimdi çaktım. tskler. ^^)/
RitmFarbRacourci tarafından 21/Mar/16 19:56 tarihinde düzenlenmiştir
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla