Jump Flood Algoritması Ayrılabilir mi?


10

JFA (burada açıklanan algoritma: http://www.comp.nus.edu.sg/~tants/jfa/i3d06.pdf ), bir Voronoi diyagramının veya bir mesafe dönüşümünün yaklaşık değerini almak için kullanılabilir. Bunu, tohum sayısına değil, elde edilen görüntünün boyutuna göre logaritmik zamanda yapar.

Resminiz her eksende aynı boyutta değilse ne yaparsınız?

Benzer boyutlar olsaydı, daha kısa eksenin 1 boyutta ekstra JFA adımlarına sahip olmasına izin verdiğinizden eminim, daha büyük eksen çalışmayı bitirdi (512 x 256 boyutlu bir görüntüye sahip olmak gibi). Büyük ölçüde farklı boyutlu eksen boyutları için bu çok daha verimsiz olabilir - 512 x 512 x 4 olan bir hacim dokusuna sahip olduğunuzu varsayalım.

JFA'yı her eksende ayrı ayrı çalıştırmak ve yine de iyi sonuçlar almak mümkün müdür?

Yoksa o noktada farklı bir algoritma kullanmak daha uygun mu? Eğer öyleyse, bu hangi algoritma olabilir?

Benim durumumda ideal olarak, hem tek noktalı tohumları hem de keyfi şekilli tohumları desteklemek istiyorum. Bir tohuma olan mesafenin bir çarpan ve / veya bir toplayıcı tarafından daha fazla veya daha az etki verecek şekilde ayarlandığı, muhtemelen ağırlıklandırılmış tohumlar.

Yanıtlar:


7

Bireysel sorularınıza hızlı yanıtlar

Resminiz her eksende aynı boyutta değilse ne yaparsınız?

Kağıt, 2 uzunluğu olan kenar uzunluklarına sahip kare görüntüler kullanmaktadır. Bu açıklama kolaylığı içindir, ancak algoritmanın çalışması için gerekli değildir. Bkz. Bölüm 3.1:

Genelliği kaybetmeden, n'nin 2 gücü olduğunu varsayabiliriz.

Yani, algoritmanın çalışması için bu varsayım gerekli değildir.

JFA'yı her eksende ayrı ayrı çalıştırmak ve yine de iyi sonuçlar almak mümkün müdür?

Her eksende ayrı ayrı çalışmanın daha yanlış piksel sonuçları vermesi ve çoğu durumda çalışması daha uzun sürer. Görüntü yan uzunluklarından birinin 8'den az olduğu (atlama yönlerinin sayısı) aşırı durumlarda, algoritma bu 8 yönü sırayla tedavi ettiğinden daha hızlı olabilir, ancak daha geniş bir görüntü için eksenleri ayırmak, bunları tedavi etme avantajını kaybeder paralel.

Benim durumumda ideal olarak, hem tek noktalı tohumları hem de keyfi şekilli tohumları desteklemeye çalışıyorum

Makale bölüm 6'da "Genelleştirilmiş Voronoi Diyagramı" alt başlığı altında keyfi şekilli tohumlardan bahsedilmektedir:

... algoritmalarımız bu tür genelleştirilmiş tohumlara nokta tohumu koleksiyonları gibi davranır ve böylece nokta tohumu için elde edilen iyi performansı miras almayı bekler.

Bu nedenle, rastgele şekilleri piksel koleksiyonları olarak modelleme amacınıza uyması koşuluyla, algoritmada herhangi bir ayarlama yapmanız gerekmez. Sadece aynı tohum numarasına, ancak farklı konumlara sahip, rastgele şekilli bir tohumdaki tüm pikselleri etiketleyen bir dokuda besleyin.

Bir tohuma olan mesafenin bir çarpan ve / veya bir toplayıcı tarafından daha fazla veya daha az etki verecek şekilde ayarlandığı, muhtemelen ağırlıklı tohumlar

"Çoğaltıcı ve katkı maddesi gibi tohumlar üzerinde ağırlıklandırma" için, kağıt sadece bölüm 8'de geçme olasılığını, gelecekteki potansiyel çalışma olarak belirtmektedir. Bununla birlikte, istenen ağırlıklandırmanın pikselden piksele geçirilen tohum verilerine dahil edilebilmesi koşuluyla, bunun uygulanması kolay olmalıdır.

Mevcut algoritma <s, position(s)>bir tohumu ve konumunu belirtmek için geçer ve herhangi bir anda piksel başına sadece bir tohum saklanır. Bunu saklamak için genişletmek <s, position(s), weight(s)>, uzaklık işlevini ağırlıklandırmak ve bir piksele geçirilen yeni tohumun, o anda depoladığından daha yakın olup olmadığını hesaplamak için gereken tüm bilgileri sağlar.

Hatta iki ağırlık, bir çarpımsal ve bir katkı maddesi ekleyebilir ve çarpımsal olanı sadece 1'e ve katkı maddesi olanı 0'a ayarlayabilirsiniz. Daha sonra algoritmanız, çoğul ağırlıklı ağırlıklı tohumlar, katkı ağırlıklı ağırlıklı tohumlar ve hatta her ikisinin birden veya her birinin bir kombinasyonu için kullanılma olasılığını içerir. Bu sadece

<s, position(s), multiplicative(s), additive(s)>

ve mevcut algoritma bu yeni algoritmaya eşdeğer

<s, position(s), 1, 0>


Nedeninin ayrıntılı açıklaması

Makalede olduğu gibi, log() baz 2 logaritmasına bakınız.

Algoritmanın farklı yan uzunluklara uyarlanması gerekmez

Yan uzunluklar eşit değilse ve 2'nin gücü değilse, algoritmayı uyarlamaya gerek yoktur. Zaten görüntünün kenarında, bazı atlama yönlerinin görüntünün dışına çıktığı piksellerle ilgilenir. Algoritma görüntünün dışına çıkan yönler için tohum bilgisini zaten atladığından, 2 gücü olmayan bir genişlik veya yükseklik sorun olmayacaktır. W genişliği ve H yüksekliği resmi için gereken maksimum atlama boyutu

2log(max(W,H))1

Eşit genişlik ve yükseklik N için, bu

2log(N)1

2 gücü olan bir yan uzunluk N durumunda, bu

2log(N)1=N/2

kağıtta kullanıldığı gibi.

Daha sezgisel olarak, maksimum yan uzunluğu 2 sonraki güce kadar yuvarlayın ve ardından maksimum atlama boyutunu elde etmek için bunu yarıya indirin.

En uzun kenar uzunluğu N ise, görüntüdeki her pikseli görüntüdeki her pikselden kapsayacak şekilde bu her zaman yeterlidir, çünkü herhangi bir piksele ofset 0 ila N-1 aralığında olacaktır. 0 - N / 2, N 2 gücü ise N-1'e kadar olan her tam sayıyı kapsayacaktır ve N 2 gücü değilse, logaritmanın tavanını alması nedeniyle kapsanan aralık yalnızca gerekenden daha büyük olabilir ( 2) sonraki gücüne yuvarlama.

2 gücü olmayan kenarları olan görüntüler çok daha az verimli olmayacaktır

Atlama sayısı, L'nin en uzun yan uzunluğuna bağlıdır. L, 2'nin gücü ise, atlama sayısı . L 2 gücü değilse, atlama sayısı . Oldukça büyük bir görüntü için bu büyük bir fark olmayacaktır.log(L)log(L)

Örneğin, 1024 x 1024 boyutlarında bir resim 10 atlama yinelemesi gerektirir. 512 x 512 görüntü için 9 atlama yinelemesi gerekir. İki boyut arasındaki her şey için de 10 tekrar gerekir. 513 x 513 görüntü gibi, sadece 2 gücün biraz üzerinde bir görüntünün en kötü durumunda bile, bu ölçekte yaklaşık% 11 daha fazla olan 1 ek yineleme gerektirir (9 yerine 10).

Kare olmayan görüntüler alan başına daha az verimlidir

Gerekli yineleme sayısı en uzun kenar uzunluğu ile belirlendiğinden, 1024 x 1024 görüntü için geçen süre 1024 x 16 görüntü ile aynı olacaktır. Kare bir görüntü, daha fazla alanın aynı sayıda yinelemeyle kaplanmasını sağlar.

Eksenleri ayırmak kaliteyi düşürür

Makalenin 5. Bölümü olası hataları açıklamaktadır. Her piksele diğer piksellerden bir yolla ulaşılabilir, ancak bazı tohumlar yoldaki önceki piksele en yakın olmadığı için en yakın tohumu getirmez. Bir tohumun ilerlemesine izin vermeyen bir pikselin, o tohumu "öldürdüğü" söylenir. Bir piksele en yakın tohum, o piksele giden tüm yollarda öldürülürse, piksel başka bir tohum kaydeder ve son görüntüde yanlış bir renk olur.

Nihai sonucun doğru olması için tohumu öldürmeyen sadece bir yolun olması gerekir. Yanlış renkler yalnızca doğru tohumdan belirli bir piksele giden tüm yollar engellendiğinde oluşur.

Bir yol, yatay ve dikey geçişleri değiştirmeyi içeriyorsa, eksenleri ayırmak bu yolu imkansız hale getirecektir (tüm dikey atlamalardan önce tüm yatay sıçramalar alınacak ve alternatifi imkansız hale getirecektir). Çapraz atlamalar hiç mümkün olmayacak. Böylece, çapraz atlamalar içeren veya içeren herhangi bir yol hariç tutulur. Her pikselin her iki piksel için de bir yolu olacaktır, ancak şimdi daha az yol olduğundan, belirli bir pikselin doğru tohumu almasının engellenmesi olasılığı daha yüksektir, bu nedenle nihai sonuç daha fazla hataya eğilimli olacaktır.

Eksenleri ayırmak, algoritmanın daha uzun sürmesini sağlayacaktır

Taşkınlar artık paralel olarak yapılmayacağından, bunun yerine her eksen için tekrarlanacağından, verimlilik muhtemelen eksenleri ayırarak azalacaktır. 2D için bu muhtemelen yaklaşık iki kat daha uzun ve 3D için yaklaşık 3 kat daha uzun sürer.

Bu, çapraz sıçramaların olmaması nedeniyle biraz azaltılabilir, ancak yine de verimlilikte genel bir düşüş bekleyebilirim.


1
Ben zaten bunlardan bazılarını denemeye başladım. Tam 9 yerine bir + işaretinde (5 okuma) örneklemenin testimde hiçbir fark göstermediğini buldum, ancak daha karmaşık durumlarla eminim, farklılıklar olurdu. Tam bir x jfa ve sonra bir tam y jfa yapmak birçok hata yapar. Varsa daha fazla ayrıntı / bilgi duymak isterim, ancak cevabınızı kabul ediyorum: P
Alan Wolfe

1
Unuttum, deneylerimden birine bağlantı: shadertoy.com/view/Mdy3D3
Alan Wolfe

İlginçtir, sadece 5 okuma ile de iyi çalışıyor - özellikle de paralelleştirilemedikleri için. Kağıt, hataya neden olan vakaları listelediğinden, kasıtlı olarak bunları ayarlayabilir ve 5 atlama yönünün hala iyi olup olmadığını görebilirsiniz.
trichoplax

Kendi cevabınızı göndermeye hazırsınız gibi geliyor ...
trichoplax

bilgilerim sizinkini tamamlıyor: P
Alan Wolfe
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.