Discussions

@Dovella:

I always wondered would MS do something like this. Make a new Zune based off WP7 which can run all the same apps.

I'd consider it *very* unlikely at this point given how much the MP3 player market has been in decline. A Windows Phone is more or less a Zune with a phone in it in so many ways anyways. They would be far better off just bringing any missing Zune features to Windows Phone 8.

@wastingtimewithforums:

I very much doubt anyone has been "furiously ripping out legacy code". The start menu code would have been planned to have been removed from the very begining I'm sure. It was only present in builds upto not to ease the transition of various aspects of the OS with dependancies on it. It is most likely there primarily so there was a robust backup to use when developers were working though issues with the new metro start screen. But now that we're into the RC it's time to cut out anything that doesn't have any use. Microsoft were never going to keep lecacy start menu code and maintain it just for the purpose of power users who want to hack it back into life.

It's most likely the same situation where when VS2010 was developed it worked in GDI mode and WPF mode up until near the very end until the finally removed all the GDI code that didn't have any purpose.

The idea that Microsoft have been "furiously ripping out legacy code" that was never going to be usable my anybody besides being hacked back into the OS is laughable. I gather though there's nothing stopping anyone from writing an alternative classic style start menu from scratch however.

"The Windows 8 developer preview launched late last year and has prompted more than 100,000 changes." They were refering to the developer preview promting 100,000 in the consumer preview, not the release preview.

@CSMR2:

Even if the web is the last place to adopt it I would still like to see an effort sooner than later simply to fill the gap in functionality left by jpeg/png/gif that jpeg xr nicely fills.

From what I understand, there's relatively low interest to photographers in jpeg-xr at the moment. Camera memory has become so cheap in recent years it's now practical to shoot everything in RAW. Photoshop CS6 does not support JPEG XR. Though I do think Jpeg XR would be useful in this area, I don't think it's something camera manufacturers are rushing to adopt.

@mloskot:

"Is there any benchmark, audit available?":

Some basic ones here:

"1. Performace. From my initial tests, it looks like the reference JPEG-XR implementation is about 10x slower to decode than libjpeg.
2. Security. I don't know that the reference implementation has been hardened against malicious inputs and from my quick look it appears that it has not." -Jeff Muizelaar, Mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=500500#c18

As opposed to the FCD ballot Jpeg XR reference software recommended in that linked thread I would recommend the final published version found here: http://www.itu.int/rec/T-REC-T.835

I don't beleive I implied that the libjpeg based Jpeg XR codec discussed was being maintained.

@Blue Ink:

I'd have to disagree with you on codecs being shipped with browsers. If there's a jpeg decoder for example that's faster, more memory effiecient and at least as stable and secure as the WIC jpeg decoder, then is there any reason at all why the former should not be used instead? I would also expect this exact scenario is the case as although the WIC codecs are not bad, I don't beleive they stand up well against the best open source image codec libraries. Also, although Windows does have WIC, I'm not so sure if mac osx or linux have similar libraries made easily available to third party applications. Even Windows XP doesn't have WIC, one reason why IE9 is not available of XP. Now even if osx, xp and most linux distros did have WIC counterparts, that would mean if a browser chose to use those different libraries on different platforms they'd all have to be individually tested for bugs, and of course if a bug is found internal to the imaging library it can't be fixed and a case specific work around must be worked out instead. It might be easier then just to use a performant open source library accross all platforms which only needs to be tested once. Now if firefox were to only use WIC on windows and nowhere else you then have fragmentation issues. A page that uses jpeg-xr on Windows will not render correctly on mac osx or linux. Browsers like firefox and chrome try to ensure they render identically across all platforms, web development is hard enough having to test a page in many browsers without having to test those same browsers across multiple os's aswell. This is the very reason I gather that firefox declined to support H264 on windows via the native OS codecs.

I think in the web today there's a demand for an image format that supports both lossy compression and alpha transparency and one that supports high colour depths. These have pretty obvious benefits in regards to graphically intensive web sites/web apps and games. This is the exact reason that adobe flash player now supports Jpeg-XR. I think there's a big opportunity for Jpeg-XR to be the format to fill this need for web developers. Web-P is being developed by google to support these features too, but at the moment that's a moving standard and is by no means complete. Jpeg-XR has an enormous benefit then by being an established ISO standard for 3 years now I think. So far though however, the only browser that supports Jpeg-XR is IE9. Why is this the case exactly? Mozilla seem pretty interested in the standard but among other things they are mostly put off by the huge amount of work it would take them to write a performant, stable and secure Jpeg-XR decoder from scratch.

"I'm interested, but there's a lot of work that would need to be done.[...] If Microsoft is looking to help, I think releasing a high quality encoder/decoder under the same license as libjpeg would go along ways to improving adoption." -Jeff Muizelaar, Mozilla

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ea39f74581072ca3/43fae1cc25b5f1c3

Microsoft do have an open source reference codec, but it's not performant or secured. Why then should Microsoft not take the lead (supposing they are interested) and release a performant, stable and secure Jpeg-XR codec of their own with a liberal (GPL Compatible) open source licence? If Microsoft is interested in getting the format more broadly adopted, especially in the web, then what better way then to do this? No new code would even need to be written, they could just open source the codec included with WIC.

My thoughts are that if this format became broadly supported in web browsers it could make a significant improvement to the kinds of things possible in web development. Most people seem to agree the format is the right one for the job, and it seems like it could become broadly adopted if Microsoft made just that much easier for people to implement.

I'm not sure how interested Microsoft is in promoting Jpeg-XR however. Seems like all the momentum behind it died the day they made the licencing free permanently and killed any means of making any real money off of it. Perhaps I'm wrong though and there's some people left in there who want to see this format adopted in more places. I'd love to hear someone from microsoft's two cents on this and whether or not this is a practical possibility.

The Samsung Focus S is essentially the Samsung Galaxy S II running mango.

Actually, using the toolbar, you need to drag your mouse first, then click. were as you could just memorise every command as a keyboard shortcut and save more time.

I see the whole Toolbar vs. Ribbon as a classic design problem of "Less is Less". Yes the tool bar takes less clicks to find things, but finding a function in a wild nest of menus and context menus can be frustrating to anyone who hasn't spent a lot of time memorising the where everything is. The only reason the Ribbon was developed was in response to the toolbar system in office becoming overrun with to many items. The original design for the toolbar specified that toolbars shouldn't contain more than 7 items for usability. Although the Ribbon is more taxing on people who've learned to use the toolbar very efficiently, I don't think the toolbar is appropriate today, or going forward, as consumers expect easier and more self explanatory user interfaces.

Interesting that there's new JpegXR APIs in Windows 8. Looks like they may be putting some real effort into supporting it (I haven't seen any from Microsoft for quite some time). Windows 7/Vista does of course support jpegXR as HDphoto, but it doesn't support the .jxr file extension recommended in the ISO spec. A small thing, but I imagine this would really put off camera makers and others supporting the format as if a camera produces a .jxr file, no computer will know what to do with it without installing extra software.

A little less important to most people.. but I found it a bit annoying that the build in jpeg-xr decoder in windows 7/vista doesn't decode all the images in the jpeg-xr test suite correctly. The ones it doesn't decode right are ones that use obscure colour formats, so it's not something most people would ever notice. But it does annoy me that if anyone else coded a decoder like this they would be liable to be sued for patent infringement by Microsoft as they would not be covered under Microsoft's "community promise" due to not completely implementing the jpeg-xr spec. Seems poor that Microsoft can't implement their own standard correctly on this one. Another issue with the decoder is, with certain images, it creates excessively large file sizes, with poor image quality. Comparatively, significantly worse compression than a jpeg. A bug like that completely defeats the point of most people wanting to compress their images like that.

Right now IE9 supports jpeg-xr, but so far they have not followed through and supported it in IE9 on windows phone. Given they got jpeg-xr support for free by using WIC on desktop for image decoding I wonder if they'll bother with the effort.

Interesting too to see jpeg-XR support in the next flash version. I'd agree it will probably sneak its way into CS6 too. I know adobe were actively working on native Jpeg-xr support in Photoshop for a while after the plugin by Microsoft was released, but shelved it after implementing jpeg2000 support and realising very few people used it yet still having to maintain the code for people who did. They were more cautious about support jpeg-xr allegedly after that.

Another cool project is a summer of code project to develop a jpegXR version of jibjpeg for use with firefox. Would be cool if we saw this grow into something usable in the near future. There seems to be a big lack of open source jpeg-xr decoders out there.