Also late to the party, but I also find it weird that we have both a single format/datatype in spec.format, but then also have per-channel format/datatypes in spec.channelformats. There are large parts of the API that don't cater to the per-channel case, and silently fail :(
I would prefer it if we found a nicer way to express the per-channel case. Perhaps there could be only one spec.datatype attribute, but it is a vector that can either contain a single datatype (for the simple case), or one entry per channel for multiple datatypes. In any case, lots of code to refactor if we change the name. Cheers, Mark On Thu, Jan 6, 2022 at 2:00 AM Nathan Rusch <nathanru...@gmail.com> wrote: > I'm late to the party on this one, but I agree that 'format' is a bit > heavily overloaded: In addition to the aforementioned "pixel format", "file > format", and "string formatting", I'll add "image format" (loosely, > geometry) as another one that is wedged pretty firmly in my brain, courtesy > of Nuke. > > If you do decide to go down the road of changing terminology, I would be > in favor of the explicit "datatype" as well. > > Cheers, > -Nathan > > On 12/29/2021 12:40 PM, Larry Gritz wrote: > > Early on (and probably borrowing from prior software), I used > ImageSpec.format as the field describing the data type of the pixel values. > > I've long though that this was an unfortunate mistake, primarily because it > causes endless confusion about the difference between "data format" and "file > format", and awkward phrasing in the documentation. > > Question 1: Does anybody else care? Or is it fine? > > Question 2: If you care, would you like to see me slowly and deliberately > migrate to different terminology, both in the docs and what things are called > in code (functions, struct fields, named parameters, etc.)? Or is the pain of > any changes that would require client code to be edited worse than the > forever-tax of having chosen a confusing name? > > Question 3: If you think we should make changes, what is a more appropriate > name to use? NumPy (which I think is widely used by our constituency) uses > "dtype", so I believe that's a strong contender because of its existing > familiarity, relative clarity, lack of conflict with any other names or > concepts we use, and short name. Or "datatype"? Or something else? > (Suggestions welcome.) > > > -- > Larry grit...@larrygritz.com > > > > > _______________________________________________ > Oiio-dev mailing > listOiio-dev@lists.openimageio.orghttp://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
