On Apr 12, 2022, at 9:01 AM, Jerome Raim <[email protected]> wrote: > > OK I think I got it to work. ImageBufAlgo.channels() operation was crashing > when I was preemptively setting the .specmod().tile_width/height to 0 but it > seems to work when I set it afterwards. Thanks for pointing me in the right > direction!
That seems dangerous to me. It's fine to use specmod() to alter "harmless" metadata (just the pure information it carries around, like ImageDescription), but not the few fields that actually describe important things about the layout of the data in the file (in particular, the width, height, tile size, and pixel format). Reading data from disk depends on knowing the image and tile dimensions, so if you alter that field in the ImageBuf and then subsequently read, all sorts of things can go wrong. Changing it after a call to channels() may seem ok, but it's very precarious -- in this instance, the call to channels() may have caused the whole file to be read, and you didn't then subsequently do anything that required additional reads form the file, but there's no guaranteeing that will be the case. A better approach is to safely make a copy of the spec, then you can change your copy any way you want without affecting the internals of the ImageBuf, and use that new copy when opening a new file. -- You know, this makes me wonder if I should have a different strategy for ImageBuf internals, where it would store an inaccessible/immutable copy that describes the file layout, safe from changes by the user, and then I can get rid of the spec/specmod distinction because the copy exposed to the user would be safe to change. That might make this whole thing safer and easier to describe in the future. I need to mull this over. That might make things a lot easier for users of ImageBuf, but it's not something I can do quickly because to do it right actually will change a lot of internals. > > On Tue, Apr 12, 2022 at 11:34 AM Jerome Raim <[email protected] > <mailto:[email protected]>> wrote: > Hi Daniel, > I appreciate the speedy response! I was a little weary of specmod() due to > the warning "It is safe to modify certain metadata, but if you change the > data format or resolution fields, you will get the chaos you deserve". > > I tried using in a few places but it either yields the same tiled image or I > get a "OpenEXR exception: Cannot initialize output part "1". Can't build a > OutputFile from a type-mismatched part." > > ...Getting closer. > > On Tue, Apr 12, 2022 at 11:19 AM Daniel Flehner Heen <[email protected] > <mailto:[email protected]>> wrote: > Hi, Jerome! > > I ran into the same issue a couple of weeks back. > Don't know if this is the best way, but setting the tile width and height to > 0 directly on the ImageSpec worked for me. > So before out.open(): > > # I created/adjusted the specs in advance and referenced them for each > subimage, but this might work (as proof of concept). > comp_buf.specmod().tile_width = 0 > comp_buf.specmod().tile_height = 0 > matte_buf.specmod().tile_width = 0 > matte_buf.specmod().tile_height = 0 > > open1 = out.open(out_filepath, (comp.spec(), matte_buf.spec())) > ... > > > > > On Tue, Apr 12, 2022 at 5:06 PM Jerome Raim <[email protected] > <mailto:[email protected]>> wrote: > Hello, > I am combining multiple channels from various EXRs into a single multi-image > EXR. > > I am using set_write_tiles (0, 0) but the resulting EXR is still being read > as tiled. > > Code looks something like this: > > out = ImageOutput.create(out_filepath) > > open1 = out.open(out_filepath, (comp.spec(), matte_buf.spec())) > comp.set_write_tiles (0, 0) > comp.write(out) > > open2 = out.open(out_filepath, matte_buf.spec(), "AppendSubimage") > matte_buf.set_write_tiles (0, 0) > matte_buf.write(out) > > out.close() > > As always, thank you so much for a great library and knowledgeable help. > > Best, > Jerome > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > > -- > -Daniel > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <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
