Microsoft's HD Photo to Become JPEG Standard?

Mortimer.CA writes "Ars Technica is reporting that Microsoft has submitted their HD Photo to the JPEG committee: 'Microsoft's ongoing attempt to establish its own photo format as a JPEG alternative (and potential successor) took another step forward today when the JPEG standards group agreed to consider HD Photo (originally named Windows Media Photo) as a standard. If successful, the new file standard will be known as JPEG XR.' Microsoft has made a 'commitment to make its patents that are required to implement the specification available without charge.' While JPEG 2000 exists, HD Photo has several advantages (not the least of which is a lot less CPU power is needed). Is this a big of an issue as ODF/OOXML?"

Re:can this be the only solution?

[St. Arbirix]

They've made what appears to be a legally binding promise they aren't going to dick people over this one using their Open Specification Promise [microsoft.com]. Whereas the OOXML vs. ODF debate has good grounding in one specification being lower quality than the other, HDPhoto really is an improvement over current formats, especially for handling raw images.

Re:could someone enlighten me?

[everphilski]

Your digital camera puts out 500kb native resolution files?

Here's the specification

[Anonymous Coward]

The specification is available at http://www.microsoft.com/whdc/xps/wmphoto.mspx [microsoft.com] to look at.

Here's the text of what you need to agree to in order to download the specification. It doesn't seem particularly bad except the patent bit. It remains to be seen if the JPEG changes actually clear that up.

Microsoft Corporation Technical Documentation License Agreement for the specification "HD Photo"

READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION ("MICROSOFT") AND THE RECIPIENT OF THE ABOVE REFERENCED MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY ("YOU"). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF DOWNLOADING THESE MATERIALS ("MATERIALS") FROM A MICROSOFT WEB SITE, BY CLICKING "I ACCEPT", DOWNLOADING, USING OR PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS, YOU ARE NOT AUTHORIZED TO ACCESS, DOWNLOAD, USE OR REVIEW THE MATERIALS.

For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows:

1. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a Microsoft product, specification, service or technology ("Microsoft Product") as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this Agreement does not give You rights under any Microsoft patents. You may not (i) duplicate any part of these Materials, (ii) remove this Agreement or any notices from these Materials, or (iii) give any part of these Materials, or assign or otherwise provide Your rights under this Agreement, to anyone else.

2. These Materials may contain preliminary information or inaccuracies, and may not correctly represent any associated Microsoft Product as commercially released. All Materials are provided entirely "AS IS." To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.

3. If You are an entity and (a) merge into another entity or (b) a controlling ownership interest in You changes, Your right to use these Materials automatically terminates and You must destroy them.

4. You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to these Materials. However, any Feedback you voluntarily provide may be used in Microsoft Products and related specifications or other documentation (collectively, "Microsoft Offerings") which in turn may be relied upon by other third parties to develop their own products, services or technology ("Third Party Products"). Accordingly, if You do give Microsoft Feedback on any version of these Materials or the Microsoft Offerings to which they apply, You agree: (a) Microsoft may freely use, reproduce, license, distribute, and otherwise commercialize Your Feedback in any Microsoft Offering; (b) You also grant third parties, without charge, only those patent rights necessary to enable Third Party Products to use, implement or interface with any specific parts of a Microsoft Product that incorporate Your Feedback; and (c) You will not give Microsoft any Feedback (i) that You have reason to believe is subject to any patent, copyright or other intellectual property claim or right of any third party; or (ii) subject to license terms which seek to require any Microsoft Offering incorporating or derived from such Feedback, or other Microsoft intellectual property, to be licensed to or otherwise shared with any third party.

5. Microsoft has no obligation to maintain the confidentiality of any Microsoft

Re:can this be the only solution?

[morgan_greywolf]

Microsoft's license for OOXML, for instance, does not include a patent license; only a promise not to sue, so long as your implementation only uses the necessary portions of details described in the specification, and not details referenced by the specification. IOW, to create an OOXML document importer or exporter, you end up recreating a lot of Microsoft code that isn't covered.

So 1) you can't use code based on the specification in a GPL V2 or GPL V3 program, because you can't satisfy the patent clause, and 2) you can't write any program based on the specification, because Microsoft only promises not sue you for implementing the specification, not for any supporting code that you would need to write to implement the specification.

See http://fussnotes.typepad.com/plexnex/2007/01/analy zing_the_m.html [typepad.com] for example.

MS patents

[SillySilly]

One of the requirements of the JPEG comittee for this proposed standard is that Microsoft (and all other participants of this process) provide their patents on a free and non-discriminatory basis. Free as in beer, no money. Non-discriminatory meaning that anyone can license them; Microsoft can't say that only certain developers are "cool enough" or "good enough" to receive a license. Many of the JPEG standards operate under these terms: the baseline process of the original JPEG, JPEG2000 part 1, and others.

It's A Trap. EULA to view the specs

[mpapet]

It just so happens I am planning an HD Image product, service or technology and the spec is totally hostile to everyone BUT microsoft. (no surprise there)

1. 1. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a Microsoft product, specification, service or technology

Mac/Linux/BSD? Nope. So, that appears to rule out web-based stuff. Fortunately, I'm only working on Windows, so I'll read on. ...You may not (i) duplicate any part of these Materials
Okay I won't. But how does my engineering group work with the spec if I can't duplicate it?

any Feedback you voluntarily provide may be used in Microsoft Products
Okay, I won't provide any feedback. It was once believed that developers were Microsoft's focus. Apparently not anymore.

Without going into specifics because the EULA prevents it, there are proprietary elements hidden inside this spec.

It's clear they are *very* late to the pro-photo fight that is on now between Apple and Adobe. Each of those companies has a proprietary "pro photo" format.

Sadly most pro photographers won't think about the consequences of adopting proprietary formats until it is too late. For example, some legacy proprietary raw images as provided by the camera manufacturers are not backward compatible. I've read it in the mailing lists already.

Re:could someone enlighten me?

[TheRaven64]

OK, how about a 1GB file? (8 megapixel * 32 bits/CYMK)

I'm not sure how you work that out. 32-bits per channel, CMYK (i.e. 4 channels), gives 16 bytes per channel. For an 8 megapixel image, that's a 128MB image. I'm not sure what kind of camera generates a CMYK image, since CMYK is subtractive mixing, and cameras record light, so RGB seems more likely, giving only three channels. Most CCDs are at most 12 or 14bits. At 14 bits per channel, this only gives 42MB for an uncompressed 8 megapixel image. Raw formats often include two green values for each pixel (or a cyan one for some), to closer match human eyes, bringing us back to 4 channels, requiring 56MB. Even with a raw image, we are still a long way away from 1GB/image.

You won't get to CMYK or 32 bits per channel from a source image and if you're sane then you won't ever store this image (unless you're exporting for a print fun), you'll store the sequence of transforms on the original image. Destructive editing is a quaint idea, but not a good one.

Re:can this be the only solution?

[Daniel Phillips]

Though it almost makes we want to spit my coffee, I have to say that I do not see anything evil here... yet. Quite the contrary, it would seem on first blush. An RF grant is pretty clearcut, see the big discussion about that leading up to the famous W3 decision to require RF grants for all new web standards.

Still, there are still ways to game an RF grant, for example, nothing stops Microsoft from supporting slightly off-standard formats in its own software and refusing to grant an RF license covering those changes to other implementors, using the argument that the original RF grant does not cover any extensions. I suppose the big question is, are other implementors free to extend the format also or does the RF grant evaporate as soon as an implementor extends the standard, perhaps in an effort to match Microsoft's own extensions? In which case the playing field would be far from level, and we have seen all too many times what happens when Microsoft manages to tilt the playing field. I simply haven't drilled into this enough to know what is true here, and no doubt, close readers will find other aspects of the grant to worry about.

Re:FP

[RegularFry]

Specs, licence and example code are here: http://www.microsoft.com/downloads/thankyou.aspx?f amilyId=285eeffd-d86c-48c3-ab93-3abd5ee7f1ce&displ ayLang=en [microsoft.com]

Re:it's A Trap

[RegularFry]

Or alternatively, we could do a little research and find the sample code [microsoft.com] that MS have released for writing a codec. Admittedly, the licence on the example code precludes including exactly that code in a GPL'd project, but a reimplementation looks to be clear... hardly "jealously guarded".

Honestly, MS are behaving oddly with this one. It's technically a good standard, they've backed down from a restrictive licence scheme they were going to use, and they've showed everybody how to use it. I can't help wondering what they're up to...

Re:could someone enlighten me?

[akreps]

Most importantly, lossless compression might mean that you don't need to shoot in RAW all the time, and be at the camera manufacturer's mercy.

Actually, RAW has a number of advantages over simple lossless compression. My camera's RAW format stores the raw data that the sensor recorded (along with a slew of camera settings), which is more than a simple RGB value. After the photo has been taken, I can change the values that the sensor interpreted, which allows me much more freedom than only being able to adjust the color and/or brightness. For example, the RAW format gives me the ability to change a day scene to night and vice versa without blowing out the exposure.

Re:Deja GIF.

[LionMage]

I'm one of the co-authors of the PNG spec, so I will give my answers to your questions. I can't claim to speak for the other PNG spec authors.

Where does PNG fit into the [paradigm]? I mean, I know it's got more advanced alpha transparency than gif, and I think that it's based on plain ol' bitmaps as opposed to compression, so it seems like a strict successor to GIF...

PNG was always intended to replace GIF and be a "better GIF than GIF." PNG is also a more-than-adequate replacement for most common TIFF variants, because you can do almost everything that TIFF can do, but with less complexity (fewer choices for implementation, simpler format, and no optional format features you can't live without that some readers may choose to ignore) and less ambiguity in the spec. The less ambiguity bit is important, since the TIFF spec's ambiguity is one of the main reasons that TIFF files written by one application may not be readable by another application -- even if both apps support the same TIFF extensions.

PNG has compression -- it uses deflate (LZ77 + Huffman coding) instead of GIF's formerly-patent-encumbered LZW algorithm. The key here is lossless compression, so unlike bog-standard JPEG, PNG images are great for archiving exact image data. Radiologists like the fact that PNG can store grayscale images with 16-bit-per-pixel accuracy, in complete image fidelity.

Yes, PNG has better alpha channel support than GIF (although it has a special palette-based transparency feature similar to GIF89's transparency, mainly to ease the transition from GIF to PNG). It also has a better interlacing scheme, for progressive rendering of images when your data pipe is constrained. Set-top-box developers like this feature.

Where PNG fails with high def photos and the like is the lack of floating point representation of pixel data, which limits the kind of High Dynamic Range stuff you can do with it. PNG has chunk types which can contain many of the kinds of meta-data that you would care about for digital photography and scanned artwork, but much of the reader code out there does nothing with this meta-data.

However, gif still has some legs up on it, namely ubiquity and the fact that animated PNGs support doesn't seem to be remotely common.

Actually, PNG doesn't support animation at all. The animated sister format is MNG. Animated GIFs are kind of a poor animation format anyway, but they're great for small-size effects on web pages. MNG support in browsers is non-existent, so this has paradoxically limited PNG's uptake (and made GIF more difficult to kill).

Re:floating point colour

[The Raven]

Most image formats treat color as a series of discrete values. For example, I could have a black dot (0 red, 0 green, 0 blue), or a white dot (255 red, 255 green, 255 blue, the highest possible values), or any color in between. Well... 'any' color is kind of misleading. The numbers have to go up by a full step each time. While it can be difficult, to the discerning eye you can see the 'line' between a wash of (0,0,0) color and a wash of (1,0,1) color. The color 'jumps', and for certain types of images the jump can be noticeable and ugly. Plus, there is the additional problem of how you represent REALLY bright colors... for example, you can have a white wall, and then next to it the SUN... the sun a hundreds or thousands of times as bright as the wall, but they're both labeled the same... this makes it hard to really show them accurately.

Floating point color means that instead of having a fixed range of color values (0 to 255, or 0 to 65535, or 0 to 16.7 million), you open it up to allow nearly any value, by allowing decimals.

0.1, 15.73332, 2.31 * 10e13 (exponential notation, equivalent to 23100000000000). Floating point values aren't more precise than integers, but they have a wider range. This lets computers represent the range of brightnesses in a sunset shot (bright sun, nearly dark foreground) in a way that allows us to see a lot more detail, and give us far more flexibility in how to expose and display the image.

Re:Deja GIF.

[LionMage]

I already addressed this issue in a sibling comment to yours, but I figured I'd address this specific point here (as I'm one of the authors of the PNG spec).

PNG was only ever intended to be a format to store image data, not animation data. The use of GIF animations wasn't very widespread when the GIF LZW patent crisis prompted a group of developers to work on the PNG specification. MNG is the sister format, is specifically intended to cover animation applications, and builds upon the PNG specification. (Without glancing at the specs, I recall that a PNG is more-or-less a valid MNG file, but not the other way around -- MNG is therefore a superset of PNG. Although I worked on the PNG spec, I have no real connection to the MNG folks.)

APNG was an effort that originated outside the PNG/MNG group, and it failed to be ratified as an extension to PNG -- mainly because it goes contrary to the mission of PNG, which is to be a standard for storing single images. The rejection of the APNG proposal happened earlier this year, according to the Wikipedia article [wikipedia.org]. Apparently undaunted, the Mozilla folks stuck APNG support into Firefox, but who knows if it'll stay there. The format extensions for APNG are officially unsupported and non-standard, making Firefox the lone holdout on this. Why they couldn't just support MNG is anyone's guess.

Basically, by the time animated GIF became a serious issue, the PNG spec was very close to frozen, and the core spec authors and library developers successfully argued that PNG should be kept solely for image storage. (During PNG development, a THMB chunk was proposed to store a thumbnail version of the full image. This was killed for similar reasons to the APNG extensions.) I tend to agree that stuffing animation features into a file format intended for still images makes the decoder more complicated, and doesn't offer a very optimal solution for animation. The whole notion of animated GIFs never sat well with me either, even though they proved to be popular with HTML jockeys.

Further reading seems to indicate that Mozilla's developers had MNG support, but yanked it in favor of APNG support. I can only guess the motivations, but sounds to me as though they wanted to blaze their own path for political/personal reasons, not necessarily sound technical reasons.

Re:can this be the only solution?

[pionzypher]

Indeed. The HD Photo Device Porting Kit SDK for this has licensing terms which prohibit its use in a copyleft manner.

2. c. Distribution Restrictions. You may not ... modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that the code be disclosed or distributed in source code form; or others have the right to modify it.



So for an open source solution, it would have to be written from the HD Photo Bitstream Specification (also assuming Microsoft does cover HD Photo under the Open Specification Promise)

BSD type licenses may also be compatible.

Most of this info was taken from wikipedia.

Re:Deja GIF.

[ender-]

As most still cameras support only jpeg, you're pretty much stuck. They're the ones that processing speed and memory requirements affect most directly. When you get the images off of the camera, you can store them in any format that you want.

What Microsoft is trying to do is make their HD Photo into the new standard, with the goal being to get the Digital Camera makers to use HD Photo as their new default format on-camera.
There's no proof yet, but I wouldn't be surprised if their hope is to let devices create HD Photo's freely, but control the market of software designed to manipulate them.

Re:Deja GIF.

[mikael]

Earlier Nikon Cameras supported uncompressed TIFF (Coolpix 850), then Nikon realised that this was a "value-added" feature, and only provided JPEG export.

Re:Deja GIF.

[dangitman]

because you can do almost everything that TIFF can do, but with less complexity

Not supporting clipping paths (vectors) seems to fall well short of "almost all" that TIFF can do. It's a pretty major omission. Another question - does PNG handle CMYK images? Color profiles? Those are a pretty big deal, too.

Re:Deja GIF.

[jZnat]

Back in the day, IE 5.0 was the best web browser on Mac OS. Strange, I know, but it used to be like that. Now it's an outdated pile of crap in comparison to Safari, Firefox/Camino, Opera (which is gratis nowadays), etc.

Re:Deja GIF.

[Kalriath]

It didn't used to be. Some time ago, Unisys sent a royalty claim to Compuserve (inventors of GIF) based on the GIF format's usage of their patented LZW algorithm (why it is possible to patent algorithms is a mystery - maths shouldn't be patentable) who then, having no other way to pay the outrageous amount, began claiming royalties for any use of GIF images on the internet. I believe it was as a result of this that PNG was initially created.

These days one is always wary of new image formats (or any new format for that matter) produced by a corporation.

Re:Deja GIF.

[EggyToast]

Most earlier cameras did, but it took a very, very long time to save to the format. As such, very few users ever tried the feature after using it once, and those that did use it realized that a new, 3 or 5mp camera would take inherently better pictures, even saving to jpg. I can't imagine how long it would take to save a 5mp picture to tiff, let alone what it would do to battery life. These little point/click cameras are not known for their speedy chips.

Re:Deja GIF.

[Anonymous Coward]

Not to nitpick, but he did mention "bog-standard" jpeg. You even quoted it.