Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-04-02More usage of GLSL for color managed image drawingSergey Sharybin
Uses GLSL for drawing image in Image Editor space. This requires change in image_buffer_rect_update, so original float buffer is being updated as well. This is unlikely be something bad, but will keep an eye on this change. Also no byte buffer allocation happens there, this is so because byte buffer used for display only and in case of GLSL display such allocation and partial update is just waste of time. Also switched OpenGL render from using CPU color space linearization to GLSL color space transform. Makes OpenGL rendering pretty much faster (but still slower than in 2.60). internal changes: - Added functions to setup GLSL shader for color space conversion in colormanagement.c. Currently conversion form a colorspace defined by a role to linear space is implemented. Easy to extend to other cases. - Added helper functions to glutil.c which does smarter image buffer draw (calling all needed OCIO stuff, editors now could draw image buffer with a single function call -- all the checks are done in glutil.c). - Also added helper function for buffer linearization from a given role to glutil.c. Everyone now able to linearize buffer with a single call. This function will do nothing is GLSL routines fails or not supported. And one last this: this function uses offscreen drawing, could potentially give issues on some cards, also will keep an eye on this.
2013-03-29Implement GPU-side display transform for clip editorSergey Sharybin
Implemented using GLSL API from OpenColorIO library and some general functions were added to it's c-api: - OCIO_setupGLSLDraw prepares OpenGL context for GPU-based transformation for a giver processor. This function compiles and links shader, sets up it's argument. After this transformation would be applied on an image displaying as a 2D texture. So, glaDrawPixelsTex called after OCIO_setupGLSLDraw will do a proper color space transform. - OCIO_finishGLSLDraw restores OpenGL context after all color-managed display is over. - OCIO_freeOGLState frees allocated state structure used for cacheing some GLSL-related stuff. There're some utility functions in IMB_colormanagent which are basically proxies to lower level OCIO functions but which could be used from any place in blender. Chacheing of movie clip frame on GPU is also removed now, and either glaDrawPixelsTex or glaDrawPixelsAuto are used for display now. This is so no code duplication happens now and no large textures are lurking around in GPU memory. Known issues: - Texture buffer and GLSL are no longer checking for video card capabilities, possibly could lead to some artifacts on crappy drivers/cards. - Only float buffers are displaying using GLSL, byte buffers will still use fallback display method. This is to be addressed later. - If RGB curves are used as a part of display transform, GLSL display will also be disabled. This is also thing to be solved later. Additional changes: - glaDrawPixelsTexScaled will now use RGBA16F as an internal format of storing textures when it's used to draw float buffer. This is needed so LUT are applied without precision loss.
2013-03-18Fix #34672: Image sampling line didn't use color management for byte buffersSergey Sharybin
This makes it so sample line (for all image editor, sequencer and compositor) displaying managed color for byte buffers as well. It was simply not implemented before.
2013-02-11Implemented delayed partial rect update for image buffersSergey Sharybin
Used by image painting mode, so every brush step would mark area if affected on, but actual color space conversion would happen later when actually displaying image. Implemented as a rcti stored in ImBuf which is getting merged with partial rect passed to IMB_partial_display_buffer_update_delayed. This makes painting as fast as it currently possible and finally solves #33935: Texture painting slow down with mouse, but not with tablet
2012-12-31Alpha premul pipeline cleanupSergey Sharybin
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.
2012-10-23Correction to recent fix for shader nodes -- image could be not loaded yetSergey Sharybin
when tree is being executed. This could lead to nor initialized color space for the image. Solved by insuring image buffer is loaded before checking for whether color conversion is needed.
2012-10-22Fix #32930: texture colors in material nodes (blender internal) are brighter ↵Sergey Sharybin
than normal There was a missing byte buffer linearization for shader nodes. Also fixed incorrect image input color space refresh when image is packed.
2012-10-13Cycles: progressive refine optionSergey Sharybin
Just makes progressive refine :) This means the whole image would be refined gradually using as much threads as it's set in performance settings. Having enough tiles is required to have this option working as it's expected. Technically it's implemented by repeatedly computing next sample for all the tiles before switching to next sample. This works around 7-12% slower than regular tile-based rendering, so use this option only if you really need it. This commit also fixes progressive update of image when Save Buffers option is enabled. And one more thing this commit fixes is handling display buffer with Save Buffers option enabled. If this option is enabled image buffer wouldn't have neither byte nor float buffer until image is fully rendered which could backfire in missing image while rendering in cases color management cache became full. This issue solved by allocating byte buffer for image buffer from tile update callback. Patch was reviewed by Brecht. He also made some minor edits to original version to patch. Thanks, man!
2012-09-26Color Management: resolve warnings when OCIO configuration file misses None ↵Sergey Sharybin
display
2012-09-25code cleanup: make naming more consistentSergey Sharybin
2012-09-25Color Management: float generated images had is_data flag set incorrectSergey Sharybin
2012-09-24Fix #32644: ctrl+F11 internal animation player crashSergey Sharybin
Crash was caused by missed color management initialization -- it was happening too late. Move it to generic ImBuf init/exit functions, so now color management is properly initializing when animation player is launched.
2012-09-24Proper fix for #32626: TIFF renders are limited to 8 bit even when we choose 16.Sergey Sharybin
Color management would be applied on both of float and byte buffers on image save in cases if file format doesn't require linear float buffer and if image is saving as render result. This solves both initial report issue and TODO marked in previous fix. Also de-duplicated image buffer color managing code and gave some more meaningful names for few functions. Also wrote documentation around this function, so current assumptions about spaces should be clear enough. Made regression tests by saving EXR/PNG images to all supported format and rendering OpenGL/Normal animation, in all cases seems everything is fine, but more tests for sure would be welcome.
2012-09-22Color Management: different fixes for byte buffersSergey Sharybin
- Color space of byte buffer for generated images haven't been updated properly on change - Byte buffers weren't handling data color spaces on display transform properly
2012-09-15Color Management, Stage 2: Switch color pipeline to use OpenColorIOSergey Sharybin
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!