[Bf-python] get/setPixelF

[Campbell Barton]

On Tue, Mar 11, 2008 at 3:30 AM, Stephen Swaney <sswaney at centurytel.net> wrote:
> On Mon, Mar 10, 2008 at 03:57:28PM -0600, Chris Want wrote:
>  >
>  > I can't say I fully understand the scope of this modification, but I
>  > would lean towards compatibility with published documentation
>  > (especially since you can't overload based on return value,
>  > as Stephen mentions). I also think it's best to have these kinds
>  > of discussions *before* committing.
>  >
>  > Having said that, it would probably be better to get the opinion
>  > of somebody who has actually used this API routine...
>
>  in a nutshell:
>
>  we have some functions in the Image class for getting and setting pixels.
>
>  example:
>
>   getPixelI() returns values as ints range 0-255
>   getPixelF() returns values as normalized floats 0.0-1.0
>
>  Pretty standard 8 bit image processing stuff.
>
>  Blender now has float buffers.  Patch 7076 adds the getPixel/setPixel
>  methods.  These methods operate with full range floats.
>
>  The Problem: rather than creating a new name (like getPixelFullFloat
>  or such) for the new methods, the patch rewrites the existing
>  getPixelF method.
>
>  Resolution: give the new methods names that do not step on existing
>  methods.  There is no reason to break the api here.  The new methods
>  operate on different datatypes so they should be treated as new
>  methods.
>
>  --

While its possible to break existing scripts I dont think it will be a
problem practically.
1) I doubt anyone is using this in a production environment, since
pixel operations in python are fairly slow. its mainly useful for
prototyping.
2) Anyone using this function for their daily work (I doubt it)
probably isnt making use of EXR/DPX images, so it should not effect
them.
3) Does anyone even use this function in a way that depends on 0-1
range? - a quick google didnt show any.

Ok, so my arguments are not strong ;-) however searching online shows
this function is not in heavy use, none of blenders bundled scripts
use it for example.

If we are worried about breaking the api in areas we don't have any
example scripts for? Why not look at changes in the api that break
existing scripts?

- Setting a Mesh color used to work then it had me.faceUV, now vertex
colors need to be added separate, solution. if there are UV's add the
color layer when needed or fake white color on read. and add a color
layer on write. - This broke a number of importers.
- Setting the camera lens used to work with ints. cam.setLens(2),
cam.setScale(1), cam.setClipStart(1), cam.setClipEnd(3) and
cam.setDrawSize(4), all these used to work and dont anymore. I noticed
when my renderfarm script raised an error. Sorry Ken for bringing this
up here, should have mentioned earlier.
- Particles api is broken, this is really really really bad. - see
http://lists.blender.org/pipermail/bf-python/2008-March/005178.html
maybe some devs could help with this.

I should have listed these somewhere else, in the tracker, however I
thought the problems listed below are just apart of working with an
API interfacing Blender - a moving target ;)



When writing scripts I find it especially annoying when there is...
spam.someFunc() and spam.someFuncWorkProperly()

examples are....
ob.data vs ob.getData(mesh=1) - without it deprecated nmesh is returned.
ob.getMaterials(what=0) - can anyone remember what what is?, one skips
None materials. material indicies dont work.
we have scene.getLayers(), scene.layers, scene.Layers, I still forget
which is a list and which is a mask

In the interest of not adding new functions for changes in blenders
limits, Id prefer not to have separate functions for this.