Hi David, You can find the relevant information you are looking for in the following documentation : http://openexr.com/TechnicalIntroduction.pdf.
Specifically, on page 7 is a listing of the data types currently supported for pixel data: uint32, half, float. The RGBA interface is really there as a convenience when dealing with the common case of 4 channels, half data. For all other cases i refer you to the generic API. Typical, but by no means exclusive, usage patterns use the fixed point representations for labelling/identifying specific objects in scenes. -Piotr On 6 December 2016 at 07:11, David Kuťák <davedes...@email.cz> wrote: > Hello, > > > > I think I got the point. > > However, one more question just come to my mind – OpenEXR should support > not just 16bit half float, but also 32 bit float and 32bit unsigned int > (referred to as FLOAT / UINT in documentation). These other data types are > not widely mentioned in documentation and Rgba interface seems to support > only half float (as it’s probably most logical choice). > > But is it possible to save pixel data directly in UINT / FLOAT (and thus > not to use half float) using OpenEXR? This way there should be no problem > with losing information when reading 16 bit unsigned int data and > converting them to UINT / FLOAT (although the compression ratio might be > unsatisfying). Or are those additional formats like UINT / FLOAT used just > for „metadata“ (like depth, etc.)? > > > > Thank you. > > > > David > > > > > > *From:* Openexr-devel [mailto:openexr-devel-bounces+davedesign= > email...@nongnu.org] *On Behalf Of *Larry Gritz > *Sent:* Tuesday, December 6, 2016 6:44 AM > *To:* openexr-devel@nongnu.org > *Subject:* Re: [Openexr-devel] OpenEXR - lossless compression problems > (Peter Hillman) > > > > If people are thinking of the problem as inherently having 16 bit unsigned > integer values, then converting to half float for output to exr, and > finally converting back to canonical uint16, perhaps they are barking up > the wrong tree by considering OpenEXR at all. > > > > The whole idea behind OpenEXR is for extended range -- values that may be > negative, or very small, or greater than 1. The kinds of things you would > usually use a 'float' for if they were in memory. The use of half precision > is itself a form of lossy compression, halving the size by accepting a loss > of precision (but an acceptable and roughly perceptually uniform loss, > since vision sensitivity is essentially logarithmic). > > > > OpenEXR is meant to store float data, not integer data. You wouldn't > expect a uint16 image to have very good accuracy or compression by going > through a 'half' conversion. It's a mismatch of method and task. > > > > -- lg > > > > > > On Dec 5, 2016, at 5:41 PM, Conrad Gaunt <helloconradga...@googlemail.com> > wrote: > > > > hi. > > > > ive been testing image formats for a few months, and in depth. new to > openexr. > > > > i'm currently starting the optimizing of my lossless 16bit+ compression > system > > > > some observations. > > > > remember, if you're source material is 16bit integer, the half float > conversion is very lossy, although it has more conservative properties when > manipulated down the post pipe in some regards, > > > > one thing all formats suffer from .. they are always going out of date . > most were invented in the 90s > > > > my classical Huffman coder beats j2k and png on 48bit photographic > material, and PIZ > > > > PNG uses Huffman coding .. and can compress 16bit values .. but the > compression system in png is only 8bit. same with TIF. > > > > all these are by products of formats beings developed back when computers > had 640kb of ram.. > > > > when you convert 16bit integer to 16bit half float, and normalise between > 0..1 , there is half as much data recorded as when you normalise between -1 > ..1 .. and you're not wasting the sign bit ! > > > > I don't know what openexr convention says. anyway, normalising between 0..1 > makes my compressor produce files that are significantly smaller than the > compressed integer source. > > > > I'm not sure what the correct normalization procedure for openexr is to be > honest > > > > try normalising all possible 65536 integer values into half floats. then > convert them back to integer, and print a list of the original inputs and > outputs (into a text file) . quite interesting > > > > k.r > > > > > > > > > > > > > > > > > > On Sun, Dec 4, 2016 at 5:43 AM, <openexr-devel-requ...@nongnu.org> wrote: > > Send Openexr-devel mailing list submissions to > openexr-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.nongnu.org/mailman/listinfo/openexr-devel > or, via email, send a message with subject or body 'help' to > openexr-devel-requ...@nongnu.org > > You can reach the person managing the list at > openexr-devel-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openexr-devel digest..." > > Today's Topics: > > 1. OpenEXR - lossless compression problems (David Ku??k) > 2. Re: OpenEXR - lossless compression problems (Peter Hillman) > > > ---------- Forwarded message ---------- > From: "David Kuťák" <davedes...@email.cz> > To: <openexr-devel@nongnu.org> > Cc: > Date: Sat, 3 Dec 2016 20:40:10 +0100 > Subject: [Openexr-devel] OpenEXR - lossless compression problems > > Hello, > > > > I am currently working on my bachelor thesis in which I am comparing image > compression algorithms (available in different image file formats). > > For my work, only file formats supporting lossless compression and 16 bit > depth are appropriate. > > During my exploration of possible formats, I found an OpenEXR and decided > to include it in my tests. > > However, I am not able to make it work properly. > > > > The input image and output image (created during compression) are not same > – the colors seem to be different (shifted). > > I thought it might be gamma problem but even after gamma correction, I am > not able to retrieve correct output image. > > Although visually the image seems to be very close to the input one (after > gamma correction), there is still a minor difference which is unacceptable. > > > > So I’d like to ask you for a help – what I am doing is written below (some > undefined wars like imageWidth, etc. are correct for sure). > > > > 1) I create my output file > > * RgbaOutputFile outputFile(argv[3], imageWidth, imageHeight, > WRITE_RGB, 1.0f,* > > * V2f(0, 0), 1.0f, > INCREASING_Y, compressionType, globalThreadCount());* > > > > 2) Then I create a pixelData vector > > *std::vector<Rgba> pixelData(imageWidth * imageHeight);* > > > > 3) I fill this vector with data retrieved from my test images (these data > are pixel values (i.e. numbers from interval <0,255/65535> – depending on > bit depth – which I normalize to inverval <0,1.0> and pass to half ctor and > then as an Rgba struct to appropriate pos in pixelData vector). > > > > 4) Then I set framebuffer and write pixels to file (shown in code below). > I think that my problem occurs somewhere in those two methods (EXR must be > doing some operations with pixel data). > > *outputFile.setFrameBuffer(pixelData.data(), 1, imageWidth);* > > *outputFile.writePixels(imageHeight); * > > > > To sum up my problem – is this the correct way to pass image data to > OpenEXR and retrieve the same image (but in EXR format)? I really don’t > know why the color problem appears. > > > > Another question I’d like to ask is that I got the idea that the > compression is done in writePixels method. Is that’s right? If it’s true, > is there any possibility to compress image in memory without writing it to > file? > > > > Thank you for your help! > > > > David > > > > ---------- Forwarded message ---------- > From: Peter Hillman <pet...@wetafx.co.nz> > To: "David Kuťák" <davedes...@email.cz>, "openexr-devel@nongnu.org" < > openexr-devel@nongnu.org> > Cc: > Date: Sun, 4 Dec 2016 00:33:39 +0000 > Subject: Re: [Openexr-devel] OpenEXR - lossless compression problems > > Hi David, > > > > Your code looks valid, and as the image looks quite close to correct it's > unlikely there's a bug in your code. > > Perhaps the difference you are seeing is due to the fact that OpenEXR's 16 > bit half is a floating point number. Converting a 16 bit unsigned integer > *n* to a half float using *n/65535* will cause rounding error. > > > > From a quick test it seems you get 7169 unique bit patterns in a half > float with that approach, which means you are losing information. The other > patterns used by 16 bit half mainly store negative numbers and numbers > above 1, which you aren't using here. These come about because OpenEXR is > intended for storing HDR images. With a 16 bit unsigned int sRGB PNG, the > darkest grey is 20 stops darker than the maximum white; with a 16 bit half > linear OpenEXR that's closer to 40 stops. > > > > The 8 bit version of *n*/255 will also cause rounding error, but in that > case each input value is represented uniquely and you can fix the error by > rounding to the nearest integer when you denormalize. > > > > The openexr.com website has some sample HDR images you could use to > experiment with OpenEXR compression schemes, but it is hard to make a > rigorous comparison of PNG (for example) to OpenEXR because they set out to > achieve different things working with different kinds of image data. > > > > Your second question: > > > > > I got the idea that the compression is done in writePixels method. Is > that’s right? If it’s true, is there any possibility to compress image in > memory without writing it to file? > > > > Yes, this is correct-writePixels is the only access to the compression > schemes from the API. It is possible to generate an OpenEXR file entirely > in memory, but is non-trivial: you have to subclass OStream and override > the methods to write data into your memory array rather than to file. If > you need to read it back, you need to make an IStream too. > > You then pass an instance of your new OStream to the OutputFile > constructor when you write it. The OpenEXR library will call your methods > when it wants to write data. You might start here: > > <https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImfExamples/lowLevelIoExamples.cpp> > > https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImfExamples/ > lowLevelIoExamples.cpp > > > > Actually, if you just want to know how big the file would be with a given > scheme, you could be sneaky and not store the image at all: just subclass > OStream with a class that has its own "file pointer" which is read by > readp(), set by seekp() and incremented by write(). You'll also need to > track the maximum value the "file pointer" ever has, which would be the > file size you need (not the final value of "file pointer") Doing this won't > let you analyse errors in lossy schemes, but would let you measure the > lossless schemes' efficiency. > > > > > > > ------------------------------ > > *From:* Openexr-devel <openexr-devel-bounces+peterh= > wetafx.co...@nongnu.org> on behalf of David Kuťák <davedes...@email.cz> > *Sent:* Sunday, 4 December 2016 8:40 a.m. > *To:* openexr-devel@nongnu.org > *Subject:* [Openexr-devel] OpenEXR - lossless compression problems > > > > Hello, > > > > I am currently working on my bachelor thesis in which I am comparing image > compression algorithms (available in different image file formats). > > For my work, only file formats supporting lossless compression and 16 bit > depth are appropriate. > > During my exploration of possible formats, I found an OpenEXR and decided > to include it in my tests. > > However, I am not able to make it work properly. > > > > The input image and output image (created during compression) are not same > – the colors seem to be different (shifted). > > I thought it might be gamma problem but even after gamma correction, I am > not able to retrieve correct output image. > > Although visually the image seems to be very close to the input one (after > gamma correction), there is still a minor difference which is unacceptable. > > > > So I’d like to ask you for a help – what I am doing is written below (some > undefined wars like imageWidth, etc. are correct for sure). > > > > 1) I create my output file > > * RgbaOutputFile outputFile(argv[3], imageWidth, imageHeight, > WRITE_RGB, 1.0f,* > > * V2f(0, 0), 1.0f, > INCREASING_Y, compressionType, globalThreadCount());* > > > > 2) Then I create a pixelData vector > > *std::vector<Rgba> pixelData(imageWidth * imageHeight);* > > > > 3) I fill this vector with data retrieved from my test images (these data > are pixel values (i.e. numbers from interval <0,255/65535> – depending on > bit depth – which I normalize to inverval <0,1.0> and pass to half ctor and > then as an Rgba struct to appropriate pos in pixelData vector). > > > > 4) Then I set framebuffer and write pixels to file (shown in code below). > I think that my problem occurs somewhere in those two methods (EXR must be > doing some operations with pixel data). > > *outputFile.setFrameBuffer(pixelData.data(), 1, imageWidth);* > > *outputFile.writePixels(imageHeight); * > > > > To sum up my problem – is this the correct way to pass image data to > OpenEXR and retrieve the same image (but in EXR format)? I really don’t > know why the color problem appears. > > > > Another question I’d like to ask is that I got the idea that the > compression is done in writePixels method. Is that’s right? If it’s true, > is there any possibility to compress image in memory without writing it to > file? > > > > Thank you for your help! > > > > David > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > > -- > > conrad gaunt > > www.cheapredhire.com > tel.07835915253 > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > -- > Larry Gritz > l...@larrygritz.com > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > >
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel