| Age | Commit message (Collapse) | Author |
|---|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
many, also don't check uchar range after casting to int, this can still cause
overflow with large float values.
|
|
also add rgba_float_to_uchar, rgba_uchar_to_float
|
|
rgb_uchar_to_float and swap args (math functions mostly have dest arg first like strcpy).
|
|
use rgb_to_grayscale in more places.
|
|
brushes were doing curve lookups within this macro for example.
|
|
* Accelerated sRGB <=> linear conversion using lookup table, this can speed up
loading of images in the compositor and simple renders quite a bit.
* Dithering now uses the Floyd-Steinberg algorithm. Previously it would simply
randomize each pixel slightly, adding noise, now that should be reduced.
Patch #29309 by David M.
|
|
byte => float, float => float, byte => byte conversions with profile, dither
and predivide. Previously code for this was spread out too much.
There should be no functional changes, this is so the predivide/table/dither
patches can work correctly.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
convert to grayscale when saving renders rather then only writing the red channel.
|
|
|
|
|
|
- made theme colors for mesh edge len & face angle/area display.
- use %g rather then %f for float display, trims unneeded zeros.
- store cached 2d and 3d text color as bytes rather then floats, compare when drawing to avoid setting the context.
- use unsigned char for more color functions, avoids casting to glColorubv().
|
|
|
|
functions
By Luca Bonavita (mindrones)
From detailed description: This patch doesnt change functionality, but uses the existing color math functions from math_color.c into
sequencer_draw.c.
|
|
the render engine assumes the RenderResult's rectf is not in linear color space when color management is disabled so the sequencer and opengl render need to follow this else it results in dark images.
|
|
YCbCr conversion function according to ITU-R BT.601/709 and JFIF
Clarifies color space usage in rgb->ycc conversion, doesn't change existing results.
|
|
|
|
* inline some more functions, from math_base and math_vector
* also made some changes to the way inline is done so it can
work for more than one file
* reflect_v3_v3v3 requires input vectors to be normalized now.
* added rgb_to_grayscale
* added zero_v4, copy_v4_v4, swap_v4_v4, is_one_v3
* added box_clip_bounds_m4 to clip a bounding box against a
projection matrix
|
|
similar to sequence editor.
--> http://mke3.net/blender/devel/2.5/color_balance_node.jpg
Also added 0 key (zero key) shortcut when mouse is over a button, to reset it to its default value.
Same as the RMB menu ->Reset to Default, except for color wheels, it only resets the hue/sat/value
components that that widget affects.
Peter/Xavier: The existing color balance code can generate NaNs (fractional power of a negative),
which causes havoc along the image pipeline. I added a check in the node code to prevent this.
Still plenty of potential for lots of better colour correction tools in the compositor, just needs time...
|
|
A solid color backdrop is now drawn behind the mute/protect toggles and sliders, reducing the visual clutter with long names still appearing behind the UI widgets.
|
|
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
|
|
* New header and source files.
* Still need a few tweaks before switching code to use them.
|
