Larry, I looked at the ImageBuf code. I need to save three images but without the "-o" flag.
./oiiotool --histogram_rgb_components prefix dir input.tif So for one RGB image input.tif three histograms will be saved for the R, G and B components. The names of those files will be dir + prefix + "_R" for example for R. I don't want the user to specify three separate paths. On 3/28/12, Stefan Stavrev <[email protected]> wrote: > I left that to be done last, I am finishing up the rest now since they > all follow similar pattern for working with images. > > Basically all the algorithms work with images in the following ways: > > 1. one input image -> one output image > 2. more input images -> one output image > 3. one input image -> more output images > > All the algorithms but one, work like 1 and 2. Just one algorithm > works as 3, and so I left it last. For 3 I need to save more images, > that is why I asked about ImageBuf::save and did not rely on using the > stack for saving images. I will let you know what happens as soon as > possible. > > Thanks > > > On 3/28/12, Larry Gritz <[email protected]> wrote: >> That's fine, yes. >> >> Were you able to make use of that pull request I submitted related to the >> ImageBuf's? >> >> -- lg >> >> >> On Mar 28, 2012, at 10:14 AM, Stefan Stavrev wrote: >> >>> If not tonight, then tomorrow I should finish command line >>> functionality for all the algorithms. >>> >>> I will make a pdf for the usage of the algorithms including example >>> images of what they do. Would it be ok if I update my current branch >>> with ALL the code and give you the pdf to play with the commands? >>> >>> Then I would create a new branch and place just one algorithm in it >>> and make a pull request for that. Once that is approved, I will update >>> the code with the next algorithm and so on. Algorithm by algorithm. >>> >>> Thanks >>> >>> >>> >>> >>> >>> On 3/28/12, Larry Gritz <[email protected]> wrote: >>>> On Mar 28, 2012, at 7:20 AM, Stefan Stavrev wrote: >>>> >>>>> 1. Would it be ok if I send 20 or so pull requests at once? >>>> >>>> That would be awkward. A pull request is for ALL differences between >>>> one >>>> of >>>> your branches versus our master at the point where your branch >>>> diverged. >>>> If >>>> you continue to push changes to that branch after you submit the pull >>>> request, the pull request will simply automatically update. So to make >>>> 20 >>>> separate simultaneous pull requests, you need them to come from 20 >>>> separate >>>> topic branches. >>>> >>>> As a practical matter, this doesn't make sense. If you have several >>>> related >>>> changes, they should all be one pull request (although it's a sign that >>>> you >>>> should have had a smaller pull request earlier, got that approved and >>>> committed, then continued from that point). If you have several >>>> unrelated >>>> changes, they should have separate pull requests, but from separate >>>> topic >>>> branches. >>>> >>>> As a more experienced developer (after you've had several commits >>>> approved), >>>> it will make sense to batch related changes up into larger pull >>>> requests. >>>> For now, I just wanted you to get the first couple small ones out of >>>> the >>>> way, it makes things easier. >>>> >>>> >>>>> 2. What if minor changes are needed for a pull request? Last time I >>>>> tried to update the code in my pull request I got some errors. >>>> >>>> It should be the case that you merely need to commit additional changes >>>> to >>>> the topic branch, then push it to your GH account. What errors exactly >>>> did >>>> you see? >>>> >>>> >>>>> 3. The license file is in dist/doc named LICENSE right? I guess I >>>>> should change the year to 2012 for this line: "Copyright 2008 Larry >>>>> Gritz and the other authors and contributors." ? >>>> >>>> No, please don't change anything you aren't directly working on. If >>>> you >>>> make a *new* file, by all means use 2012 in that comment. But there's >>>> no >>>> reason (legal or otherwise) to change the existing notices, and my it >>>> conflicts with my philosophy that commits should be minimal and >>>> orthogonal >>>> (not mixing completely unrelated changes). If we ever needed to change >>>> the >>>> license or copyright (which we don't -- it would offer no additional >>>> protection), we would do it across the board as a single commit with >>>> nothing >>>> else included. >>>> >>>> -- >>>> 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
