Entirely optional.
On September 30, 2014 5:41:49 PM PDT, Nathan Rusch <[email protected]> wrote: >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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
