- Made them receive number of channels rather than number of planes.
This matches to how ImBuf structure stored planes and channels.
- IMB_premultiply_rect_float() was called with channels passed instead
of planes already :S.
Summary:
Uses some magic pseudo-random which is actually a
texture coordinate hashing function.
TODOs:
- Dither noise is the same for all the frames.
- It's different from Floyd's dither we've been
using before.
- Currently CPU and GPU dithering used different
implementation. Ideally we need to use the same
dither in CPU.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D58
Allocate float buffer outside of image buffer,
so work-in-progress color space conversion doesn't
interfere with other parts of blender.
Covers most of cases -- since image buffer wouldn't
have partially-update float buffer all the rest
areas would be happy.
However, if there're places which updates float
buffer from byte buffer, it's still possible
some WIP color space conversion is displayed on
the screen.
But what a heck someone will do such a crappy
conversion anyway!
This assumptions are now made:
- Internally float buffers are always linear alpha-premul colors
- Readers should worry about delivering float buffers with that
assumptions.
- There's an input image setting to say whether it's stored with
straight/premul alpha on the disk.
- Byte buffers are now assumed have straight alpha, readers should
deliver straight alpha.
Some implementation details:
- Removed scene's color unpremultiply setting, which was very
much confusing and was wrong for default settings.
Now all renderers assumes to deliver premultiplied alpha.
- IMB_buffer_byte_from_float will now linearize alpha when
converting from buffer.
- Sequencer's effects were changed to assume bytes have got
straight alpha. Most of effects will work with bytes still,
however for glow it was more tricky to avoid data loss, so
there's a commented out glow implementation which converts
byte buffer to floats first, operates on floats and returns
bytes back. It's slower and not sure if it should actually
be used -- who're using glow on alpha anyway?
- Sequencer modifiers should also be working nice with straight
bytes now.
- GLSL preview will predivide float textures to make nice shading,
shading with byte textures worked nice (GLSL was assuming straight
alpha).
- Blender Internal will set alpha=1 to the whole sky. The same
happens in Cycles and there's no way to avoid this -- sky is
neither straight nor premul and doesn't fit color pipeline well.
- Straight alpha mode for render result was also eliminated.
- Conversion to correct alpha need to be done before linearizing
float buffer.
- TIFF will now load and save files with proper alpha mode setting
in file meta data header.
- Remove Use Alpha from texture mapping and replaced with image
datablock setting.
Behaves much more predictable and clear from code point of view
and solves possible regressions when non-premultiplied images were
used as textures with ignoring alpha channel.
not do correct partial updates, now it remembers if the opengl texture is a
non-color data texture or not and takes that into account for the update.
Also includes some renaming ncd => is_data for consistency with color space
terminology used elsewhere.
The issue was caused by compositor was allocating float buffer for image and
then this buffer was filled with data converted from byte buffer.
If display happens at time between float was allocated and it was filled black
areas were appearing on the screen.
Made it so IMB_float_from_rect locks color management thread so display
transform wouldn't use uninitialized buffer anymore.
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
- new compositor could use uninitialized var
- profile conversion could use uninitialized var
- set better warnings for clang+cmake.
- remove picky warnings from sphinx doc gen shell script.
Issue is caused by scaling for power of 2 dimensions and mipmapping that happens through GLU. It looks like the library cannot handle float colour values above 1.0 correctly. Since we are close to release I will just clamp the srgb result for now even though it will result in a small performance loss for 16 bit textures only.
I tried a few things before that, glGenerateMipmaps + no scaling (supported for 2.0 GL hardware and up), or using our own scaling instead of glu among them which worked very nicely and gave a speedup too. However, since we are close to release and there may be issues with GPU mipmap generation, see:
http://www.gamedev.net/topic/495747-another-glgeneratemipmap-question/
(old discussion but better be sure than sorry)
I went for the most compatible solution. Maybe after release this can be tested if other devs agree.
* 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.
For premultiplied alpha images, this makes any color space conversion for the image
or render output work on color without alpha multiplied in.
This is typically useful to avoid fringing when the image was or will be composited
over a light background. If the image will be composited over a black background on
the other hand, leaving this option off will give correct results.
In an ideal world, there should never be any color space conversion on images with
alpha, since it's undefined what to do then, but in practice it's useful to have
this option.
Patch by Troy Sobotka, with changes by me.
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.
This fix also allows for partial update of the image, speeding up painting.
The different code path implemented will be used to upload high resolution images to OpenGL when onion branch is merged.
Due to conversion of float textures to/from sRGB, corrections made to brush color sampling to take account of the image profile. This is not 100% correct yet as texture images used for projection painting strokes are not converted to/from sRGB yet(This has been decided due to loss of precision for 8-bit formats). It will have to do for now, though.
last-minute update, exr image loading is broken, will fix asap
Three code fixes for 1 report. User experienced crashes while
painting on float buffer + having preview renders on.
- Texture Nodes: Image was re-allocated without using
proper thread lock
- Paint code: old convention to free the byte rect from
a float image as signal to re-create now is a proper
flag. This keeps image memory unchanged. Nice for render.
- Imbuf: call to make a byte rect from float was freeing
mipmaps unnecessary.
also minor functional changes
- OBJECT_OT_make_links_data() type property is now assigned to the operator property (so popup menu can find it)
- removing BG image now returns cancelled if no image is removed.
- a linear float buffer was being created and saved into a non-linear DPX/Cineon file.
- removed the UI since the settings are not used at the moment.
added a utility function IMB_float_profile_ensure(), which returns a float buffer in the requested profile, using the existing if needed or returning an allocated buffer if the profile is different to that of the ImBuf. - Useful this case where the save function has its own linear setting.
