Talk:HD Photo

From Wikipedia, the free encyclopedia

Contents 1 Working 2 Licensing 3 Miraculous claims 4 DRMs 5 Licensing? 6 Summary list of formats needs addition 7 Integer Ops

[edit] Working

I am working on this article. Please hang on for a day or two. --soUmyaSch 19:17, 12 May 2006 (UTC)

Done. --soUmyaSch 12:42, 15 May 2006 (UTC)

[edit] Licensing

Any idea of the licensing issues of this format? Is it patented? Free to use in any application? --WhiteDragon 14:11, 25 May 2006 (UTC)

You need to agree to a license agreement just to read the specs... I'll give you 3 guesses. —The preceding unsigned comment was added by 69.248.114.49 (talk • contribs).

Well, the format will most definitely be patented. But, how will it be licensed is still unclear. Most analysts propose MS to make it free from royalty for greater acceptance. They also feel doing so would greater promote use of Windows Media formats. --soUmyaSch 09:41, 26 May 2006 (UTC)

Licensing is now explained on Bill Crow's blog, there's a lot of new info there that could be added, so in the meantime I'm going to put a link to the blog on the article's links. ~ (22 July 2006)

Ultra-brief summary for lazy readers: free until 2010, free for small-volume use (up to 50,000 units per year), free for hosted applications. See Crow's blog for details.

The problem with the licence description is that the fact that it mentions 'opensource operating systems" - given there are multiple operating systems under different 'opensource licences' - the description needs to be rephrased as, "opensource operating systems licenced under the General Public Licence (GPL)" - Kaiwai (kaiwai dot gardiner at gmail dot com)

Onother licensing issue; don't know where the 'Compression Algorithm' bit came from but I have some strong thoughts it came from the HDPhoto Bitstream Specification 1.0. It is explicitily forbidden by the License Agreement accompanied in that document to distribute any part of the document and... Even better it is not allowed to use any of the reference material for a product other than one that can interface with a Microsoft product (Thus Windows)... Just some thoughts, don't know how to implement this on this page

[edit] Miraculous claims

A truly integer-only (that nonetheless handles floating-point color), block-based compression/decompression algorithm that performs more than twice as well as JPEG, while still retaining comparable computational cost? Unless i'm really behind on developments in the state of the art, this sounds way too good to be true.

Are there independent verifications of these claims, or at least slightly more concrete descriptions of the algorithm(s) in question? --Piet Delport 12:36, 27 May 2006 (UTC)

Well, I can't say you what exact algorithm MS is using, but the number of shifts and adds mentioned does sound fair to me. I am researching on a image format BTC-PF which does give comparable performance. As for compression ratio and quality, we still have to wait. And as for the integer/float stuff, no compression algorithm processes color info as it is. Rather they convert it to some format suitable for the algorithm. The transform is what is integer-only here. --soUmyaSch 12:57, 27 May 2006 (UTC)

With "performance", i mean the algorithm's compression performance, not the raw speed/computational cost. (In other words, what the quote "delivers a lossy compressed image of better perceptive quality than JPEG at less than half the file size" is talking about.)

And about the color conversion/transform: you can't just "convert" floating point data to integer and then back again. Their dynamic ranges are fundamentally different: if you simply round the floating point values to integer/fixed-point ones, you throw away pretty much the entire range/precision that floating point gives you to begin with. --Piet Delport 15:36, 27 May 2006 (UTC)

Yes floating pt numbers can be represented by integers without loss of data - use two different ints to store the mantissa and the exponent separately, and transform them into something else. I dunno exactly what they are doing there, but clever encoding techniques, under some constrained conditions can make integer ops simulate floating point arithmetic. Such tricks would be analoguous to using a 8-bit memory to store numbers 2³⁰ or even much more, under certain conditions. So by the amount of public info is there, neither way can be conclusively proved or disproved. We need to wait for more information to be disclosed, at least the codec be made available for use. --soUmyaSch 16:37, 27 May 2006 (UTC)

Sure, it's possible to emulate floating point arithmetic this way, but that doesn't make any sense in this context. It would just complicate the code, while also slowing it down (probably significantly; PC's don't have FPUs just for decoration).

Besides, even if this were done, it would still be "floating point", not "integer": using a superficially different representation of the parts of the floating point numbers does not change change the fact that the computation is still floating point, instead of integer/fixed point. --Piet Delport 20:25, 28 May 2006 (UTC)

What I am saying is that the info is from MS WMPhoto spec sheet. And as of now, info on WMPoto is a bit scarce. So we have to wait till the codec is released so that independent tests so what exactly it does. And emulating floating point arithmetic using integer ops can be sometimes faster provided a lot many other things are satisfied, such as using logarithms to represent the number and other such trickeries, and they do not make code bloat; rather they make possible computations which would have been impossible in given time/space constraints. But generally such trickeries hold for very specialized use, and I do agree that using it for image compression seems a little far-fetched. But as I said, we are still short on info as of now. Still, I will try to rewrite that bit as best as I can. Please help out as much if you can.--soUmyaSch 01:15, 29 May 2006 (UTC)

What concerns me is that that seems to be the least far-fetched of the claims. :)

I'm in favor of removing/commenting the claims, until a better/more solid citation can be found, as per Wikipedia:Verifiability. --Piet Delport 08:10, 29 May 2006 (UTC)

Well, removed the confusing bit for now. What do you think? --soUmyaSch 08:28, 29 May 2006 (UTC)

"Confusing bit"? The removed text looks sensible to me. :)

The miraculous-sounding compression performance claim are still there, however. --Piet Delport 10:33, 29 May 2006 (UTC)

What? U want to remove the performance claims? C'mon, the figures have been quoted by every publication now. U think it would be wise to remove that? And i removed the bit that stated integer ops handling floating pt color losslessly, something I presume you were confused with (A truly integer-only (that nonetheless handles floating-point color)). --soUmyaSch 12:21, 29 May 2006 (UTC)

I think you're getting the wrong idea here:

• I don't want to remove the performance claims, i want to correct them. I'm almost certain that they're simply being quoted out of context, or have otherwise been distorted in the telling. (The other possibility is that the claims really are completely true, and that Microsoft is harboring some earth-shattering new advances in data compression and information theory. As fantastic as this would be, i don't have my hopes up, though.)
• I was not "confused" by the integer/floating point bits; i was saying that, like the performance claims, they don't make much sense if you take them at face value, for reasons i already explained above.

In other words, these claims raise more questions than answers, and i think Wikipedia should be explaining them, or otherwise clarify the situation. (Which, in practical terms, probably means waiting for someone with access to more solid information about the algorithm to drop by and notice the talk page...) --Piet Delport 19:41, 29 May 2006 (UTC)

If you look at MS' spec sheet, the numbers have been quoted from there. And that spec sheet is the most authoritative source we have now (considering, the software is still not released). (Yes, even I do not entirely believe in the claims. I myself am researching on image and video compression and know that at that performance level, you most likely have to limit yourself to a "decent enough" quality :-) ). But still independent reports (reports by websites such as CNet) confirm that WMPhoto images "visibly contained more detail that JPEG and JPEG 2000" at same compression level. So I guess we have to believe in what MS states, as of now, till it is released and subsequently dissected. --soUmyaSch 11:12, 30 May 2006 (UTC)

I was at the WinHEC session presenting WMPhoto, so I can essentially verify the substance of their claims. One of the most telling slides was the comparison of error images between JPEG and WMPhoto. At half the bit rate, WMPhoto actually had more absolute error, but its distribution was very uniform and even, much like random noise, while the JPEG errors had the characteristic block structure, granules near edges, and so on. There is also the question of default settings for chroma subsampling. The capabilities do not differ significantly between the two formats, but most JPEG encoders do chroma subsampling by default, while WMPhoto does not. Lastly, limitations in JPEG's Ycc<->RGB conversion tend to systematically darken colors near the edge of the gamut, while WMPhoto solves this problem. Some of the "2x" benefit would be achievable by better tuning of JPEG implementations, but I do think it reasonably accurately represents what the average user will see in typical applications.--Raph Levien 20:30, 1 June 2006 (UTC)

Does that mean that the "half the bits" claim is comparing JPEG with subsampling against WMPhoto without subsampling? Intriguing.

[edit] DRMs

Will there be DRM on that format? David.Monniaux 13:47, 8 June 2006 (UTC)

No, at least, not in the near future. See the last comment on this blog entry. ~

[edit] Licensing?

How open will this format be? Will third parties be able to write plugins using this format? Will it be legally encumbered to sabotage any hope of interoperability? grendel|khan 17:45, 10 December 2006 (UTC)

Why would you suspect Microsoft of using a format standard to control and thwart interoperability? Have they ever done that before? Dicklyon 18:07, 10 December 2006 (UTC)

Microsoft has 15 issued U.S. patents that mention "lapped biorthogonal transform", mostly with inventor Henrique S. Malvar. Those might be a good source of public-domain description and drawings of their methods. Dicklyon 18:27, 10 December 2006 (UTC)

[edit] Summary list of formats needs addition

The list of audio/video formats at the bottom of this article needs to have some added links for physical media containers for audio/video for the major types of media used (DVD, SVCD, VCD, audio CD, etc).—The preceding unsigned comment was added by User:199.253.16.1 (talk • contribs).

[edit] Integer Ops

"Integer operations typically work faster than divides". i beleive this should be "integer operations typically work faster than floating point operations". there is an integer devide as an integer operation.