Folks, as announced earlier, the ISO process for the JPEG extensions have started at the last Shanghai meeting, thus working drafts and documents have to be generated. As I'm the editor of this project, I want to drive this project a little bit different than the previous ISO standards and explicitly want to include feedback from the community. I also want to be as open as the ISO process allows. And it allows to pass out documents up to the FCD state, thus no problem so far. At the usual location, at you now find a document named WD2.pdf which is a *very early* working draft of the standards text (yes, really!) for review and comments - by you. So please feel free to browse and comment (here or personal to my mail at thor at math dot tu dash berlin dot de). To let you know, we had I believe five proposals for HDR coding on the table, one of them the code that was posted here. The code design you find in Clause 5 and Annex E of the document is a composition and compromize of all the proposals we had, including the Stuttgart (this) and the Dolby (largest industry member) proposal. It looks a bit involved, but covers lossy and lossless coding of HDR images, thus basically the features of the code we had. The document is still in bad shape (I know - this is an early WD!) specifically references are missing, and the document is not yet entirely consistent. Annex B - the codestream design - currently only describes the Stuttgart codestream but fails to cover features required by other proposals, and some marker parameters are missing. Alpha components are missing and will probably be added later. Typos should be everywhere. Sorry for that. It's a first draft, and only that. Still, some interesting highlights: There are currently three HDR coding methods covered by the draft: A an "additive residual" process from here with a pretty good performance that includes lossless, a "multiplicative residual" process (essentially JPEG-HDR), and a "refinement" process for >8bpp images using mostly the layout of the old DCT process with "hidden additional scans" which is very lightweight. Note that the current implementation on github only covers additive residual and refinement, not yet the additional multiplicative process, so document and software are not yet in sync. Feedback welcome!