Currently we're pulling from master...which I think its advertising itself as 1.1. I'm sure you could knock out the --chnames flag faster than me, specially if your doing a big refactor. I'll work in getting those verbose messages in place. Thanks
On Wed, Apr 3, 2013 at 3:43 AM, Larry Gritz <[email protected]> wrote: > Are you guys concerned primarily with master, or are you using 1.1? > > maketx is in transition right now; we're switching to a new code path > (internal to libOpenImageIO, rather than all the good bits just in the > maketx binary, and quite overhauled for performance improvements), so it's > a bit different in master and 1.1. > > In this instance, it may be easier for me to make the --chnames change, > unless you really had your heart set on trying it yourself. (If you want > to take a crack at something, the verbose messages thing you mentioned > might be a good toe in the water.) > > > On Apr 2, 2013, at 12:52 AM, Matt Chambers wrote: > > Ha, I didn't see that oiiotool option, I'm going to use that for now. > > I think think for most cases that is a good assumption...for a particular > internal case we need it in R. I'd love for there to be no extra step > because then it makes this really easy for all departments when every > single texture publish can be done with a single maketx command. > > I'd love to give it a try. Would I add a --chnames option that would just > override the channel names for any operation? > > -Matt > > > On Tue, Apr 2, 2013 at 8:36 PM, Larry Gritz <[email protected]> wrote: > >> Fundamentally, I think the problem is >> with ImageSpec::default_channel_names () (in >> src/libOpenImageIO/formatspec.cpp). There's an assumption that if channels >> aren't named (hello, TIFF) and there's only one channel in an image, it >> will be "A" in the absence of any other information. I dunno, maybe that's >> a bad assumption, but nobody every complained before. >> >> oiiotool --chnames can be used after the fact to rename channels. If you >> don't want that extra step, we could probably put a similar option in >> maketx directly. >> >> Yes, we would welcome the patch you describe (or any other). >> >> -- lg >> >> >> On Apr 2, 2013, at 12:25 AM, Matt Chambers wrote: >> >> Yeah, pretty much. The input image is 1 channel, I need it to go into R, >> not A...an internal thing. I've poked around the code a bit but I can't >> tell where its happening. I'd be happy to add an option if you can point >> me to the right place. >> >> Also, somewhat related, my colleagues have been using (or trying to use) >> a lot of the optimization options like monochrome-detect and opaque detect, >> but there is actually a few other checks maketx does before enabling those >> options. Can I push you a patch where in verbose mode it would tell you if >> those things were ignored because they conflicted with another option or >> the number of channels in the source image was too high? >> >> -Matt >> >> > -- > 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
