<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Microsoft HD Photo</title>
	<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/</link>
	<description>The 9 to 5 Life of an International Playboy</description>
	<pubDate>Fri, 09 Jan 2009 23:52:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-617</link>
		<author>Jeff Mather</author>
		<pubDate>Fri, 04 Jan 2008 20:58:01 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-617</guid>
		<description>&lt;b&gt;UPDATE&lt;/b&gt;: After &lt;a href="http://forums.dpreview.com/forums/read.asp?forum=1000&#38;message=18663471" rel="nofollow"&gt;reading more&lt;/a&gt; of that thread about the new DCT-based JPEG proposal (T.851) put forward by some members of the IJG, I'm far less inclined to lend credence to their complaints about JPEG-XR and prospects for a "new" JPEG that isn't JPEG-XR.

In particular, JPEG-XR has better file size performance, better PSNR performance, (probably) better computational performance; is less blocky than the DCT-based "new" JPEG; supports more bit-depths; and actually exists in an implemented and tested form.</description>
		<content:encoded><![CDATA[<p><b>UPDATE</b>: After <a href="http://forums.dpreview.com/forums/read.asp?forum=1000&amp;message=18663471" rel="nofollow">reading more</a> of that thread about the new DCT-based JPEG proposal (T.851) put forward by some members of the IJG, I&#8217;m far less inclined to lend credence to their complaints about JPEG-XR and prospects for a &#8220;new&#8221; JPEG that isn&#8217;t JPEG-XR.</p>
<p>In particular, JPEG-XR has better file size performance, better PSNR performance, (probably) better computational performance; is less blocky than the DCT-based &#8220;new&#8221; JPEG; supports more bit-depths; and actually exists in an implemented and tested form.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-615</link>
		<author>Jeff Mather</author>
		<pubDate>Fri, 04 Jan 2008 14:44:12 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-615</guid>
		<description>I have some experience implementing JPEG-2000 and think that it would make a good archival format. The pros of using JPEG-2000:

&lt;ul&gt;
&lt;li&gt;All of the things you noted: open standards, lossless compression, infinitely flexible metadata boxes.&lt;/li&gt;
&lt;li&gt;It's not patent-bound and has been implemented by several vendors on many platforms (unlike HD Photo).&lt;/li&gt;
&lt;li&gt;It supports high bit-depth images (such as 16 bits/channel).&lt;/li&gt;
&lt;li&gt;The lossy modes use wavelets that produce virtually no artifacts if you use the right quality settings, and the artifacts that show up at lower bit-rates look much better than classic JPEG. (&lt;a href="http://dclunie.com/papers/spie_mi_2000_foos.pdf" rel="nofollow"&gt;Medical image archivists prefer lossy JPEG-2000 to lossy JPEG&lt;/a&gt;.)&lt;/li&gt;
&lt;li&gt;Image storage can be optimized in a variety of ways for different disciplines. It's possible to transcode the images between these optimizations without recompressing the data.&lt;/li&gt;
&lt;li&gt;Different parts of the image can have different quality settings.&lt;/li&gt;
&lt;li&gt;You can store an image at a very high quality level &#8212; producing a rather large archive copy &#8212; and then decode it at lower quality settings, which might be useful when streaming data to the web or generating previews, for example.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;There are a couple of cons:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;It's a very complicated format, which means that you'll need to license a commercial product to develop a new application that uses many of its features. Jasper, an open-source solution, is just too slow. I recommend &lt;a href="http://www.kakadusoftware.com/" rel="nofollow"&gt;Kakadu&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;It hasn't been widely adopted in the consumer realm. This means that you'll likely need to provide JPEG 2000 viewers to your end users or convert the archive images to another format if you're serving them over the web.&lt;/li&gt;
&lt;/ul&gt;</description>
		<content:encoded><![CDATA[<p>I have some experience implementing JPEG-2000 and think that it would make a good archival format. The pros of using JPEG-2000:</p>
<ul>
<li>All of the things you noted: open standards, lossless compression, infinitely flexible metadata boxes.</li>
<li>It&#8217;s not patent-bound and has been implemented by several vendors on many platforms (unlike HD Photo).</li>
<li>It supports high bit-depth images (such as 16 bits/channel).</li>
<li>The lossy modes use wavelets that produce virtually no artifacts if you use the right quality settings, and the artifacts that show up at lower bit-rates look much better than classic JPEG. (<a href="http://dclunie.com/papers/spie_mi_2000_foos.pdf" rel="nofollow">Medical image archivists prefer lossy JPEG-2000 to lossy JPEG</a>.)</li>
<li>Image storage can be optimized in a variety of ways for different disciplines. It&#8217;s possible to transcode the images between these optimizations without recompressing the data.</li>
<li>Different parts of the image can have different quality settings.</li>
<li>You can store an image at a very high quality level &mdash; producing a rather large archive copy &mdash; and then decode it at lower quality settings, which might be useful when streaming data to the web or generating previews, for example.</li>
</ul>
<p>There are a couple of cons:</p>
<ul>
<li>It&#8217;s a very complicated format, which means that you&#8217;ll need to license a commercial product to develop a new application that uses many of its features. Jasper, an open-source solution, is just too slow. I recommend <a href="http://www.kakadusoftware.com/" rel="nofollow">Kakadu</a>.</li>
<li>It hasn&#8217;t been widely adopted in the consumer realm. This means that you&#8217;ll likely need to provide JPEG 2000 viewers to your end users or convert the archive images to another format if you&#8217;re serving them over the web.</li>
</ul>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Murray</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-614</link>
		<author>Peter Murray</author>
		<pubDate>Fri, 04 Jan 2008 13:52:38 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-614</guid>
		<description>Thanks for the clarification, Jeff.  I'm particularly interested in &lt;a href="http://dltj.org/2007/02/jpeg2000-for-digital-preservation/" title="&#39;JPEG2000 for Digital Preservation&#39; in Disruptive Library Technology Jester" rel="nofollow"&gt;JPEG2000 as a preservation format for cultural heritage materials&lt;/a&gt;.  It's nature as an open standard, lossless compression, and infinitely flexible metadata boxes makes it ideally suited as a replacement for my community's current TIFF practice.  As such, &lt;a href="http://dltj.org/2007/08/hd-photo-versus-jpeg2000/" title="&#39;JPEG XR Could Be Neat, but JPEG2000 is Still Neater%#039; in Disruptive Library Technology Jester" rel="nofollow"&gt;I have some concerns about some aspects of Microsoft Photo HD&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Thanks for the clarification, Jeff.  I&#8217;m particularly interested in <a href="http://dltj.org/2007/02/jpeg2000-for-digital-preservation/" title="&#39;JPEG2000 for Digital Preservation&#39; in Disruptive Library Technology Jester" rel="nofollow">JPEG2000 as a preservation format for cultural heritage materials</a>.  It&#8217;s nature as an open standard, lossless compression, and infinitely flexible metadata boxes makes it ideally suited as a replacement for my community&#8217;s current TIFF practice.  As such, <a href="http://dltj.org/2007/08/hd-photo-versus-jpeg2000/" title="&#39;JPEG XR Could Be Neat, but JPEG2000 is Still Neater%#039; in Disruptive Library Technology Jester" rel="nofollow">I have some concerns about some aspects of Microsoft Photo HD</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-598</link>
		<author>Jeff Mather</author>
		<pubDate>Thu, 03 Jan 2008 19:32:51 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-598</guid>
		<description>Hi Peter,

I mean the real JPEG-2000 standard (ISO/IEC 15444-1 and i5444-2) &#8212; the one that preceeded HD Photo. JPEG-2000 is a very good compression standard and format, but it has the most complicated interaction between compression and image storage that I have ever seen.

I have only recently started looking at JPEG-XR, but some JPEG folks &lt;a href="http://forums.dpreview.com/forums/read.asp?forum=1000&#38;message=18649764" rel="nofollow"&gt;don't think much of it&lt;/a&gt;. I have no opinion yet.</description>
		<content:encoded><![CDATA[<p>Hi Peter,</p>
<p>I mean the real JPEG-2000 standard (ISO/IEC 15444-1 and i5444-2) &mdash; the one that preceeded HD Photo. JPEG-2000 is a very good compression standard and format, but it has the most complicated interaction between compression and image storage that I have ever seen.</p>
<p>I have only recently started looking at JPEG-XR, but some JPEG folks <a href="http://forums.dpreview.com/forums/read.asp?forum=1000&amp;message=18649764" rel="nofollow">don&#8217;t think much of it</a>. I have no opinion yet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Murray</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-595</link>
		<author>Peter Murray</author>
		<pubDate>Thu, 03 Jan 2008 16:52:42 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/microsoft-hd-photo/#comment-595</guid>
		<description>Just for clarification, when you speak of JPEG2000 in your posting, do you mean JPEG2000 as it was known before Microsoft HD Photo came along?  Or do you mean JPEG-XR, the Microsoft-contributed specification that was &lt;a href="http://www.itscj.ipsj.or.jp/sc29/29w02901.pdf" rel="nofollow"&gt;recently moved to ballot status as a committee draft&lt;/a&gt;?</description>
		<content:encoded><![CDATA[<p>Just for clarification, when you speak of JPEG2000 in your posting, do you mean JPEG2000 as it was known before Microsoft HD Photo came along?  Or do you mean JPEG-XR, the Microsoft-contributed specification that was <a href="http://www.itscj.ipsj.or.jp/sc29/29w02901.pdf" rel="nofollow">recently moved to ballot status as a committee draft</a>?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
