[Bf-python] get/setPixelF

[Campbell Barton]

Hey  pythoners.
Stivs and I have a little disagreement.
Their are valid arguments for and against, thought it would be good to
get others input.

http://projects.blender.org/tracker/?func=detail&atid=127&aid=7076&group_id=9

---- extracted from the tracker

----- Matt Ebb's original message.
Currently in Blender, the Image.getPixelF() / setPixelF() functions
don't actually use Blender's float buffers, they
just get the pixel from the char image source and divide by 255. This
is inaccurate, and of course also clamps the high
dynamic range float values to 0.0-1.0 which makes it impossible to do
any work with HDR images in Python.

This patch changes that behaviour to access the float buffers - in
getPixelF, if no float buffer exists, it reverts
to the old behaviour of converting a char buffer to float, and in
setPixelF, if there is no float buffer, it creates
one.

There are two issues here that may take some consideration:
* Old scripts may assume that the values from getPixelF are normalised
to 0.0-1.0 and if used with an HDR image, it
may break the scripts (I wouldn't think this is very likely)
* When using setPixelF, you can't see the results immediately in the
image editor, since the changes haven't been 'flushed'
to the char buffer, which is what's displayed on screen. You can
update it manually by opening up the curves floating
panel and doing a tweak there. There is a function:
 void IMB_rect_from_float(struct ImBuf *ibuf)
that can be used to update the image, but putting it in setPixelF is
very bad, since it's slow, and if you're iterating
over an entire image, you're in for some waiting. Is there any way of
delaying this till afterwards internally? Or perhaps
an Image.update() py function is needed (also to redraw the image
editor, which doesn't happen at all now)

patch and demo file attached.

----------------

Date: 2007-08-23 03:46
Sender: Stephen Swaney

When Image.getPixelF() was originally done, Blender did not have
float buffers.  Being able to manipulate HDR iamges is good,
but breaking the existing API is bad.

Maybe we could call the new methods something like getPixelHDR()
or getPixelHF() if the values are 'half floats'.

The update issue:  having a flush or update method is probably
the way to go here.

----------------

Date: 2008-03-10 12:39
Sender: Campbell Barton

I dont think the argument for keeping the [0.0, 1.0] range is
strong enough to add new functions. We only have a float buffer
not half float buffer internally.

Commited this patch as well as image.updateDisplay()

----------------

Date: 2008-03-10 19:53
Sender: Stephen Swaney

"I dont think the argument for keeping the [0.0, 1.0] range
is strong enough to add new functions."

I strongly disagree.

1) you are breaking the published api.
2) these are new methods that return new values.  Since you can't
overload methods based on return values, they need new names.

If you insist on reusing the old setPixelF() for a new purpose,
you can add a keyword like range={normal,full}.  But the default
would need to be 'normal' in order to keep old scripts working.

But adding a default param is both overkill and inconsistent.
The simplest solution is to make new methods like setPixelFF()
for full floats.  (note: all names are for purpose of illustration.
I am not married to them)