[Openexr-devel] Re: P.S.

[Thomas Richter]

Gregory J. Ward wrote:
> Hi Thomas,
>
> > > I have a DVD I can send you -- it's 4 GBytes of data, so a bit too
> > > much for my website.
> > I could provide an upload to an sftp server (actually, the JPEG sftp
> > server for test material) if this suits you fine?
>
> I don't particularly want to commit my laptop to 3+ hours of upload.  Do 
> you need this right away, or can it wait a week or so?

It can definitely wait for a week - I'm traveling the next week (JPEG 
meeting in SF) - so I won't be able to perform much experiments. A DVD 
would be fine as well.

> > > Actually, I was referring to Dolby Canada's format -- not very well
> > > advertised, obviously.  It's a backwards-compatible extension to
> > > standard JPEG for HDR content, described in the following CIC 2005 
> > > paper:
> > >
> > >     http://www.anyhere.com/gward/papers/cic05.pdf

Thanks for this work - I had the time to go through it, I like it, and I 
find a lot of good starting points for further research.

> > > The maximum capacity of this extension is about 9 or 10 orders of
> > > magnitude, so I'm not sure it fits with your priorities, but I can
> > > provide you with the libraries if you want to include it in your
> > > evaluations.
> > If possible, sure. However, libraries for which operating system? Since
> > the complete evaluation tool-chain is script-driven and Linux-based, I
> > would prefer simple
> > command line front-ends in the form of binaries for AMD64 systems that
> > compress and expand images from a documented format (openexr would be
> > great ;-) to the HDR-JPEG, and back. It's a 64 bit system because some
> > of the evaluation algorithms require really *a lot* of memory. Libraries
> > or plugins for photoshop wouldn't help, unfortunately. This is a)
> > because we don't have photoshop here, and b) it doesn't work on Linux,
> > either. (-: Alternatively, if this is an option for you, source code
> > would do it if you can release it under a license that would allow
> > testing; if this requires a NDA, let me know.
>
> I don't have the rights to distribute source code with or w/o an NDA at 
> this time, but getting you a Linux binary isn't a big deal.  It might 
> not be 64-bit, but it should still run on an AMD64.  Try grabbing the 
> archive:
>
>     http://www.anyhere.com/gward/pickup/hdrgen_linux.tar.gz
>
> In the bin directory should be an executable called "hdrcvt" that will 
> convert from most any HDR format to and from JPEG-HDR, like so:
>
>     hdrcvt -q qual_setting input.{hdr|exr|tif} converted.jpg
>
> Converting back is just:
>
>     hdrcvt -q 100 converted.jpg comparison.{exr|hdr|tif}
>
> Setting the quality to 100 on the reverse conversion forces IEEE 
> floating point output in the case of TIFF, but doesn't affect EXR.
>
> Also, if you want that test image I mentioned, it's on my website at:
>
>     http://www.anyhere.com/gward/pickup/test1flt.tif

Thanks, I picked the binary, it works fine here - from the scratch, no 
trouble - and tests are running (on the ILM test material right now). 
Thus, I really don't need any sources.

Would you be interested in the results? Is it acceptable to present the 
results in a scientific work and/or in the ISO committee? If so, please 
let me know under which conditions.

Thanks a lot, this is a very helpful discussion.

Thomas