The old Photoshop plugin reads and writes a single scanline at a time, so that might also be useful to look at.
The source is available here: OpenEXR_Photoshop-1.2.1.Source.tar.gz And the relevant code is in EXRFormatPlugin.cpp. See EXRFormatPlugin::DoReadContinue and EXRFormatPlugin::DoWriteStart. I don't know if the plugin will actually compile anymore, unfortunately. I stopped maintaining it when Photoshop got native EXR support. - Paul On Dec 14, 2009, at 10:01 AM, Jonathan Litt wrote: > It's almost exactly like the general interface examples in the distribution > (generalInterfaceExamples.cpp -> writeGZ1 & writeGZ2), but you would put a > loop around that whole chunk of code. Your buffers should each be the size of > one scanline, and you need to recreate the framebuffer object for each > scanline because you're going to pass the same pixel buffers each time but > give them a different offset into the file. The key thing to get right is the > second argument to the Slice() object that you pass to each call of > framebuffer.insert(), because that is where the offset will go. That is how > writePixels knows where to start. Perhaps the closest example of this is in > the function "readGZ1", although that is for reading a datawindow and not > writing scanlines. > > I agree it would be nice if there were an example of this in the distribution. > > -Jonathan > > > From: Koraxen <kora...@gmail.com> > To: Florian Kainz <ka...@ilm.com> > Cc: openexr-devel@nongnu.org > Sent: Thu, December 10, 2009 10:34:44 AM > Subject: Re: [Openexr-devel] Writing single EXR file with very many channels? > > More precisely: > > generateScanline(1) > write scanline1 of channel1 > write scanline1 of channel2 > write scanline1 of channel3 > write scanline1 of channel4 > free() mem > > generateScanline(2) > write scanline2 of channel1 > write scanline2 of channel2 > write scanline2 of channel3 > write scanline2 of channel4 > free() mem > > .. and so forth. > > The writePixels( int height ) function will write a given number of > scanlines, but not a specific scanline? > > - K. > > On Thu, Dec 10, 2009 at 10:26 AM, Koraxen <kora...@gmail.com> wrote: > Thanks for the reply Florian! > > Do you know of any example that shows scanlines being written 1 at a time? > > As in: > write scanline1 of channel1 > write scanline1 of channel2 > write scanline1 of channel3 > write scanline1 of channel4 > free() mem > > write scanline2 of channel1 > write scanline2 of channel2 > write scanline2 of channel3 > write scanline2 of channel4 > free() mem > > ...and so forth. > > I can find one for tiled files in the ReadingAndWritingImageFiles pdf, but > not for scanline. > > Thanks again, > - K. > > > > On Wed, Dec 9, 2009 at 11:20 AM, Florian Kainz <ka...@ilm.com> wrote: > Hi Kora, > > the IlmImf library does not allow writing the file channel by channel; > all channels must be written at the same time. The OpenEXR file layout > would channel-by-channel writing very inefficient. > However, you can write a few scanlines at a time or a few tiles at a > time; your frame buffer only has to be large enough to hold the portion > of the image you are writing. (In the extreme, a single scan line or > a single tile is enough.) > > Florian > > > Koraxen wrote: > Hey guys, > > I have a question regarding how to deal memory consumption and multi-layered > EXR files. > > I need to write an EXR file that contains 10 different versions of a same > high res (5120 x 2880) image. This translates into an EXR file that contains > 10 layers x 4 channels = 40 channels. > > What I am doing is: > 1. Instantiate an exr framebuffer > 2. Allocate memory for 40 high-res channels, and insert() them all into > framebuffer > 3. Instantiate OutputFile object, and set the framebuffer to it > 4. Write the OutputFile > > The problem is that host system obviously runs out of memory during step #2. > > What's needed here is the ability to: > - Insert a channel to framebuffer > - Write it to disk > - Free memory > - Repeat 40 times > - End up with a *single* EXR file containing 40 channels > > How can this be done? > > Thanks a ton! > - Kora > > > ------------------------------------------------------------------------ > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
