Yeah exactly, each file has the full data window, but only some part we care about and there may be non-black pixel values outside of that!
They're named like image.t###.####.exr Tiles are the same sizes but won't always be square. The users inputs the amount of tiles they want in x and y. 10x10 for examples. On Mon, Jul 29, 2019 at 8:42 PM Larry Gritz <[email protected]> wrote: > So the data windows are not restricted to their tiled areas? Each file has > a full data window, but only part you care about, and there may be > non-black pixel values outside of that? > > Are the files/tiles at least all the same size (if offset)? And are they > named something sensible? > > > On Jul 29, 2019, at 5:39 PM, Carl Bérubé <[email protected]> wrote: > > That's correct! Sorry if this wasn't clear! > > Each tile has the full data window, so in Nuke we currently just merge > them on top of each other! Unfortunately we can't do that anymore as some > garbage pixels just appeared outside the tile's rectangle and they get > added to the final image! > > Does that make sense? > > On Mon, Jul 29, 2019 at 8:35 PM Larry Gritz <[email protected]> wrote: > >> I'm not quite sure what you're trying to do. Is this the gist...? >> >> You broke up a large frame into several overlapping pieces and you're >> trying to recombine again, is that it? Do they all have their data windows >> set correctly to their section, so that among them all they are all exactly >> abutting and non-overlapping? And do they all have the same display window >> that indicates the size of the full frame you are trying to assemble? >> >> >> >> On Jul 29, 2019, at 5:13 PM, Carl Bérubé <[email protected]> wrote: >> >> Hey! >> >> Sorry about the confusing title! >> >> I'm dealing with a small issue and I'm curious to know if either oiiotool >> or the Python binding of OpenImageIO can help me do what I want... >> >> I've got EXR images with lots of channels (~50 -- cryptomatte and all) >> rendered in regions, but the buffer is the full resolution. >> >> So you can split it in tiles, and they can be uneven -- 5 rows and 7 >> columns for example. >> >> I didn't think it was possible to do it through oiiotool, but I've >> managed to do with I wanted with the Python Binding so far, but it hasn't >> been as efficient as I thought it would be... >> >> My pseudo code would go as follow : >> >> final_image_buffer = OpenImageIO.ImageBuffer(full_frame_spec) >> for tile_file_path, rect in tile_file_paths: >> tile_image_buffer = OpenImageIO.ImageBuf(tile_file_path) >> roi_cropped = OpenImageIO.ROI(*rect) # it's like (xbegin, xend, ybeing, >> yend) >> OpenImageIO.ImageBufAlgo.copy(final_image_buffer, tile_image_buffer, >> roi=roi_cropped) >> >> final_image_buffer.write(output_path) >> >> Now that works pretty well, like I said, but it is very slow. Eventually >> that might not be that big of a deal when it goes on better farm machines >> than my development toaster oven, but is there anything obvious that I'm >> missing? Would oiiotool be able to deal with this more efficiently? >> >> Thanks! >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > [email protected] > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
