Cool.
Now, although it looks like a pain to have to go scanline by scanline, there
are some advantages to using the get_pixels approach.
* Because get_pixels will do any data conversion from the IB to the type
specified (UINT8), there is no need for the ImageBuf to be uint8. It can be
whatever the native type of the file is, or float for maximum precision for
image processing, or whatever.
* With the get_pixels interface rather than needing the in-memory address of a
pixel buffer, you don't need to force the read of the ImageBuf at all, it can
rely on ImageCache. So the first two lines of your snippet can be replaced by:
ImageBuf Src (filename);
Yeah, no need for an explicit read() call. It will read on demand.
* Because the get_pixels takes an ROI that gives the channel range, the
ImageBuf is no longer constrained to be 3 channels. Any will do, and (at most)
3 channels will be copied out.
* If your QImage is of type Format_RGB32, that's fine, you can use strides:
Dst.get_pixels (ROI(0,Dst.spec().width,i,i+1,0,1,0,3/*nchannels*/),
TypeDesc::UINT8,
newQImage->scanLine(i),
4 /* pixel stride */);
* If you want a full RGBA image, you can use strides and offsets to shuffle the
channel order since QImage wants ARGB:
// Copy alpha
Dst.get_pixels (ROI(0,Dst.spec().width,i,i+1,0,1, 3, 4),
TypeDesc::UINT8,
newQImage->scanLine(i)
4 /* pixel stride */);
// Copy RGB
Dst.get_pixels (ROI(0,Dst.spec().width,i,i+1,0,1, 0, 3),
TypeDesc::UINT8,
(char *)newQImage->scanLine(i) + 1,
4 /* pixel stride */);
> On Feb 5, 2016, at 2:32 AM, Renaud Talon <[email protected]> wrote:
>
> Thanks Larry that worked great. I fixed a few typos and made some minor
> changes and it worked 😊
>
> That said if I add an ImageBufAlgo display transform a black image is
> returned.
> I believe I am following the documentation example properly. Am I missing
> something ?
> The OCIO env variable is set in the windows ENV VAR, pointing to the
> nuke-default config file.
> Ociotools.exe does list all the colorspaces from nuke-default as available
> (“Alexa”, “RedLog”, …).
>
> ImageBuf Src (filename);
> Src.read (0, 0 , true , TypeDesc::UINT8);
> ImageBufAlgo::ociodisplay (Dst /*dest*/, Src/*src*/, "sRGB",
> "AlexaV3LogC");
>
> QImage *newQImage = new QImage (Dst.spec().width, Dst.spec().height,
> QImage::Format_RGB888);
>
> for (int i = 0; i < Dst.spec().height; ++i)
> Dst.get_pixels
> (ROI(0,Dst.spec().width,i,i+1,0,1,0,3/*nchannels*/),
> TypeDesc::UINT8,
> newQImage->scanLine(i)
> );
> return newQImage;
>
> From: Larry Gritz <mailto:[email protected]>
> Sent: Friday, February 5, 2016 12:33 AM
> To: OpenImageIO developers <mailto:[email protected]>
> Subject: Re: [Oiio-dev] ImgBuff to Qimage
>
> Sorry, yes, localpixels().
>
> Looking at this http://doc.qt.io/qt-4.8/qimage.html it seems that for the
> QImage constructor I used as an example, it doesn't COPY the data, but rather
> just points to it, to it's crucial that the ImageBuf survive for the entire
> lifetime of the QImage. I'm sure that's your problem -- by letting the
> ImageBuf get destroyed when it leaves scope but returning the QImage that
> inadvertently points to the ImageBuf's (now invalid) memory, you would expect
> chaos.
>
> I think, then, that instead you want something like:
>
> QImage *newQImage = new QImage (myImageBuf.spec().width,
> myImageBuf.spec().height,
> QImage::Format_RGB888);
> // now your QImage owns its own memory
>
> And, ick, I think you would need to copy things in scanline by scanline?
> Something like
>
> for (int i = 0; i < height; ++i)
> myImageBuf.get_pixels (ROI(0,width,line,line+1,0,1,0,3/*nchannels*/),
> TypeDesc::UINT8,
> newQImage->scanline(i));
>
> Maybe there's something in QImage that I'm missing that would let you do it
> in one step. I'm not sure.
>
>
>
> > On Feb 5, 2016, at 12:16 AM, Renaud <[email protected]> wrote:
> >
> >> // Now create a QImage that copies the pixels from B.
> >> QImage Q ((const unsigned char *)B.localdata(),
> >> B.spec().width, B.spec().height,
> >> QImage::Format_RGB888);
> >>
> >
> > Hi Larry !
> > I apologize for the delayed answer, I didn't get any notification from the
> > mailing list so I assumed nobody answered my message. Thank you very much
> > again for the help. I think an example which goes all the way to a QImage
> > would be great in the doc.
> > When I read the documentation I had a hard time figuring out where the image
> > "raw data" was "stored" when using an ImageBuf reading method.
> > "localdata()" from your example seems to be what I was missing but
> > unfortunately it doesn't seem to exist.
> >
> > I replaced "B.localdata()" with "B.localpixels()", the code compiles but the
> > program crashes when I try to display the resulted QImage (most likely
> > "corrupted" data). Maybe using localpixels() is the issue ?
> >
> > I also tried Pete's methods with no luck.
> >
> >
> > Code:
> >
> > ImageBuf myImageBuf (filename);
> >
> > myImageBuf.read (0 /*subimage*/, 0 , true , TypeDesc::UINT8);
> >
> > QImage *newQImage = new QImage((const unsigned char
> > *)myImageBuf.localpixels(), myImageBuf.spec().width,
> > myImageBuf.spec().height, QImage::Format_RGB888);
> >
> > return newQImage;
> >
> >
> > _______________________________________________
> > 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] <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] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <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
