Yeah, what Larry said. I would NOT resize the destination image and just fail. For point-based image ops, the images should be sized by the caller. For area ops, this gets much harder. As always, hard failures are easier to debug than soft errors.
I would NOT expose a thread argument directly. That is already too much of the implementation exposed. There might be tons of ways to improve performance via threads. I don't like the idea of somehow baking the implementation into the public API. What about GPUs? SSE or other vector ops? Do those count as threads? It is unclear, so I'd leave it out of the top-level entry point and try to find some alternative way of controlling those implementation details. I would expose a ROI in the public call. If this were my code, I'd require the images to be the same size and NOT specify an ROI, but instead, the typical solution is to define an ImageReference class, which derives from the base Image class, defining a ROI, but only *referencing* the image data. But, I'm not familiar enough with the OIIO image classes to know how this would affect things. It generally means a more fundamental change to the way everything works that probably won't work if it isn't already supported. So, if that's not possible here, I'd pass an ROI. On Fri, Jun 8, 2012 at 2:19 PM, Stefan Stavrev <[email protected]>wrote: > 1. class ROI looks really nice. > > 2. Do we need a separate function "parallel_image" for each image > processing operation since most of them will have different signatures, > different number of input images, etc., and threads in parallel_image are > managed in a way that depends on the signature of the function being called? > > We can get away with something much better I think, could we have a case > statement on lines 455 and 462 in src/maketx/maketx.cpp, to handle > functions with different signatures? The case would branch based on a > parameter that would say which signature we are dealing with, it could be > an enum. No matter what the signature is, this should work, assuming the > image processing function works with image regions. I mean, if it works > with image regions, it can be divided, so we are fine. > > Stefan > > _______________________________________________ > 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
