Slashdot Mirror
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?"
I can't for my life figure out how Microsoft or why Microsoft introduces evil into this format and standard, other than Microsoft's track record. Unfortunately, that is sufficient... I'd vote no on any of their proposals.
The future and potential for photography is huge. There are:
Microsoft makes their promise to make this free. Somehow, that just rings a tad hollow. Must we continue to be the Charlie Brown to Microsoft's Lucy?
If the specification is as free as ASCII, to use one example, then there is nothing wrong in adopting that as a standard.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
"Nothing for you to see here; please move along"
Wow! The image compression used by Microsoft's HD Photo format is so good that it can reduce any image down to 0 bits!
If they are truly interested in making the patents "available", they would simply surrender the patents into the public domain. Since they have not done this, assume they will not always make the patents "available" to everyone or will have special cases where it is not available (for example, to extend the specification, or to set up a company that certifies HD Photo implementations, or "no government use without paying us", etc).
If MS gives away all rights to the format spec and any algorithms required to use it, fine. JPEG can declare particular implementations in compliance or not. Otherwise, no way.
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 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)
...You may not (i) duplicate any part of these Materials
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.
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.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Gentoo Sucks
Taking a quick glance at Microsoft's HDPhoto standard it looks like it is not really suitable for capturing raw image data for cameras.
In a digital camera, a pixel is red, green, blue and sometimes additional colors laid out in a pattern that can differ from camera to camera. A pixel is not RGB (unless it's a Fovon sensor), so standard lossless formats like PNG or TIFF won't work. HDPhoto supports N color channels and more than 8 bits per color, but I do not see support for the raw CCD data, which is usually not RGB, but R, G, or B (sometimes with additional colors).
I like to preserve my pictures in RAW format since as time goes by, the algorithms to convert the image to a RGB image suitable for displaying keep improving. Also, when editing my photos, some of the processing is done on the raw data before converting it to RGB. Raw data helps for things like noise filtering, for example, since the noise filtering software can be aware of the camera's CCD properties (Noise Ninja, for example, has profiles for my camera at different ISO settings).
The only problem with current raw photos is that each manufacturer seems to have their own format which is incompatible with other manufacturers, or even incompatible between different cameras. It would be nice if they could standardize on something like OpenRAW.
Now, as much as I dislike Microsoft, I think this could be good for regular photos since the compression is about as good as Jpeg2000 (assuming Microsoft isn't spreading FUD) but with a much faster encoding/decoding speed. This could also be a good format for most people taking pictures (who are happy with JPEG).
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Wow! The image compression used by Microsoft's HD Photo format is so good that it can reduce any image down to 0 bits!
It's decompression that's always been the sticky part.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Well, the inability to use it in GPL v2/3 code would be the evil part that the OP was referring to. There you go.
The cesspool just got a check and balance.
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.
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).
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. 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.