[Bf-python] get/setPixelF

Chris Want cwant at ualberta.ca
Mon Mar 10 22:57:28 CET 2008


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...

Chris

Campbell Barton wrote:
> 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)
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python




More information about the Bf-python mailing list