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 Gritz
l...@larrygritz.com




_______________________________________________
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

Reply via email to