<?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: The JPEG Family Circus</title>
	<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/</link>
	<description>The 9 to 5 Life of an International Playboy</description>
	<pubDate>Sat, 22 Nov 2008 04:50:35 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: pixpush</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-2020</link>
		<author>pixpush</author>
		<pubDate>Tue, 15 Apr 2008 11:40:34 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-2020</guid>
		<description>Oh well, I'm not involved with them, just genuinely interested. :)
As you say, they should "open" it...so it gets implemented more easily.
But I personally do prefer something that - apparently - shows a higher quality than a new "wannabe" standard like JpegXR, and that is immediately compatible with "everything jpeg".
I mean, JpegXR can well never estabilish itself as a replacement for jpeg-1...(jpeg2000 never did) and for the sake of it, probably no format will ever do.
Unless...it's already "jpeg"! I think that's the real beauty of it.
I'm really curious to know the underlying algorithm as well...so if you "get to know it", just post on your blog! ;)

Oh, and how about the 48bit/pixel ?
HDR is still a pretty "niche" technology, but think about RAW formats (digital cameras, medical images etc.).
Now it's a total mess...and camera makers just cannot rely on a "not widely spread" image format (like HD Photo or Jpeg2000).
A "jpeg-compatible" RAW format...I think it would be killer. (again, given they open it)

Thanks for the reply!</description>
		<content:encoded><![CDATA[<p>Oh well, I&#8217;m not involved with them, just genuinely interested. <img src='http://jeffmatherphotography.com/dispatches_wp/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
As you say, they should &#8220;open&#8221; it&#8230;so it gets implemented more easily.<br />
But I personally do prefer something that - apparently - shows a higher quality than a new &#8220;wannabe&#8221; standard like JpegXR, and that is immediately compatible with &#8220;everything jpeg&#8221;.<br />
I mean, JpegXR can well never estabilish itself as a replacement for jpeg-1&#8230;(jpeg2000 never did) and for the sake of it, probably no format will ever do.<br />
Unless&#8230;it&#8217;s already &#8220;jpeg&#8221;! I think that&#8217;s the real beauty of it.<br />
I&#8217;m really curious to know the underlying algorithm as well&#8230;so if you &#8220;get to know it&#8221;, just post on your blog! <img src='http://jeffmatherphotography.com/dispatches_wp/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
<p>Oh, and how about the 48bit/pixel ?<br />
HDR is still a pretty &#8220;niche&#8221; technology, but think about RAW formats (digital cameras, medical images etc.).<br />
Now it&#8217;s a total mess&#8230;and camera makers just cannot rely on a &#8220;not widely spread&#8221; image format (like HD Photo or Jpeg2000).<br />
A &#8220;jpeg-compatible&#8221; RAW format&#8230;I think it would be killer. (again, given they open it)</p>
<p>Thanks for the reply!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1998</link>
		<author>Jeff Mather</author>
		<pubDate>Tue, 15 Apr 2008 01:57:02 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1998</guid>
		<description>Pixpush, I'm not sure if you're involved with Xdepth somehow -- it's getting harder for me to tell the difference these days between folks trying to pimp stuff in the comments and those who just really like something. 

It's an interesting approach that XDepth takes, stuffing HDR and wide-gamut support into (I assume) the application markers for JPEG.  Others have tried this before with inconsistent results.  EXIF took off, which makes sense, since you can use it or ignore it with impunity.  But Greg Ward's &lt;a href="http://portal.acm.org/citation.cfm?id=1198708" title="ACM - JPEG-HDR: a backwards-compatible, high dynamic range extension to JPEG" rel="nofollow"&gt;JPEG-HDR&lt;/a&gt; encoding hasn't gone anywhere.  I think the reason for that was it involved reinterpreting the RGB data, albeit in a "backward compatible" way.  (It's worth noting that JPEG-HDR is not a fundamentally different kind of JPEG encoding unlike JPEG-XR.)

Personally I'm really doubtful of the prospects for proprietary JPEG extensions, as compared to open ones like EXIF.  The computing world is moving away from closed formats.  And any extension to JPEG that changes the fundamental meaning of the data -- which it seems is what XDepth does -- seems like an uphill battle.

Best of luck to XDepth.  It would be interesting to know how it works.  Perhaps it actually uses the ideas in JPEG-HDR.  I guess we'll only know if they tell us.  (Although I will reverse engineer formats for fun and profit.)</description>
		<content:encoded><![CDATA[<p>Pixpush, I&#8217;m not sure if you&#8217;re involved with Xdepth somehow &#8212; it&#8217;s getting harder for me to tell the difference these days between folks trying to pimp stuff in the comments and those who just really like something. </p>
<p>It&#8217;s an interesting approach that XDepth takes, stuffing HDR and wide-gamut support into (I assume) the application markers for JPEG.  Others have tried this before with inconsistent results.  EXIF took off, which makes sense, since you can use it or ignore it with impunity.  But Greg Ward&#8217;s <a href="http://portal.acm.org/citation.cfm?id=1198708" title="ACM - JPEG-HDR: a backwards-compatible, high dynamic range extension to JPEG" rel="nofollow">JPEG-HDR</a> encoding hasn&#8217;t gone anywhere.  I think the reason for that was it involved reinterpreting the RGB data, albeit in a &#8220;backward compatible&#8221; way.  (It&#8217;s worth noting that JPEG-HDR is not a fundamentally different kind of JPEG encoding unlike JPEG-XR.)</p>
<p>Personally I&#8217;m really doubtful of the prospects for proprietary JPEG extensions, as compared to open ones like EXIF.  The computing world is moving away from closed formats.  And any extension to JPEG that changes the fundamental meaning of the data &#8212; which it seems is what XDepth does &#8212; seems like an uphill battle.</p>
<p>Best of luck to XDepth.  It would be interesting to know how it works.  Perhaps it actually uses the ideas in JPEG-HDR.  I guess we&#8217;ll only know if they tell us.  (Although I will reverse engineer formats for fun and profit.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pixpush</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1988</link>
		<author>pixpush</author>
		<pubDate>Mon, 14 Apr 2008 20:57:04 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1988</guid>
		<description>Great article, thanks!
I found this website - www.xdepth.com - where they claim they're able to "inject" most (all?) of the new features required in tomorrow's digital imaging in whatever "base format".
They've released some plugins to show High Dynamic Range "into" Jpeg-1...and it actually works very good. (it's got HDR while keeping compatibility with the jpeg-1 format)
If they come out with a "48 bit/pixel" version (RAW, or sort of...) as well, wouldn't this be a killer format, being already compatible with jpeg-1 ?</description>
		<content:encoded><![CDATA[<p>Great article, thanks!<br />
I found this website - <a href="http://www.xdepth.com" rel="nofollow">www.xdepth.com</a> - where they claim they&#8217;re able to &#8220;inject&#8221; most (all?) of the new features required in tomorrow&#8217;s digital imaging in whatever &#8220;base format&#8221;.<br />
They&#8217;ve released some plugins to show High Dynamic Range &#8220;into&#8221; Jpeg-1&#8230;and it actually works very good. (it&#8217;s got HDR while keeping compatibility with the jpeg-1 format)<br />
If they come out with a &#8220;48 bit/pixel&#8221; version (RAW, or sort of&#8230;) as well, wouldn&#8217;t this be a killer format, being already compatible with jpeg-1 ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1175</link>
		<author>Jeff Mather</author>
		<pubDate>Mon, 10 Mar 2008 00:22:45 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1175</guid>
		<description>Sergio,

One of the things I do in my job is keep track of all of the various formats out there for imagery as well as the compression methods that they use.

There are literally hundreds of formats out there, so each new format faces an enormous challenge making any kind of dent.  Standardization does help, but usually you need a good &lt;i&gt;raison d'être&lt;/i&gt; to get people to join on your standardization committee.  Being Microsoft or Adobe really helps, too.

Why make a new format or compression mode?  Most people get the answer wrong.  The answer is not because you have something that provides marginal improvement over existing solution.  Worse yet is that the format works well in one particular, application-specific context.  (I'm not saying PGF does either of these.  I haven't looked at it.)

Instead you should &lt;b&gt;think seriously&lt;/b&gt; about whether it enables new solutions.  Right now these solutions &#8212; high dynamic range imaging, nondestructive image editing, video and imagery from mobile devices, etc. &#8212; might need:

&lt;ul&gt;
&lt;li&gt;Support for bit-depths that are in use in consumer electronics (or soon will be)&lt;/li&gt;
&lt;li&gt;Wider color gamuts&lt;/li&gt;
&lt;li&gt;Richer metadata support, such as geolocation&lt;/li&gt;
&lt;li&gt;Lower power consumption by the codec&lt;/li&gt;
&lt;/ul&gt;


Once you've thought about whether you have something to add, step back and &lt;b&gt;think again&lt;/b&gt;.  Many of these problems already have solutions &#8212; such as XMP metadata, color appearance modeling, etc. &#8212; and formats that are capable of plugging in these solutions.  For example, you can add just about anything to TIFF, and HD-Photo looks like a winner going forward.

I'm not saying you shouldn't innovate or make improvements on existing technologies.  But you should seriously question whether your innovations and improvements will be spectacular enough to get many adherents.

And if you say, "Well, it's a proprietary format that people will only use with the software that we create or license," then you really need to stop.  People's data is not something to be owned by a software company.  It's the height of hubris to think that your software is the way that people should be accessing their data &lt;b&gt;forever&lt;/b&gt; or that you in some way own their use of it.

Finally, there's the "&lt;a href="http://www.imdb.com/title/tt0289043/" rel="nofollow"&gt;28 Days Later&lt;/a&gt;" phenomena.  For those who haven't seen the film, it's your much better-than-average zombie movie where a virus gets loose from a government lab and destroys humanity as we know it.  The analogy with new formats is a bit doomsday, I will grant you, but the cause is the same: Someone thinks that they're making a special purpose format that's never meant to see the light of day because it's (you know) "internal use only" and the next thing you know, people are asking the makers of third-party software to support the (usually) undefined file format.  Tell your grad student to implement a lightweight interface to libTIFF or HDF5 if you "need a new file format."

Once again . . . I'm not saying that the creators of PGF have any of these faults, but I've seen it over and over.  Here ends my public service announcement.</description>
		<content:encoded><![CDATA[<p>Sergio,</p>
<p>One of the things I do in my job is keep track of all of the various formats out there for imagery as well as the compression methods that they use.</p>
<p>There are literally hundreds of formats out there, so each new format faces an enormous challenge making any kind of dent.  Standardization does help, but usually you need a good <i>raison d&#8217;être</i> to get people to join on your standardization committee.  Being Microsoft or Adobe really helps, too.</p>
<p>Why make a new format or compression mode?  Most people get the answer wrong.  The answer is not because you have something that provides marginal improvement over existing solution.  Worse yet is that the format works well in one particular, application-specific context.  (I&#8217;m not saying PGF does either of these.  I haven&#8217;t looked at it.)</p>
<p>Instead you should <b>think seriously</b> about whether it enables new solutions.  Right now these solutions &mdash; high dynamic range imaging, nondestructive image editing, video and imagery from mobile devices, etc. &mdash; might need:</p>
<ul>
<li>Support for bit-depths that are in use in consumer electronics (or soon will be)</li>
<li>Wider color gamuts</li>
<li>Richer metadata support, such as geolocation</li>
<li>Lower power consumption by the codec</li>
</ul>
<p>Once you&#8217;ve thought about whether you have something to add, step back and <b>think again</b>.  Many of these problems already have solutions &mdash; such as XMP metadata, color appearance modeling, etc. &mdash; and formats that are capable of plugging in these solutions.  For example, you can add just about anything to TIFF, and HD-Photo looks like a winner going forward.</p>
<p>I&#8217;m not saying you shouldn&#8217;t innovate or make improvements on existing technologies.  But you should seriously question whether your innovations and improvements will be spectacular enough to get many adherents.</p>
<p>And if you say, &#8220;Well, it&#8217;s a proprietary format that people will only use with the software that we create or license,&#8221; then you really need to stop.  People&#8217;s data is not something to be owned by a software company.  It&#8217;s the height of hubris to think that your software is the way that people should be accessing their data <b>forever</b> or that you in some way own their use of it.</p>
<p>Finally, there&#8217;s the &#8220;<a href="http://www.imdb.com/title/tt0289043/" rel="nofollow">28 Days Later</a>&#8221; phenomena.  For those who haven&#8217;t seen the film, it&#8217;s your much better-than-average zombie movie where a virus gets loose from a government lab and destroys humanity as we know it.  The analogy with new formats is a bit doomsday, I will grant you, but the cause is the same: Someone thinks that they&#8217;re making a special purpose format that&#8217;s never meant to see the light of day because it&#8217;s (you know) &#8220;internal use only&#8221; and the next thing you know, people are asking the makers of third-party software to support the (usually) undefined file format.  Tell your grad student to implement a lightweight interface to libTIFF or HDF5 if you &#8220;need a new file format.&#8221;</p>
<p>Once again . . . I&#8217;m not saying that the creators of PGF have any of these faults, but I&#8217;ve seen it over and over.  Here ends my public service announcement.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SergioGuru</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1174</link>
		<author>SergioGuru</author>
		<pubDate>Sun, 09 Mar 2008 22:57:53 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-1174</guid>
		<description>Thanks for great summary post. It's interesting why PGF (even has Wiki page - &lt;a href="http://en.wikipedia.org/wiki/Progressive_Graphics_File" rel="nofollow"&gt;http://en.wikipedia.org/wiki/Progressive_Graphics_File&lt;/a&gt;) has not spread more. Well, marketing ... I've found some first news releases of HD-Photo very similar to PGF benefits. More and code for PGF at http://www.libpgf.org.

Anyway, it the standards that win. That's why we have fractal image compression (mainly from past Iterated Systems) only in some very niche software products.</description>
		<content:encoded><![CDATA[<p>Thanks for great summary post. It&#8217;s interesting why PGF (even has Wiki page - <a href="http://en.wikipedia.org/wiki/Progressive_Graphics_File" rel="nofollow">http://en.wikipedia.org/wiki/Progressive_Graphics_File</a>) has not spread more. Well, marketing &#8230; I&#8217;ve found some first news releases of HD-Photo very similar to PGF benefits. More and code for PGF at <a href="http://www.libpgf.org." rel="nofollow">http://www.libpgf.org.</a></p>
<p>Anyway, it the standards that win. That&#8217;s why we have fractal image compression (mainly from past Iterated Systems) only in some very niche software products.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: "Wireless JPEG2000 Video and a Paper on How JPEG2000 Works" in Disruptive Library Technology Jester</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-639</link>
		<author>"Wireless JPEG2000 Video and a Paper on How JPEG2000 Works" in Disruptive Library Technology Jester</author>
		<pubDate>Tue, 08 Jan 2008 17:16:33 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-639</guid>
		<description>[...] 20080108T1213 : Add to this now a posting by Jeff Mather that describes the various compression schemes and file formats that share .... Do you think there is only one, or possibly two, &#8220;JPEG&#8221; standards. Read Jeff&#8217;s [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] 20080108T1213 : Add to this now a posting by Jeff Mather that describes the various compression schemes and file formats that share &#8230;. Do you think there is only one, or possibly two, &#8220;JPEG&#8221; standards. Read Jeff&#8217;s [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Mather</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-638</link>
		<author>Jeff Mather</author>
		<pubDate>Tue, 08 Jan 2008 15:58:17 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-638</guid>
		<description>Thanks for the pointer, Ron.

Just to be clear, I think that JPEG-2000 has a future which will include both industrial and consumer applications, just not the same ones that were proposed by its earliest proponents.

I don't think that JPEG-2000 is going to be the replacement for JPEG on the web or in digital still camera workflows. But I do think it will (eventually) replace a bunch of proprietary lossless and wavelet-based compression formats. We've been seeing evidence of this already in the digital cinema and TV realms.

Consider &lt;a href="http://www.jpeg.org/newsrel19.html" rel="nofollow"&gt;this July 2007 press release&lt;/a&gt;: "The success of JPEG 2000 in Digital Cinema continues to grow as the Digital Cinema Initiatives (www.dcimovies.com) has recently approved the JPEG 2000 based DCI specification 1.1 for distribution of digital movies to theatres/cinemas worldwide. The strength of Digital Cinema is apparent with nearly 4,000 JPEG 2000 compliant servers deployed and nearly 5,000 systems expected by the end of 2007. The most recent JPEG 2000 digital cinema releases include Transformers from Paramount Pictures and Harry Potter and the Order of the Phoenix from Warner Bros."

(Too bad "Transformers" was such a terrible film . . .)</description>
		<content:encoded><![CDATA[<p>Thanks for the pointer, Ron.</p>
<p>Just to be clear, I think that JPEG-2000 has a future which will include both industrial and consumer applications, just not the same ones that were proposed by its earliest proponents.</p>
<p>I don&#8217;t think that JPEG-2000 is going to be the replacement for JPEG on the web or in digital still camera workflows. But I do think it will (eventually) replace a bunch of proprietary lossless and wavelet-based compression formats. We&#8217;ve been seeing evidence of this already in the digital cinema and TV realms.</p>
<p>Consider <a href="http://www.jpeg.org/newsrel19.html" rel="nofollow">this July 2007 press release</a>: &#8220;The success of JPEG 2000 in Digital Cinema continues to grow as the Digital Cinema Initiatives (www.dcimovies.com) has recently approved the JPEG 2000 based DCI specification 1.1 for distribution of digital movies to theatres/cinemas worldwide. The strength of Digital Cinema is apparent with nearly 4,000 JPEG 2000 compliant servers deployed and nearly 5,000 systems expected by the end of 2007. The most recent JPEG 2000 digital cinema releases include Transformers from Paramount Pictures and Harry Potter and the Order of the Phoenix from Warner Bros.&#8221;</p>
<p>(Too bad &#8220;Transformers&#8221; was such a terrible film . . .)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ron M.</title>
		<link>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-637</link>
		<author>Ron M.</author>
		<pubDate>Tue, 08 Jan 2008 15:28:44 +0000</pubDate>
		<guid>http://jeffmatherphotography.com/dispatches/2008/01/the-jpeg-family-circus/#comment-637</guid>
		<description>On the same Google Alert that uncovered this blog entry came one that revealed that JPEG 2000 is coming to marked in wireless HDTV systems (http://www.gearlive.com/news/article/q307-westinghouse-wireless-hdtv/).

While the market dynamics will not repeat the past in this case, recall that 35mm still photography came into being as a side effect of the film industry. In any case this means that in the near future, the nearest J2K codec might just be in your TV.

Somewhat creepily, JPEG 2000 is also gaining quite a presence in surveillance systems, an is, I believe, the image format for the new US biometric passports.</description>
		<content:encoded><![CDATA[<p>On the same Google Alert that uncovered this blog entry came one that revealed that JPEG 2000 is coming to marked in wireless HDTV systems (http://www.gearlive.com/news/article/q307-westinghouse-wireless-hdtv/).</p>
<p>While the market dynamics will not repeat the past in this case, recall that 35mm still photography came into being as a side effect of the film industry. In any case this means that in the near future, the nearest J2K codec might just be in your TV.</p>
<p>Somewhat creepily, JPEG 2000 is also gaining quite a presence in surveillance systems, an is, I believe, the image format for the new US biometric passports.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
