<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wikidot="http://www.wikidot.com/rss-namespace">

	<channel>
		<title>Exact EDT?</title>
		<link>http://contourtextures.wikidot.com/forum/t-984944/exact-edt</link>
		<description>Posts in the discussion thread &quot;Exact EDT?&quot; - JFA is inexact; there exist linear-time EDT algorithms, highly paralleliseable</description>
				<copyright></copyright>
		<lastBuildDate>Wed, 22 Jul 2026 04:48:48 +0000</lastBuildDate>
		
					<item>
				<guid>http://contourtextures.wikidot.com/forum/t-984944#post-2088591</guid>
				<title>Re: Exact EDT?</title>
				<link>http://contourtextures.wikidot.com/forum/t-984944/exact-edt#post-2088591</link>
				<description></description>
				<pubDate>Thu, 14 Aug 2014 10:21:13 +0000</pubDate>
				<wikidot:authorName>stegu</wikidot:authorName>				<wikidot:authorUserId>30391</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>That's an interesting question, but I don't have an answer from the top of my head. I would need to look closer into it, but unfortunately I don't have much time to spend on that at the moment.</p> <p>Generally speaking, the errors generated by the anti-aliased version are different than the errors from the binary transform, and I would expect it to potentially mess things up a bit for the exact algorithms. The key issue is that you need to evaluate more pixels than the closest one on the discrete grid to be certain of finding the nearest edge in the anti-aliased sense. I have not spent any deep thought on what that would mean for the two specific algorithms you mention.</p> <p>Thanks for your comment, and your interest. I would be happy to discuss this further, but right now I have very little time to spend on actual coding and testing in this area. My focus when I did this was in getting it to work at all, because I needed the results for my research in computer graphics. The fine details about getting exact results (and even trying to figure out how &quot;exact&quot; would be interpreted in this context) were not my primary concern at the time.</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://contourtextures.wikidot.com/forum/t-984944#post-2088578</guid>
				<title>Exact EDT?</title>
				<link>http://contourtextures.wikidot.com/forum/t-984944/exact-edt#post-2088578</link>
				<description></description>
				<pubDate>Thu, 14 Aug 2014 09:32:56 +0000</pubDate>
				<wikidot:authorName>cbrunschen</wikidot:authorName>				<wikidot:authorUserId>1951915</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>(Sorry for the lack of links; as a low-karma user I am not permitted to post those, it seems. I've tried to give clear references instead; apologies for anything I've gotten wrong.)</p> <p>The <em>Jump Flooding Algorithm</em> (JFA) as used here for calculating the distance transform is fairly quick and produces good, but not exact, results. But there also exist algorithms that produce the <em>exact</em> Euclidean Distance Transform (EDT) in linear time, such as described in <em>A General Algorithm for Computing Distance Transforms in Linear Time</em> (A. Meijster, J.B.T.M. Roerdink, W.H. Hesselink, A general algorithm for computing distance transforms in linear time, Computational Imaging and Vision 18 (8) (2000) 331–340) and <em>A Linear Time Algorithm for Computing Exact Euclidean Distance Transforms of Binary Images in Arbitrary Dimensions</em> (C.R. Maurer, R. Qi, and V. Raghavan, IEEE Transactions on Pattern Analysis and Machine Intelligence, 25(2):265–270, February 2003). This is straightforward to parallelise on CPUs, and has been implemented on GPUs (in Cuda) as well as the <em>Parallel Banding Algorithm</em> (Thanh-Tung Cao, Ke Tang, Anis Mohamed, and Tiow-Seng Tan, Proceedings of the 2010 ACM SIGGRAPH symposium on Interactive 3D Graphics and Games (I3D '10)).</p> <p>Would some of this be applicable here and possible to adapt to generate the anti-aliased distance transform? An exact algorithm would avoid the (small) errors still present in what Jump-Flooding calculates, and a linear-time algorithm might be able to calculate them a little bit more quickly as well; and a GPU implementation would seem to fit in well to be able to generate them from rendered content in real time within a game.</p> 
				 	]]>
				</content:encoded>							</item>
				</channel>
</rss>