This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/editors/space_image/image_draw.c

935 lines
26 KiB
C
Raw Normal View History

/*
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* Contributor(s): Blender Foundation, 2002-2009
*
* ***** END GPL LICENSE BLOCK *****
*/
2011-02-27 20:29:51 +00:00
/** \file blender/editors/space_image/image_draw.c
* \ingroup spimage
*/
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include <math.h>
#include <stdlib.h>
#include <string.h>
#include "MEM_guardedalloc.h"
#include "DNA_camera_types.h"
#include "DNA_object_types.h"
#include "DNA_space_types.h"
#include "DNA_scene_types.h"
#include "DNA_screen_types.h"
#include "DNA_brush_types.h"
#include "DNA_mask_types.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "PIL_time.h"
#include "BLI_math.h"
2012-08-20 23:06:17 +00:00
#include "BLI_rect.h"
#include "BLI_threads.h"
#include "BLI_string.h"
#include "BLI_utildefines.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "IMB_imbuf.h"
#include "IMB_imbuf_types.h"
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
#include "IMB_colormanagement.h"
#include "IMB_moviecache.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "BKE_context.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "BKE_global.h"
#include "BKE_image.h"
#include "BKE_paint.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "BIF_gl.h"
#include "BIF_glutil.h"
#include "BLF_api.h"
#include "ED_gpencil.h"
#include "ED_image.h"
#include "ED_mask.h"
#include "ED_screen.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "UI_interface.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "UI_resources.h"
#include "UI_view2d.h"
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
#include "WM_api.h"
#include "WM_types.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "RE_pipeline.h"
#include "RE_engine.h"
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
#include "image_intern.h"
static void draw_render_info(Scene *scene, Image *ima, ARegion *ar, float zoomx, float zoomy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
RenderResult *rr;
Render *re = RE_GetRender(scene->id.name);
2012-03-28 11:53:18 +00:00
rr = BKE_image_acquire_renderresult(scene, ima);
if (rr && rr->text) {
float fill_color[4] = {0.0f, 0.0f, 0.0f, 0.25f};
ED_region_info_draw(ar, rr->text, 1, fill_color);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
BKE_image_release_renderresult(scene, ima);
if (re) {
int total_tiles;
rcti *tiles;
RE_engine_get_current_tiles(re, &total_tiles, &tiles);
if (total_tiles) {
int i, x, y;
rcti *tile;
/* find window pixel coordinates of origin */
UI_view2d_to_region_no_clip(&ar->v2d, 0.0f, 0.0f, &x, &y);
glPushMatrix();
glTranslatef(x, y, 0.0f);
glScalef(zoomx, zoomy, 1.0f);
if (scene->r.mode & R_BORDER) {
glTranslatef((int)(-scene->r.border.xmin * scene->r.xsch * scene->r.size / 100.0f),
(int)(-scene->r.border.ymin * scene->r.ysch * scene->r.size / 100.0f),
0.0f);
}
UI_ThemeColor(TH_FACE_SELECT);
for (i = 0, tile = tiles; i < total_tiles; i++, tile++) {
float delta_x = 4.0f * UI_DPI_FAC / zoomx;
float delta_y = 4.0f * UI_DPI_FAC / zoomy;
delta_x = min_ff(delta_x, tile->xmax - tile->xmin);
delta_y = min_ff(delta_y, tile->ymax - tile->ymin);
/* left bottom corner */
glBegin(GL_LINE_STRIP);
glVertex2f(tile->xmin, tile->ymin + delta_y);
glVertex2f(tile->xmin, tile->ymin);
glVertex2f(tile->xmin + delta_x, tile->ymin);
glEnd();
/* left top corner */
glBegin(GL_LINE_STRIP);
glVertex2f(tile->xmin, tile->ymax - delta_y);
glVertex2f(tile->xmin, tile->ymax);
glVertex2f(tile->xmin + delta_x, tile->ymax);
glEnd();
/* right bottom corner */
glBegin(GL_LINE_STRIP);
glVertex2f(tile->xmax - delta_x, tile->ymin);
glVertex2f(tile->xmax, tile->ymin);
glVertex2f(tile->xmax, tile->ymin + delta_y);
glEnd();
/* right top corner */
glBegin(GL_LINE_STRIP);
glVertex2f(tile->xmax - delta_x, tile->ymax);
glVertex2f(tile->xmax, tile->ymax);
glVertex2f(tile->xmax, tile->ymax - delta_y);
glEnd();
}
MEM_freeN(tiles);
glPopMatrix();
}
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
/* used by node view too */
2014-03-31 23:39:08 +11:00
void ED_image_draw_info(Scene *scene, ARegion *ar, bool color_manage, bool use_default_view, int channels, int x, int y,
const unsigned char cp[4], const float fp[4], const float linearcol[4], int *zp, float *zpf)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
rcti color_rect;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
char str[256];
int dx = 6;
const int dy = 0.3f * UI_UNIT_Y;
/* text colors */
/* XXX colored text not allowed in Blender UI */
#if 0
unsigned char red[3] = {255, 50, 50};
unsigned char green[3] = {0, 255, 0};
unsigned char blue[3] = {100, 100, 255};
#else
unsigned char red[3] = {255, 255, 255};
unsigned char green[3] = {255, 255, 255};
unsigned char blue[3] = {255, 255, 255};
#endif
2012-03-28 11:53:18 +00:00
float hue = 0, sat = 0, val = 0, lum = 0, u = 0, v = 0;
float col[4], finalcol[4];
2012-03-28 11:53:18 +00:00
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glEnable(GL_BLEND);
/* noisy, high contrast make impossible to read if lower alpha is used. */
glColor4ub(0, 0, 0, 190);
glRecti(0.0, 0.0, BLI_rcti_size_x(&ar->winrct) + 1, UI_UNIT_Y);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glDisable(GL_BLEND);
BLF_size(blf_mono_font, 11 * U.pixelsize, U.dpi);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glColor3ub(255, 255, 255);
BLI_snprintf(str, sizeof(str), "X:%-4d Y:%-4d |", x, y);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
if (zp) {
glColor3ub(255, 255, 255);
2012-03-28 11:53:18 +00:00
BLI_snprintf(str, sizeof(str), " Z:%-.4f |", 0.5f + 0.5f * (((float)*zp) / (float)0x7fffffff));
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
}
if (zpf) {
glColor3ub(255, 255, 255);
BLI_snprintf(str, sizeof(str), " Z:%-.3f |", *zpf);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
}
if (channels >= 3) {
glColor3ubv(red);
if (fp)
BLI_snprintf(str, sizeof(str), " R:%-.5f", fp[0]);
else if (cp)
BLI_snprintf(str, sizeof(str), " R:%-3d", cp[0]);
else
BLI_snprintf(str, sizeof(str), " R:-");
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
glColor3ubv(green);
if (fp)
BLI_snprintf(str, sizeof(str), " G:%-.5f", fp[1]);
else if (cp)
BLI_snprintf(str, sizeof(str), " G:%-3d", cp[1]);
else
BLI_snprintf(str, sizeof(str), " G:-");
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
glColor3ubv(blue);
if (fp)
BLI_snprintf(str, sizeof(str), " B:%-.5f", fp[2]);
else if (cp)
BLI_snprintf(str, sizeof(str), " B:%-3d", cp[2]);
else
BLI_snprintf(str, sizeof(str), " B:-");
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
if (channels == 4) {
glColor3ub(255, 255, 255);
if (fp)
BLI_snprintf(str, sizeof(str), " A:%-.4f", fp[3]);
else if (cp)
BLI_snprintf(str, sizeof(str), " A:%-3d", cp[3]);
else
BLI_snprintf(str, sizeof(str), "- ");
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (color_manage) {
float rgba[4];
copy_v3_v3(rgba, linearcol);
if (channels == 3)
rgba[3] = 1.0f;
else
rgba[3] = linearcol[3];
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (use_default_view)
IMB_colormanagement_pixel_to_display_space_v4(rgba, rgba, NULL, &scene->display_settings);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
else
IMB_colormanagement_pixel_to_display_space_v4(rgba, rgba, &scene->view_settings, &scene->display_settings);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
BLI_snprintf(str, sizeof(str), " | CM R:%-.4f G:%-.4f B:%-.4f", rgba[0], rgba[1], rgba[2]);
BLF_position(blf_mono_font, dx, dy, 0);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
}
}
/* color rectangle */
2012-03-28 11:53:18 +00:00
if (channels == 1) {
if (fp) {
col[0] = col[1] = col[2] = fp[0];
}
else if (cp) {
2012-03-28 11:53:18 +00:00
col[0] = col[1] = col[2] = (float)cp[0] / 255.0f;
}
else {
col[0] = col[1] = col[2] = 0.0f;
}
col[3] = 1.0f;
}
2012-03-28 11:53:18 +00:00
else if (channels == 3) {
copy_v3_v3(col, linearcol);
col[3] = 1.0f;
}
2012-03-28 11:53:18 +00:00
else if (channels == 4) {
copy_v4_v4(col, linearcol);
}
else {
BLI_assert(0);
zero_v4(col);
}
if (color_manage) {
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (use_default_view)
IMB_colormanagement_pixel_to_display_space_v4(finalcol, col, NULL, &scene->display_settings);
else
IMB_colormanagement_pixel_to_display_space_v4(finalcol, col, &scene->view_settings, &scene->display_settings);
}
else {
copy_v4_v4(finalcol, col);
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
glDisable(GL_BLEND);
dx += 0.25f * UI_UNIT_X;
BLI_rcti_init(&color_rect, dx, dx + (1.5f * UI_UNIT_X), 0.15f * UI_UNIT_Y, 0.85f * UI_UNIT_Y);
if (channels == 4) {
rcti color_rect_half;
int color_quater_x, color_quater_y;
color_rect_half = color_rect;
color_rect_half.xmax = BLI_rcti_cent_x(&color_rect);
glRecti(color_rect.xmin, color_rect.ymin, color_rect.xmax, color_rect.ymax);
color_rect_half = color_rect;
color_rect_half.xmin = BLI_rcti_cent_x(&color_rect);
color_quater_x = BLI_rcti_cent_x(&color_rect_half);
color_quater_y = BLI_rcti_cent_y(&color_rect_half);
glColor4ub(UI_ALPHA_CHECKER_DARK, UI_ALPHA_CHECKER_DARK, UI_ALPHA_CHECKER_DARK, 255);
glRecti(color_rect_half.xmin, color_rect_half.ymin, color_rect_half.xmax, color_rect_half.ymax);
glColor4ub(UI_ALPHA_CHECKER_LIGHT, UI_ALPHA_CHECKER_LIGHT, UI_ALPHA_CHECKER_LIGHT, 255);
glRecti(color_quater_x, color_quater_y, color_rect_half.xmax, color_rect_half.ymax);
glRecti(color_rect_half.xmin, color_rect_half.ymin, color_quater_x, color_quater_y);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glColor4f(UNPACK3(finalcol), fp ? fp[3] : (cp[3] / 255.0f));
glRecti(color_rect.xmin, color_rect.ymin, color_rect.xmax, color_rect.ymax);
glDisable(GL_BLEND);
}
else {
glColor3fv(finalcol);
glRecti(color_rect.xmin, color_rect.ymin, color_rect.xmax, color_rect.ymax);
}
/* draw outline */
glColor3ub(128, 128, 128);
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
glRecti(color_rect.xmin, color_rect.ymin, color_rect.xmax, color_rect.ymax);
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
dx += 1.75f * UI_UNIT_X;
glColor3ub(255, 255, 255);
if (channels == 1) {
if (fp) {
rgb_to_hsv(fp[0], fp[0], fp[0], &hue, &sat, &val);
rgb_to_yuv(fp[0], fp[0], fp[0], &lum, &u, &v);
}
else if (cp) {
2012-03-28 11:53:18 +00:00
rgb_to_hsv((float)cp[0] / 255.0f, (float)cp[0] / 255.0f, (float)cp[0] / 255.0f, &hue, &sat, &val);
rgb_to_yuv((float)cp[0] / 255.0f, (float)cp[0] / 255.0f, (float)cp[0] / 255.0f, &lum, &u, &v);
}
BLI_snprintf(str, sizeof(str), "V:%-.4f", val);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
BLI_snprintf(str, sizeof(str), " L:%-.4f", lum);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
}
else if (channels >= 3) {
rgb_to_hsv(finalcol[0], finalcol[1], finalcol[2], &hue, &sat, &val);
rgb_to_yuv(finalcol[0], finalcol[1], finalcol[2], &lum, &u, &v);
BLI_snprintf(str, sizeof(str), "H:%-.4f", hue);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
BLI_snprintf(str, sizeof(str), " S:%-.4f", sat);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
BLI_snprintf(str, sizeof(str), " V:%-.4f", val);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
BLI_snprintf(str, sizeof(str), " L:%-.4f", lum);
BLF_position(blf_mono_font, dx, dy, 0);
BLF_draw_ascii(blf_mono_font, str, sizeof(str));
dx += BLF_width(blf_mono_font, str, sizeof(str));
}
(void)dx;
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* image drawing */
static void sima_draw_alpha_pixels(float x1, float y1, int rectx, int recty, unsigned int *recti)
{
/* swap bytes, so alpha is most significant one, then just draw it as luminance int */
if (ENDIAN_ORDER == B_ENDIAN)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glPixelStorei(GL_UNPACK_SWAP_BYTES, 1);
glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE, GL_UNSIGNED_INT, recti);
glPixelStorei(GL_UNPACK_SWAP_BYTES, 0);
}
static void sima_draw_alpha_pixelsf(float x1, float y1, int rectx, int recty, float *rectf)
{
2012-03-28 11:53:18 +00:00
float *trectf = MEM_mallocN(rectx * recty * 4, "temp");
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
int a, b;
2012-03-28 11:53:18 +00:00
for (a = rectx * recty - 1, b = 4 * a + 3; a >= 0; a--, b -= 4)
trectf[a] = rectf[b];
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE, GL_FLOAT, trectf);
MEM_freeN(trectf);
/* ogl trick below is slower... (on ATI 9600) */
// glColorMask(1, 0, 0, 0);
2013-02-02 04:58:03 +00:00
// glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_RGBA, GL_FLOAT, rectf + 3);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
// glColorMask(0, 1, 0, 0);
2013-02-02 04:58:03 +00:00
// glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_RGBA, GL_FLOAT, rectf + 2);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
// glColorMask(0, 0, 1, 0);
2013-02-02 04:58:03 +00:00
// glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_RGBA, GL_FLOAT, rectf + 1);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
// glColorMask(1, 1, 1, 1);
}
static void sima_draw_zbuf_pixels(float x1, float y1, int rectx, int recty, int *recti)
{
/* zbuffer values are signed, so we need to shift color range */
glPixelTransferf(GL_RED_SCALE, 0.5f);
glPixelTransferf(GL_GREEN_SCALE, 0.5f);
glPixelTransferf(GL_BLUE_SCALE, 0.5f);
glPixelTransferf(GL_RED_BIAS, 0.5f);
glPixelTransferf(GL_GREEN_BIAS, 0.5f);
glPixelTransferf(GL_BLUE_BIAS, 0.5f);
glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE, GL_INT, recti);
glPixelTransferf(GL_RED_SCALE, 1.0f);
glPixelTransferf(GL_GREEN_SCALE, 1.0f);
glPixelTransferf(GL_BLUE_SCALE, 1.0f);
glPixelTransferf(GL_RED_BIAS, 0.0f);
glPixelTransferf(GL_GREEN_BIAS, 0.0f);
glPixelTransferf(GL_BLUE_BIAS, 0.0f);
}
static void sima_draw_zbuffloat_pixels(Scene *scene, float x1, float y1, int rectx, int recty, float *rect_float)
{
float bias, scale, *rectf, clipend;
int a;
2012-03-28 11:53:18 +00:00
if (scene->camera && scene->camera->type == OB_CAMERA) {
bias = ((Camera *)scene->camera->data)->clipsta;
clipend = ((Camera *)scene->camera->data)->clipend;
scale = 1.0f / (clipend - bias);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
else {
2012-03-28 11:53:18 +00:00
bias = 0.1f;
scale = 0.01f;
clipend = 100.0f;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
2012-03-28 11:53:18 +00:00
rectf = MEM_mallocN(rectx * recty * 4, "temp");
for (a = rectx * recty - 1; a >= 0; a--) {
if (rect_float[a] > clipend)
rectf[a] = 0.0f;
else if (rect_float[a] < bias)
rectf[a] = 1.0f;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
else {
2012-03-28 11:53:18 +00:00
rectf[a] = 1.0f - (rect_float[a] - bias) * scale;
rectf[a] *= rectf[a];
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
}
glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE, GL_FLOAT, rectf);
MEM_freeN(rectf);
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
static void draw_image_buffer(const bContext *C, SpaceImage *sima, ARegion *ar, Scene *scene, ImBuf *ibuf, float fx, float fy, float zoomx, float zoomy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
int x, y;
/* set zoom */
glPixelZoom(zoomx, zoomy);
glaDefine2DArea(&ar->winrct);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* find window pixel coordinates of origin */
UI_view2d_to_region_no_clip(&ar->v2d, fx, fy, &x, &y);
/* this part is generic image display */
if (sima->flag & SI_SHOW_ALPHA) {
if (ibuf->rect)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
sima_draw_alpha_pixels(x, y, ibuf->x, ibuf->y, ibuf->rect);
2012-03-28 11:53:18 +00:00
else if (ibuf->rect_float && ibuf->channels == 4)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
sima_draw_alpha_pixelsf(x, y, ibuf->x, ibuf->y, ibuf->rect_float);
}
2012-03-28 11:53:18 +00:00
else if (sima->flag & SI_SHOW_ZBUF && (ibuf->zbuf || ibuf->zbuf_float || (ibuf->channels == 1))) {
if (ibuf->zbuf)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
sima_draw_zbuf_pixels(x, y, ibuf->x, ibuf->y, ibuf->zbuf);
else if (ibuf->zbuf_float)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
sima_draw_zbuffloat_pixels(scene, x, y, ibuf->x, ibuf->y, ibuf->zbuf_float);
2012-03-28 11:53:18 +00:00
else if (ibuf->channels == 1)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
sima_draw_zbuffloat_pixels(scene, x, y, ibuf->x, ibuf->y, ibuf->rect_float);
}
else {
if (sima->flag & SI_USE_ALPHA) {
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
2012-03-28 11:53:18 +00:00
fdrawcheckerboard(x, y, x + ibuf->x * zoomx, y + ibuf->y * zoomy);
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glaDrawImBuf_glsl_ctx(C, ibuf, x, y, GL_NEAREST);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (sima->flag & SI_USE_ALPHA)
glDisable(GL_BLEND);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
/* reset zoom */
glPixelZoom(1.0f, 1.0f);
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
static unsigned int *get_part_from_buffer(unsigned int *buffer, int width, short startx, short starty, short endx, short endy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
unsigned int *rt, *rp, *rectmain;
short y, heigth, len;
/* the right offset in rectot */
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
rt = buffer + (starty * width + startx);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
len = (endx - startx);
heigth = (endy - starty);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
rp = rectmain = MEM_mallocN(heigth * len * sizeof(int), "rect");
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
for (y = 0; y < heigth; y++) {
memcpy(rp, rt, len * 4);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
rt += width;
2012-03-28 11:53:18 +00:00
rp += len;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
return rectmain;
}
static void draw_image_buffer_tiled(SpaceImage *sima, ARegion *ar, Scene *scene, Image *ima, ImBuf *ibuf, float fx, float fy, float zoomx, float zoomy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
unsigned char *display_buffer;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
unsigned int *rect;
int dx, dy, sx, sy, x, y;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
void *cache_handle;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* verify valid values, just leave this a while */
2012-03-28 11:53:18 +00:00
if (ima->xrep < 1) return;
if (ima->yrep < 1) return;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (ima->flag & IMA_VIEW_AS_RENDER)
display_buffer = IMB_display_buffer_acquire(ibuf, &scene->view_settings, &scene->display_settings, &cache_handle);
else
display_buffer = IMB_display_buffer_acquire(ibuf, NULL, &scene->display_settings, &cache_handle);
if (!display_buffer)
return;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glPixelZoom(zoomx, zoomy);
2012-03-28 11:53:18 +00:00
if (sima->curtile >= ima->xrep * ima->yrep)
sima->curtile = ima->xrep * ima->yrep - 1;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* retrieve part of image buffer */
dx = max_ii(ibuf->x / ima->xrep, 1);
dy = max_ii(ibuf->y / ima->yrep, 1);
2012-03-28 11:53:18 +00:00
sx = (sima->curtile % ima->xrep) * dx;
sy = (sima->curtile / ima->xrep) * dy;
2012-09-30 06:12:47 +00:00
rect = get_part_from_buffer((unsigned int *)display_buffer, ibuf->x, sx, sy, sx + dx, sy + dy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* draw repeated */
2012-03-28 11:53:18 +00:00
for (sy = 0; sy + dy <= ibuf->y; sy += dy) {
for (sx = 0; sx + dx <= ibuf->x; sx += dx) {
UI_view2d_to_region_no_clip(&ar->v2d, fx + (float)sx / (float)ibuf->x, fy + (float)sy / (float)ibuf->y, &x, &y);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
glaDrawPixelsSafe(x, y, dx, dy, dx, GL_RGBA, GL_UNSIGNED_BYTE, rect);
}
}
glPixelZoom(1.0f, 1.0f);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
IMB_display_buffer_release(cache_handle);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
MEM_freeN(rect);
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
static void draw_image_buffer_repeated(const bContext *C, SpaceImage *sima, ARegion *ar, Scene *scene, Image *ima, ImBuf *ibuf, float zoomx, float zoomy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
2012-03-28 11:53:18 +00:00
const double time_current = PIL_check_seconds_timer();
2012-03-28 11:53:18 +00:00
const int xmax = ceil(ar->v2d.cur.xmax);
const int ymax = ceil(ar->v2d.cur.ymax);
const int xmin = floor(ar->v2d.cur.xmin);
const int ymin = floor(ar->v2d.cur.ymin);
int x;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
for (x = xmin; x < xmax; x++) {
int y;
2012-03-28 11:53:18 +00:00
for (y = ymin; y < ymax; y++) {
if (ima && (ima->tpageflag & IMA_TILES))
draw_image_buffer_tiled(sima, ar, scene, ima, ibuf, x, y, zoomx, zoomy);
else
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
draw_image_buffer(C, sima, ar, scene, ibuf, x, y, zoomx, zoomy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* only draw until running out of time */
if ((PIL_check_seconds_timer() - time_current) > 0.25)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
return;
}
}
}
/* draw uv edit */
/* draw grease pencil */
2014-03-31 23:39:08 +11:00
void draw_image_grease_pencil(bContext *C, bool onlyv2d)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
/* draw in View2D space? */
if (onlyv2d) {
/* draw grease-pencil ('image' strokes) */
draw_gpencil_2dimage(C);
}
else {
/* assume that UI_view2d_restore(C) has been called... */
2012-10-26 04:14:10 +00:00
//SpaceImage *sima = (SpaceImage *)CTX_wm_space_data(C);
/* draw grease-pencil ('screen' strokes) */
2012-03-28 11:53:18 +00:00
draw_gpencil_view2d(C, 0);
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
void draw_image_sample_line(SpaceImage *sima)
{
if (sima->sample_line_hist.flag & HISTO_FLAG_SAMPLELINE) {
Histogram *hist = &sima->sample_line_hist;
glBegin(GL_LINES);
glColor3ub(0, 0, 0);
glVertex2fv(hist->co[0]);
glVertex2fv(hist->co[1]);
glEnd();
setlinestyle(1);
glBegin(GL_LINES);
glColor3ub(255, 255, 255);
glVertex2fv(hist->co[0]);
glVertex2fv(hist->co[1]);
glEnd();
setlinestyle(0);
}
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* XXX becomes WM paint cursor */
#if 0
static void draw_image_view_tool(Scene *scene)
{
2012-03-28 11:53:18 +00:00
ToolSettings *settings = scene->toolsettings;
Brush *brush = settings->imapaint.brush;
int mval[2];
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
float radius;
2012-03-28 11:53:18 +00:00
int draw = 0;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (brush) {
if (settings->imapaint.flag & IMAGEPAINT_DRAWING) {
if (settings->imapaint.flag & IMAGEPAINT_DRAW_TOOL_DRAWING)
2012-03-28 11:53:18 +00:00
draw = 1;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
else if (settings->imapaint.flag & IMAGEPAINT_DRAW_TOOL)
2012-03-28 11:53:18 +00:00
draw = 1;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (draw) {
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
getmouseco_areawin(mval);
2012-05-05 00:58:22 +00:00
radius = BKE_brush_size_get(brush) * G.sima->zoom;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
fdrawXORcirc(mval[0], mval[1], radius);
if (brush->innerradius != 1.0) {
radius *= brush->innerradius;
fdrawXORcirc(mval[0], mval[1], radius);
}
}
}
}
#endif
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
static unsigned char *get_alpha_clone_image(const bContext *C, Scene *scene, int *width, int *height)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
Brush *brush = BKE_paint_brush(&scene->toolsettings->imapaint.paint);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
ImBuf *ibuf;
unsigned int size, alpha;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
unsigned char *display_buffer;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
unsigned char *rect, *cp;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
void *cache_handle;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (!brush || !brush->clone.image)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
return NULL;
ibuf = BKE_image_acquire_ibuf(brush->clone.image, NULL, NULL);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
if (!ibuf)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
return NULL;
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
display_buffer = IMB_display_buffer_acquire_ctx(C, ibuf, &cache_handle);
if (!display_buffer) {
BKE_image_release_ibuf(brush->clone.image, ibuf, NULL);
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
IMB_display_buffer_release(cache_handle);
return NULL;
}
rect = MEM_dupallocN(display_buffer);
IMB_display_buffer_release(cache_handle);
if (!rect) {
BKE_image_release_ibuf(brush->clone.image, ibuf, NULL);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
return NULL;
}
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
*width = ibuf->x;
*height = ibuf->y;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
2012-03-28 11:53:18 +00:00
size = (*width) * (*height);
alpha = (unsigned char)255 * brush->clone.alpha;
cp = rect;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
while (size-- > 0) {
2012-03-28 11:53:18 +00:00
cp[3] = alpha;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
cp += 4;
}
BKE_image_release_ibuf(brush->clone.image, ibuf, NULL);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
return rect;
}
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
static void draw_image_paint_helpers(const bContext *C, ARegion *ar, Scene *scene, float zoomx, float zoomy)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
Brush *brush;
int x, y, w, h;
unsigned char *clonerect;
brush = BKE_paint_brush(&scene->toolsettings->imapaint.paint);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (brush && (brush->imagepaint_tool == PAINT_TOOL_CLONE)) {
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* this is not very efficient, but glDrawPixels doesn't allow
* drawing with alpha */
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
clonerect = get_alpha_clone_image(C, scene, &w, &h);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (clonerect) {
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
UI_view2d_to_region_no_clip(&ar->v2d, brush->clone.offset[0], brush->clone.offset[1], &x, &y);
glPixelZoom(zoomx, zoomy);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glaDrawPixelsSafe(x, y, w, h, w, GL_RGBA, GL_UNSIGNED_BYTE, clonerect);
glDisable(GL_BLEND);
glPixelZoom(1.0, 1.0);
MEM_freeN(clonerect);
}
}
}
/* draw main image area */
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
void draw_image_main(const bContext *C, ARegion *ar)
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
{
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
SpaceImage *sima = CTX_wm_space_image(C);
Scene *scene = CTX_data_scene(C);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
Image *ima;
ImBuf *ibuf;
float zoomx, zoomy;
bool show_viewer, show_render, show_paint;
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
void *lock;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* XXX can we do this in refresh? */
#if 0
what_image(sima);
if (sima->image) {
ED_image_get_aspect(sima->image, &xuser_asp, &yuser_asp);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* UGLY hack? until now iusers worked fine... but for flipbook viewer we need this */
2012-03-28 11:53:18 +00:00
if (sima->image->type == IMA_TYPE_COMPOSITE) {
ImageUser *iuser = ntree_get_active_iuser(scene->nodetree);
if (iuser) {
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
BKE_image_user_calc_imanr(iuser, scene->r.cfra, 0);
2012-03-28 11:53:18 +00:00
sima->iuser = *iuser;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
}
/* and we check for spare */
2012-03-28 11:53:18 +00:00
ibuf = ED_space_image_buffer(sima);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
}
#endif
/* retrieve the image and information about it */
2012-03-28 11:53:18 +00:00
ima = ED_space_image(sima);
ED_space_image_get_zoom(sima, ar, &zoomx, &zoomy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
show_viewer = (ima && ima->source == IMA_SRC_VIEWER) != 0;
show_render = (show_viewer && ima->type == IMA_TYPE_R_RESULT) != 0;
show_paint = (ima && (sima->mode == SI_MODE_PAINT) && (show_viewer == false) && (show_render == false));
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (show_viewer) {
2013-01-15 07:56:50 +00:00
/* use locked draw for drawing viewer image buffer since the compositor
* is running in separated thread and compositor could free this buffers.
* other images are not modifying in such a way so they does not require
* lock (sergey)
*/
BLI_lock_thread(LOCK_DRAW_IMAGE);
}
ibuf = ED_space_image_acquire_buffer(sima, &lock);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* draw the image or grid */
2012-03-28 11:53:18 +00:00
if (ibuf == NULL)
ED_region_grid_draw(ar, zoomx, zoomy);
else if (sima->flag & SI_DRAW_TILE)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
draw_image_buffer_repeated(C, sima, ar, scene, ima, ibuf, zoomx, zoomy);
else if (ima && (ima->tpageflag & IMA_TILES))
draw_image_buffer_tiled(sima, ar, scene, ima, ibuf, 0.0f, 0.0, zoomx, zoomy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
else
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
draw_image_buffer(C, sima, ar, scene, ibuf, 0.0f, 0.0f, zoomx, zoomy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* paint helpers */
if (show_paint)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO 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!
2012-09-15 10:05:07 +00:00
draw_image_paint_helpers(C, ar, scene, zoomx, zoomy);
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
/* XXX integrate this code */
#if 0
if (ibuf) {
2012-03-28 11:53:18 +00:00
float xoffs = 0.0f, yoffs = 0.0f;
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
if (image_preview_active(sa, &xim, &yim)) {
2012-03-28 11:53:18 +00:00
xoffs = scene->r.disprect.xmin;
yoffs = scene->r.disprect.ymin;
glColor3ub(0, 0, 0);
calc_image_view(sima, 'f');
2.5: Space Image ported back Organized as follows: uvedit/ uv editing related code uvedit_draw.c: drawing code uvedit_ops.c: operators, just a few done uvedit_unwrap_ops.c: will be operators for unwrapping uvedit_paramatrizer.c: lscm/abf/stretch/pack space_image/ space_image.c: registration and common getter/setters image_draw.c: drawing code, mostly functional image_panels.c: panels, all commented out image_render.c: render callbacks, non functional image_ops.c: operators, only view navigation done image_header.c: header, menus mostly done but missing buttons Notes: * Header menus consist only of Operator and RNA buttons, if they are not implemented they're displayed grayed out. Ideally the full header could work like this, but std_libbuttons looks problematic. * Started using view2d code more than the old code, but for now it still does own view2d management due to some very specific requirements that the image window has. The drawing code however is more clear hopefully, it only uses view2d, and there is no switching between 'p' and 'f' view2d's anymore, it is always 'f'. * In order to make uvedit operators more independent I move some image space settings to scene toolsettings, and the current image and its buffer is in the context. Especially sync selection and select mode belonged there anyway as this cannot work correct with different spaces having different settings anyway. * Image paint is not back yet, did not want to put that together with uvedit because there's really no code sharing.. perhaps vertex paint, image paint and sculpt would be good to have in one module to share brush code, partial redraw, etc better.
2009-01-15 04:38:18 +00:00
myortho2(G.v2d->cur.xmin, G.v2d->cur.xmax, G.v2d->cur.ymin, G.v2d->cur.ymax);
glRectf(0.0f, 0.0f, 1.0f, 1.0f);
glLoadIdentity();
}
}
#endif
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
ED_space_image_release_buffer(sima, ibuf, lock);
if (show_viewer) {
BLI_unlock_thread(LOCK_DRAW_IMAGE);
}
/* render info */
if (ima && show_render)
draw_render_info(sima->iuser.scene, ima, ar, zoomx, zoomy);
}
void draw_image_cache(const bContext *C, ARegion *ar)
{
SpaceImage *sima = CTX_wm_space_image(C);
Scene *scene = CTX_data_scene(C);
Image *image = ED_space_image(sima);
float x, cfra = CFRA, sfra = SFRA, efra = EFRA, framelen = ar->winx / (efra - sfra + 1);
Mask *mask = NULL;
if (sima->mode == SI_MODE_MASK) {
mask = ED_space_image_get_mask(sima);
}
if (image == NULL && mask == NULL) {
return;
}
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
/* Draw cache background. */
ED_region_cache_draw_background(ar);
/* Draw cached segments. */
if (image != NULL && image->cache != NULL && ELEM(image->source, IMA_SRC_SEQUENCE, IMA_SRC_MOVIE)) {
int num_segments = 0;
int *points = NULL;
IMB_moviecache_get_cache_segments(image->cache, IMB_PROXY_NONE, 0, &num_segments, &points);
ED_region_cache_draw_cached_segments(ar, num_segments, points, sfra + sima->iuser.offset, efra + sima->iuser.offset);
}
glDisable(GL_BLEND);
/* Draw current frame. */
x = (cfra - sfra) / (efra - sfra + 1) * ar->winx;
UI_ThemeColor(TH_CFRAME);
glRecti(x, 0, x + ceilf(framelen), 8 * UI_DPI_FAC);
ED_region_cache_draw_curfra_label(cfra, x, 8.0f * UI_DPI_FAC);
if (mask != NULL) {
ED_mask_draw_frames(mask, ar, cfra, sfra, efra);
}
}