One more thing... should I add an issue on GitHub for tracking/posterity? -Nathan
On Tue, Sep 30, 2014 at 4:32 PM, Nathan Rusch <[email protected]> wrote: > Yup, without that things seem to be working as expected. > > Thanks, > > -Nathan > > On Tue, Sep 30, 2014 at 3:58 PM, Larry Gritz <[email protected]> wrote: > >> Definitely sounds like a bug. Thanks for the repro case, knowing that >> it's related to checknan will help narrow it down. In the mean time, I >> assume that by disabling checknan, you can get unstuck and make some >> forward progress? >> >> -- lg >> >> >> On Sep 30, 2014, at 3:53 PM, Nathan Rusch <[email protected]> wrote: >> >> Hey Larry, >> >> As requested, I stripped it down to a minimal set of operations, and >> after playing with a couple of things, it appears to be a side-effect of >> turning on "maketx:checknan". In my case, the source buffer is always of >> type FLOAT, so the "checknan" block in make_texture will never be skipped >> if that attribute is set. >> >> Here's the code I used to reproduce it: >> >> >> #include <iostream> >> >> #include "OpenImageIO/imagebuf.h" >> #include "OpenImageIO/imagebufalgo.h" >> >> >> #define WIDTH 640 >> #define HEIGHT 480 >> #define CHANNELS 3 >> >> >> OIIO_NAMESPACE_USING >> >> int main (int argc, char* argv[]) { >> if (argc < 2) { >> std::cout << "ERROR: An output file path is required" << >> std::endl; >> return 1; >> } >> >> const char* filename = argv[1]; >> >> ImageSpec srcSpec(WIDTH, HEIGHT, CHANNELS, TypeDesc::FLOAT); >> ImageBuf srcBuffer(srcSpec); >> >> float zero[CHANNELS]; >> for (int i = 0; i < CHANNELS; i++) >> zero[i] = 0.0f; >> >> for (int y = 0; y < HEIGHT; y++) >> for (int x = 0; x < WIDTH; x++) >> srcBuffer.setpixel(x, y, &zero[0]); >> >> ImageSpec destSpec(WIDTH, HEIGHT, CHANNELS, TypeDesc::FLOAT); >> >> destSpec.attribute("maketx:filtername", "box"); >> >> // This is bad news >> destSpec.attribute("maketx:checknan", 1); >> >> destSpec.attribute("maketx:verbose", 1); >> destSpec.attribute("maketx:stats", 1); >> destSpec.attribute("maketx:oiio_options", 1); >> >> OIIO::attribute("threads", 4); >> >> std::cout << "Calling make_texture" << std::endl; >> if (!ImageBufAlgo::make_texture(ImageBufAlgo::MakeTxTexture, >> srcBuffer, >> filename, destSpec, &std::cout)) { >> std::cout << "ImageBufAlgo::make_texture failed to write file " >> << filename << std::endl; >> return 1; >> } >> return 0; >> } >> >> >> >> Let me know if I can provide any more info. >> >> -Nathan >> >> On Tue, Sep 30, 2014 at 2:54 PM, Larry Gritz <[email protected]> wrote: >> >>> Smells like maybe some kind of a bug, but I'll need to look into it. >>> >>> Can you possibly reduce it down to the minimal C++ program that will >>> reproduce the crash? >>> >>> >>> >>> On Sep 30, 2014, at 2:37 PM, Nathan Rusch <[email protected]> wrote: >>> >>> Hello all, >>> >>> I'm running into an error when using ImageBufAlgo::make_texture to >>> create a mipmapped .tx file from an ImageBuf, using OIIO 1.4.12.. I've >>> tried to do my due diligence in looking for previous questions about this, >>> as well as trying to track it down myself, but so far I've had no luck. I >>> haven't gone as far as patching and playing around with the OIIO code yet >>> though. >>> >>> Here's a rough outline of what I'm doing: >>> >>> ImageSpec srcSpec(w, h, chanCount, TypeDesc::FLOAT); >>> ImageBuf srcBuffer(srcSpec); >>> // ... >>> // Fill in srcBuffer, currently using setpixel, >>> // but eventually (hopefully) using an iterator >>> // ... >>> ImageSpec destSpec(w, h, chanCount, TypeDesc::FLOAT); >>> // ...or some other BASETYPE >>> // ... >>> // Set various "maketx:" attributes >>> ImageBufAlgo::make_texture(ImageBufAlgo::MakeTxTexture, srcBuffer, >>> filename, destSpec, &std::cout); >>> >>> >>> When this runs, I get a failed assertion '0 && "ImageBuf wrapping client >>> buffer not yet supported"'. I've looked through various source files, and >>> while this is originating in the ImageBuf copy constructor, it looks like >>> the assertion should only be hit if the original ImageBuf was constructed >>> with an external buffer pointer. I'm obviously not doing this, and I have >>> confirmed that my buffer's storage mode is set to LOCALBUFFER, so I'm not >>> sure what else could be going on. >>> >>> So my question to you good people is, am I just doing and/or overlooking >>> something really dumb here? Or does this look like a bug in make_texture? >>> >>> Thanks for any help or ideas. >>> >>> >>> -Nathan >>> _______________________________________________ >>> 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
