<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Computer Graphics Lab</title>
	<atom:link href="http://cg.alexandra.dk/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://cg.alexandra.dk</link>
	<description>at the Alexandra Institute</description>
	<lastBuildDate>Fri, 08 Feb 2013 00:43:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>Comment on WebGL Tutorial: Optimizing Data Transfer for WebGL Applications by Christian Jensen</title>
		<link>http://cg.alexandra.dk/2012/11/26/webgl-tutorial-optimizing-data-transfer-for-webgl-applications/comment-page-1/#comment-26241</link>
		<dc:creator>Christian Jensen</dc:creator>
		<pubDate>Fri, 08 Feb 2013 00:43:16 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1386#comment-26241</guid>
		<description>Looking at how you pack the data into the png I believe you can get much better compression if you pack the data in a manner that groups similar data in the same area in the image so the PNG filters can reduce the data as much as possible before compressing. See : http://www.w3.org/TR/PNG/#9Filters

I would probably try greyscale encoding so each pixel corresponded to one value and I&#039;d try grouping as type of value on it&#039;s own line.
In your case you have 7 different value for each point so the data for one point could be stored in pixels 0,0 through 0,6

Like so :
0123456789..
0123456789..
0123456789..
0123456789..
0123456789..
0123456789..
0123456789..
.. where each number is a point and each row is a value.

So width * height becomes pointnumber * value

That only uses 7 pixels of the PNG height so to make it possible to do larger datasets without hitting the PNG limit of 4 bytes width * 4 bytes height you could either just continue the same pattern but with more rows, or you could group the data even more so instead having the next value in the point come at (rownumber + 1) it could come at (rownumber + (maxheight/7))

If you&#039;re really feeling ambitious you could even try performing a FFT on the image and then do an inverse FFT clientside in javascript, but just like with LZMA compression this may or may not turn out to take longer time decoding than it gains through more efficient compression.</description>
		<content:encoded><![CDATA[<p>Looking at how you pack the data into the png I believe you can get much better compression if you pack the data in a manner that groups similar data in the same area in the image so the PNG filters can reduce the data as much as possible before compressing. See : <a href="http://www.w3.org/TR/PNG/#9Filters" rel="nofollow">http://www.w3.org/TR/PNG/#9Filters</a></p>
<p>I would probably try greyscale encoding so each pixel corresponded to one value and I'd try grouping as type of value on it's own line.<br />
In your case you have 7 different value for each point so the data for one point could be stored in pixels 0,0 through 0,6</p>
<p>Like so :<br />
0123456789..<br />
0123456789..<br />
0123456789..<br />
0123456789..<br />
0123456789..<br />
0123456789..<br />
0123456789..<br />
.. where each number is a point and each row is a value.</p>
<p>So width * height becomes pointnumber * value</p>
<p>That only uses 7 pixels of the PNG height so to make it possible to do larger datasets without hitting the PNG limit of 4 bytes width * 4 bytes height you could either just continue the same pattern but with more rows, or you could group the data even more so instead having the next value in the point come at (rownumber + 1) it could come at (rownumber + (maxheight/7))</p>
<p>If you're really feeling ambitious you could even try performing a FFT on the image and then do an inverse FFT clientside in javascript, but just like with LZMA compression this may or may not turn out to take longer time decoding than it gains through more efficient compression.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on WebGL Tutorial: Optimizing Data Transfer for WebGL Applications by Christian Jensen</title>
		<link>http://cg.alexandra.dk/2012/11/26/webgl-tutorial-optimizing-data-transfer-for-webgl-applications/comment-page-1/#comment-26229</link>
		<dc:creator>Christian Jensen</dc:creator>
		<pubDate>Thu, 07 Feb 2013 22:55:09 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1386#comment-26229</guid>
		<description>You can improve on this even further by using better compression.

I used ScriptPNG to optimize KommuneDataVBO.png to only 739 kb.
I also used ScriptGZ to reduce KommuneDataVBO.bin to 743 kb.
You can find both on http://css-ig.net/
The website is in french (I used Google Translate to help me there) but the tools are not.
I suggest reading the article on pre-compressing files with Gzip http://css-ig.net/articles/pre-compression-gzip , because it not only provides a link to ScriptGzip but also explains how to avoid having the server compress the files, which makes the server load the file faster and use less cpu.

You could also look into compressing the files with something much more efficient like LZMA (KommuneDataVBO.bin only took up 455kb LZMA compressed) and use a javascript decompressor.  There are some available online - the trick is finding one that is both fast and small as you don&#039;t want the client spending more time loading the extra javascript and decompressing, than is actually saved by doing this.</description>
		<content:encoded><![CDATA[<p>You can improve on this even further by using better compression.</p>
<p>I used ScriptPNG to optimize KommuneDataVBO.png to only 739 kb.<br />
I also used ScriptGZ to reduce KommuneDataVBO.bin to 743 kb.<br />
You can find both on <a href="http://css-ig.net/" rel="nofollow">http://css-ig.net/</a><br />
The website is in french (I used Google Translate to help me there) but the tools are not.<br />
I suggest reading the article on pre-compressing files with Gzip <a href="http://css-ig.net/articles/pre-compression-gzip" rel="nofollow">http://css-ig.net/articles/pre-compression-gzip</a> , because it not only provides a link to ScriptGzip but also explains how to avoid having the server compress the files, which makes the server load the file faster and use less cpu.</p>
<p>You could also look into compressing the files with something much more efficient like LZMA (KommuneDataVBO.bin only took up 455kb LZMA compressed) and use a javascript decompressor.  There are some available online - the trick is finding one that is both fast and small as you don't want the client spending more time loading the extra javascript and decompressing, than is actually saved by doing this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Mosegaards Cloth Simulation Coding Tutorial by jiangxu082@gmail.com</title>
		<link>http://cg.alexandra.dk/2009/06/02/mosegaards-cloth-simulation-coding-tutorial/comment-page-1/#comment-25495</link>
		<dc:creator>jiangxu082@gmail.com</dc:creator>
		<pubDate>Tue, 29 Jan 2013 07:23:14 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=147#comment-25495</guid>
		<description>very nice tutorial!</description>
		<content:encoded><![CDATA[<p>very nice tutorial!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Oriented Particles Christmas Card by Oriented Particles in 2D &#8211; an example. &#171; Computer Graphics Lab</title>
		<link>http://cg.alexandra.dk/2012/12/07/oriented-particles-christmas-card/comment-page-1/#comment-23600</link>
		<dc:creator>Oriented Particles in 2D &#8211; an example. &#171; Computer Graphics Lab</dc:creator>
		<pubDate>Wed, 02 Jan 2013 13:36:26 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1542#comment-23600</guid>
		<description>[...] what the demo show is a somewhat simplified version of our Oriented Particles Christmas Card. The demo is a standard GLUT/OpenGL application but it can also be cross-compiled to [...]</description>
		<content:encoded><![CDATA[<p>[...] what the demo show is a somewhat simplified version of our Oriented Particles Christmas Card. The demo is a standard GLUT/OpenGL application but it can also be cross-compiled to [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Mosegaards Cloth Simulation Coding Tutorial by rsq</title>
		<link>http://cg.alexandra.dk/2009/06/02/mosegaards-cloth-simulation-coding-tutorial/comment-page-1/#comment-23323</link>
		<dc:creator>rsq</dc:creator>
		<pubDate>Sat, 29 Dec 2012 03:53:30 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=147#comment-23323</guid>
		<description>very good  i understand it</description>
		<content:encoded><![CDATA[<p>very good  i understand it</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fun with oriented particles (do knot try this at home). by admin</title>
		<link>http://cg.alexandra.dk/2012/05/15/fun-with-oriented-particles-do-knot-try-this-at-home/comment-page-1/#comment-21484</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Fri, 07 Dec 2012 10:07:01 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1188#comment-21484</guid>
		<description>Hi yalmar

We won&#039;t be giving out the source code for the 3D implementation, but soon you will see a tutorial on a 2D version of the method on our blog.</description>
		<content:encoded><![CDATA[<p>Hi yalmar</p>
<p>We won't be giving out the source code for the 3D implementation, but soon you will see a tutorial on a 2D version of the method on our blog.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on WebGL Tutorial: Optimizing Data Transfer for WebGL Applications by tamat</title>
		<link>http://cg.alexandra.dk/2012/11/26/webgl-tutorial-optimizing-data-transfer-for-webgl-applications/comment-page-1/#comment-20759</link>
		<dc:creator>tamat</dc:creator>
		<pubDate>Tue, 27 Nov 2012 09:16:22 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1386#comment-20759</guid>
		<description>Nice post, although I would discourage the use of localStorage because it slows down the startup of the website (localStorage data is stored in a text file that is loaded synchronously when the user loads a website).</description>
		<content:encoded><![CDATA[<p>Nice post, although I would discourage the use of localStorage because it slows down the startup of the website (localStorage data is stored in a text file that is loaded synchronously when the user loads a website).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fun with oriented particles (do knot try this at home). by yalmar</title>
		<link>http://cg.alexandra.dk/2012/05/15/fun-with-oriented-particles-do-knot-try-this-at-home/comment-page-1/#comment-19761</link>
		<dc:creator>yalmar</dc:creator>
		<pubDate>Sat, 10 Nov 2012 04:55:43 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1188#comment-19761</guid>
		<description>Are there no source code? I would like experiment with your implementation. It looks really cool. great job!.</description>
		<content:encoded><![CDATA[<p>Are there no source code? I would like experiment with your implementation. It looks really cool. great job!.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Interactive infographics in WebGL by WebGL around the net, 8 November 2012 &#124; Learning WebGL</title>
		<link>http://cg.alexandra.dk/2012/10/12/interactive-infographics-in-webgl/comment-page-1/#comment-19698</link>
		<dc:creator>WebGL around the net, 8 November 2012 &#124; Learning WebGL</dc:creator>
		<pubDate>Thu, 08 Nov 2012 15:13:15 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=1284#comment-19698</guid>
		<description>[...] From Thomas Kjeldsen, an interactive view of data about Danish municipalities. [...]</description>
		<content:encoded><![CDATA[<p>[...] From Thomas Kjeldsen, an interactive view of data about Danish municipalities. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Noe&#039;s tutorial on deforming 3D geometry using RBFs by admin</title>
		<link>http://cg.alexandra.dk/2009/08/14/deforming-geometry-using-radial-basis-functions/comment-page-1/#comment-19586</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Mon, 05 Nov 2012 11:53:53 +0000</pubDate>
		<guid isPermaLink="false">http://cg.alexandra.dk/?p=312#comment-19586</guid>
		<description>To Nina

The work we used it for was this:

Surface membrane based bladder registration for evaluation of accumulated dose during brachytherapy in cervical cancer. K. Ø. Noe, K. Tanderup, T.S. Sørensen. IEEE International Symposium on Biomedical Imaging (ISBI) 2011.

We adopted the RBF method from here:

G. K. Matsopoulos, N. A. Mouravliansky, P. A. Asvestas, K. K. Delibasis, and V. Kouloulias. Thoracic non-rigid registration  combining selforganizing maps and radial basis functions. Medical Image Analysis, 9(3):237 – 254, 2005.</description>
		<content:encoded><![CDATA[<p>To Nina</p>
<p>The work we used it for was this:</p>
<p>Surface membrane based bladder registration for evaluation of accumulated dose during brachytherapy in cervical cancer. K. Ø. Noe, K. Tanderup, T.S. Sørensen. IEEE International Symposium on Biomedical Imaging (ISBI) 2011.</p>
<p>We adopted the RBF method from here:</p>
<p>G. K. Matsopoulos, N. A. Mouravliansky, P. A. Asvestas, K. K. Delibasis, and V. Kouloulias. Thoracic non-rigid registration  combining selforganizing maps and radial basis functions. Medical Image Analysis, 9(3):237 – 254, 2005.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
