There's actual pixel data which is 0-1.0 for rgba. But all the other bastardizations of 'image' really should use a different structure entirely like for displacement maps, z-depth/distance, masks, vector-pixel data and even intermediate compo results (even if saved in a exr container) even though the currrent rgba grid container has been handy, it has been pertubated way too much imho.but that would be a recode...perhaps force exr as an internal format that could support all the above?
Sent from my iPhone On Dec 14, 2010, at 1:18 AM, Matt Ebb <[email protected]> wrote: > On Tue, Dec 14, 2010 at 4:35 PM, Campbell Barton <[email protected]> wrote: >> On Tue, Dec 14, 2010 at 5:10 AM, Matt Ebb <[email protected]> wrote: >>> On Tue, Dec 14, 2010 at 3:44 PM, Campbell Barton <[email protected]> >>> wrote: >>> >>>> Log Message: >>>> ----------- >>>> disallow RNA color values to be set to negative values. Material colors >>>> could be set to -100.0 if typed in manually, this is sure to cause >>>> bad/unpredictable behavior. >>> >>> If this is a problem for materials, then it should be set in the >>> material colour's range functions. Forcing all colour properties to >>> have these limits is too heavy handed - It's not sure to cause bad >>> behaviour, there are plenty of cases where you might want negative >>> values in a colour property - doing things in the compositor for >>> example. >>> >>> Matt >> >> Hi Matt, >> Yep, materials could have their colors clamped instead (setting value >> ranges is enough, without having range functions). >> However this is the sort of thing that is often overlooked when adding >> properties - color properties like sequencer, bone, object, theme, >> lamp shadow, render stamp, fcurve, brush, world.... etc. >> >> So I think its better to have negative colors opt-in. > > I'm really not sure why. Colours are used for all kinds of things, not > just pixels in an image. They can be used to represent other things > like displacements, or used as relative offsets (eg. some comp nodes), > or all kinds of stuff. Blender uses full linear floating point colours > internally, and there's nothing inherent in that that means they > should only be positive. I think defining this as something that 'all > colours should be always positive' is too great a limitation to apply > as a blanket case across blender - to me it's a similar sort of thing > as the idiotic 'can't make concave faces' error in mesh edit mode, > making an arbitrary yet wide ranging limitation in order to prevent a > few corner cases. > > On a practical level I also disagree since: > * people have to willingly type negative colours into those fields to > start with - if that's what you explicitly type in then you get what > you get > * the idea that things can be added back in as needed I think is > expecting a lot, I don't think it's the sort of thing that people will > be bothered with reporting as bugs > * if it's to prevent bugs, better to fix it at the source, since it > could be a deeper problem. eg. if it's a problem in materials, what > happens when a texture with negative colours is used, or anim sys is > used to get negative values in there, or if a node setup generates > negative colours? Clamping RNA inputs may not be enough there. > > My 2c anyway. > > Matt > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
