griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
1f44a7494707747140840c94de0dbda74bd79b61
test/source/blender/imbuf/intern/interp.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

28 lines
729 B
C++
Raw Normal View History

ImBuf: Refactor pixel interpolation functions There exist a bunch of "give me a (filtered) image pixel at this location" functions, some with duplicated functionality, some with almost the same but not quite, some that look similar but behave slightly differently, etc. Some of them were in BLI, some were in ImBuf. This commit tries to improve the situation by: * Adding low level interpolation functions to `BLI_math_interp.hh` - With documentation on their behavior, - And with more unit tests. * At `ImBuf` level, there are only convenience inline wrappers to the above BLI functions (split off into a separate header `IMB_interp.hh`). However, since these wrappers are inline, some things get a tiny bit faster as a side effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X): - Nearest filter: 2.33 -> 1.94ms - Bilinear filter: 5.83 -> 5.69ms - Subsampled3x3 filter: 28.6 -> 22.4ms Details on the functions: - All of them have `_byte` and `_fl` suffixes. - They exist in 4-channel byte (uchar4) and float (float4), as well as explicitly passed amount of channels for other float images. - New functions in BLI `blender::math` namespace: - `interpolate_nearest` - `interpolate_bilinear` - `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function, this one no longer requires the caller to do their own wrapping. - `interpolate_cubic_bspline`. Previous similar function was called just "bicubic" which could mean many different things. - Same functions exist in `IMB_interp.hh`, they are just convenience that takes ImBuf and uses data pointer, width, height from that. Other bits: - Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf` and `floored_modulo` that exist elsewhere), made it branchless and added more unit tests. - `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead, moved the clamp to be outside of the call in `paint_image_proj.cc` and `paint_utils.cc`. Though the need for clamping in there is also questionable. Pull Request: https://projects.blender.org/blender/blender/pulls/117387
2024-01-25 11:45:24 +01:00
/* SPDX-FileCopyrightText: 2024 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
/** \file
* \ingroup imbuf
*/
#include "BLI_math_vector.h"
#include "IMB_colormanagement.hh"
#include "IMB_interp.hh"
void IMB_sampleImageAtLocation(ImBuf *ibuf, float x, float y, bool make_linear_rgb, float color[4])
{
using namespace blender;
if (ibuf->float_buffer.data) {
BLI: Add nearest interpolation with clamped boundary This patch adds clamped boundaries variants of the nearest interpolation functions in the BLI module. The naming convention used by the bilinear functions were followed. Needed by #119414. Pull Request: https://projects.blender.org/blender/blender/pulls/119732
2024-03-21 13:22:10 +01:00
imbuf::interpolate_nearest_border_fl(ibuf, color, x, y);
ImBuf: Refactor pixel interpolation functions There exist a bunch of "give me a (filtered) image pixel at this location" functions, some with duplicated functionality, some with almost the same but not quite, some that look similar but behave slightly differently, etc. Some of them were in BLI, some were in ImBuf. This commit tries to improve the situation by: * Adding low level interpolation functions to `BLI_math_interp.hh` - With documentation on their behavior, - And with more unit tests. * At `ImBuf` level, there are only convenience inline wrappers to the above BLI functions (split off into a separate header `IMB_interp.hh`). However, since these wrappers are inline, some things get a tiny bit faster as a side effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X): - Nearest filter: 2.33 -> 1.94ms - Bilinear filter: 5.83 -> 5.69ms - Subsampled3x3 filter: 28.6 -> 22.4ms Details on the functions: - All of them have `_byte` and `_fl` suffixes. - They exist in 4-channel byte (uchar4) and float (float4), as well as explicitly passed amount of channels for other float images. - New functions in BLI `blender::math` namespace: - `interpolate_nearest` - `interpolate_bilinear` - `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function, this one no longer requires the caller to do their own wrapping. - `interpolate_cubic_bspline`. Previous similar function was called just "bicubic" which could mean many different things. - Same functions exist in `IMB_interp.hh`, they are just convenience that takes ImBuf and uses data pointer, width, height from that. Other bits: - Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf` and `floored_modulo` that exist elsewhere), made it branchless and added more unit tests. - `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead, moved the clamp to be outside of the call in `paint_image_proj.cc` and `paint_utils.cc`. Though the need for clamping in there is also questionable. Pull Request: https://projects.blender.org/blender/blender/pulls/117387
2024-01-25 11:45:24 +01:00
}
else {
BLI: Add nearest interpolation with clamped boundary This patch adds clamped boundaries variants of the nearest interpolation functions in the BLI module. The naming convention used by the bilinear functions were followed. Needed by #119414. Pull Request: https://projects.blender.org/blender/blender/pulls/119732
2024-03-21 13:22:10 +01:00
uchar4 byte_color = imbuf::interpolate_nearest_border_byte(ibuf, x, y);
ImBuf: Refactor pixel interpolation functions There exist a bunch of "give me a (filtered) image pixel at this location" functions, some with duplicated functionality, some with almost the same but not quite, some that look similar but behave slightly differently, etc. Some of them were in BLI, some were in ImBuf. This commit tries to improve the situation by: * Adding low level interpolation functions to `BLI_math_interp.hh` - With documentation on their behavior, - And with more unit tests. * At `ImBuf` level, there are only convenience inline wrappers to the above BLI functions (split off into a separate header `IMB_interp.hh`). However, since these wrappers are inline, some things get a tiny bit faster as a side effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X): - Nearest filter: 2.33 -> 1.94ms - Bilinear filter: 5.83 -> 5.69ms - Subsampled3x3 filter: 28.6 -> 22.4ms Details on the functions: - All of them have `_byte` and `_fl` suffixes. - They exist in 4-channel byte (uchar4) and float (float4), as well as explicitly passed amount of channels for other float images. - New functions in BLI `blender::math` namespace: - `interpolate_nearest` - `interpolate_bilinear` - `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function, this one no longer requires the caller to do their own wrapping. - `interpolate_cubic_bspline`. Previous similar function was called just "bicubic" which could mean many different things. - Same functions exist in `IMB_interp.hh`, they are just convenience that takes ImBuf and uses data pointer, width, height from that. Other bits: - Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf` and `floored_modulo` that exist elsewhere), made it branchless and added more unit tests. - `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead, moved the clamp to be outside of the call in `paint_image_proj.cc` and `paint_utils.cc`. Though the need for clamping in there is also questionable. Pull Request: https://projects.blender.org/blender/blender/pulls/117387
2024-01-25 11:45:24 +01:00
rgba_uchar_to_float(color, byte_color);
if (make_linear_rgb) {
IMB_colormanagement_colorspace_to_scene_linear_v4(
color, false, ibuf->byte_buffer.colorspace);
}
}
}
Reference in New Issue Copy Permalink