Closes https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4752
Add Python type hints into documentation, in places where example code
defines a function. That ended up being just
`src/doc/pythonbindings.rst`. I also updated `testsuite/runtest.py` and
the functions in `testsuite/docs-examples-python/src/docs-examples-*.py`.
While I was in `pythonbindings.rst`, I noticed a couple places with
`py::method` (note the double colon). These lines didn't render in the
docs, so I removed the extra colon to match other usage.
I locally built the docs to make sure html looks good. I ran the tests
with `ctest` and the tests ran, so I'm taking that as a sign that
`runtest.py` still works.
Signed-off-by: Connie Chang <connie.chang@dreamworks.com>
- The parameter 'pattern' now supports a special value 'auto', which is
also default.
- The parameter 'layout' now supports a special value 'auto', which is
also default.
- The parameter 'algorithm' now supports a special value 'auto', which
is also default.
- New parameter 'white_balance_mode.
- The raw input plugin now adds an attribute 'raw:WhiteBalance' in
addition to the libraw-specific 'raw:cam_mul', carrying the same values.
This changes the current behaviour, please read below.
Previously, the parameter 'pattern' defaulted to 'bayer'. The new default
value of 'auto' makes OIIO look for the input ImageBuf's attribute
'raw:FilterPattern', and deduct the pattern from its value. If the
attribute is missing, 'bayer' is assumed.
Previously, the parameter 'layout' defaulted to 'RGGB' for Bayer pattern,
or 'GRBGBR BGGRGG RGGBGG GBRGRB RGGBGG BGGRGG' for X-Trans. The new
default value of 'auto' makes OIIO look for the input ImageBuf's
attribute 'raw:FilterPattern', and deduct the layout from its value. If
the attribute is missing, the old default values are assumed.
Technically the 2 changes above the current behaviour may change, but
only in a very rare use case: when the user relies on the old default
values to decode the image, and there is metadata present in the
ImageBuf saying that the pattern and/or layout is different from the
default.
Previously, the parameter 'algorithm' defaulted to 'linear'. The new
default value 'auto' maps to 'MHC' for the Bayer pattern, and 'linear'
for the X-Trans.
The newly added parameter 'white_balance_mode' can have one of the
following three values:
- 'auto' (default) - the white-balancing weights are read from the input
ImageBuf's attribute 'raw:WhiteBalance', defaulting to (1, 1, 1, 1).
- 'manual' - the white-balancing weights are read from the parameter
'white_balance'.
- 'none' - same as 'manual' with the weights of (1, 1, 1, 1).
This changes the current behaviour where the white-balancing weights
from the parameter 'white_balance' get applied if present. Now, in
addition to providing them, you need to explicitly set
'white_balance_mode' to 'manual'.
I've updated the unit tests to cover the new 'auto' mode.
---------
Signed-off-by: Anton Dukhovnikov <antond@wetafx.co.nz>
Two PRs crossed paths in flight last week -- one adding the ARM tests,
the other doing something that changed the reference output of this test
slightly. Both passed on their own, but the combo left one platform's
output needing the update.
Also, edit nicknames of two tests, they were not unique.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
GHA offers free runners for Linux on ARM based machines. Let's throw
them into the testing mix!
A very small number of tests needed additional reference outputs saved,
due to a few LSB type errors in the math.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
ImageInput methods that read scanlines, tiles, and image are given new
flavors that take image_span, much like the changes of PR #4727 did for
ImageOutput.
Generally, for each, there are three versions: (1) a low-level virtual
method base case that takes an `image_span<byte>` that describes the
underlying memory, and an explicit TypeDesc that specifies the data type
conversion (including allowing TypeUnknown to indicate keeping channels
in their native per-channel format from the file); (2) a templated
version taking an `image_span<T>` that infers the data type conversion
from `T` (must be a single type for all channels); (3) a templated
version taking a `span<T>` that further implies a contiguous buffer in
all dimensions.
For now, the default implementations of these new ImageInput methods are
just wrappers that call the old pointer-based ones. One by one, over
time, we can swap them, changing the format implementations to have a
full implementation of the new bounded versions, and make their raw
pointer versions call the wrappers. The raw pointer ones will be
understood to be "unsafe", merely assuming that the pointers always
refer to appropriately-sized memory areas. Meanwhile, the ones using
spans and image_spans will, due to assertions in their implementations,
make it easier to verify (at least in debug mode), that we never touch
memory outside these bounds.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Implements IBA::scale, an algo which takes two images, one of which is
required to be a single channel image, each channel of the other image
gets multiplied by that single channel, per pixel.
Note that this is subtly different from IBA::mul(), which is a
channel-by-channel multiplication, and so doesn't have a provision for
allowing you to scale all channels of one image by the single channel of
a second image.
I have added tests for the C++ code, python code, oiiotool, and the
documentation examples
Signed-off-by: Anton Dukhovnikov <antond@wetafx.co.nz>
Replacing 3x IBA + Helper function that generate 4 fulls size image
buffers with single unsharp_mask_impl() that use parallel_image() to
compute unsharp:
src + contr * (((src - blur) < threshold) ? 0.0 : (src - blur))
Added two pass 1D convolution for a kernels higher than 3x3
## Tests
```
ImageBuf sharped(input.spec());
const int repeats = 50;
std::cout << "Start sharpening\n";
auto start = std::chrono::high_resolution_clock::now();
for (int i = 0; i < repeats; i++)
{
//ok = ImageBufAlgo::unsharp_mask(sharped, input, "gaussian", 15.0f, 10.0f, 0.01f);
ok = ImageBufAlgo::unsharp_mask(sharped, input, "gaussian", 5.0f, 2.0f, 0.05f);
std::cout << ".";
}
std::cout << "\n";
auto part1 = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> elapsed_part1 = part1 - start;
std::cout << "Elapsed time: " << elapsed_part1.count() << " s\n";
```
both single threaded (one IB at time) and multithreaded (multiply IB at
time) show pretty good speedup:
~30-40% with less memory use.
for 5x5 gaussian kernels two pass mode should add at least 20% speedup.
(if someone can do independent benchmark, will be great. As soon as I
had a big differences on them depend on real or synthetic use)
---------
Signed-off-by: Vlad (Kuzmin) Erium <libalias@gmail.com>
cumentation to testsuite conversion for cpp and python for the
ImageBufAlgo Chapter, Section: Image Arithmetic up to the div function.
The PR also fixes a python testing image file reference in
..docs-examples-python/ref/out.txt, where reference images "simple.tif"
and "scanlines.tif" should have the docs-examples-cpp prefix (see
..docs-examples-python/run.py line 11 for details).
---------
Signed-off-by: Lydia Zheng <lydiamzheng@gmail.com>
Convert C++ and Python examples from the "Image transformations and data
movement" section of the "imagebufalgo" chapter into tests within the
"docs-examples" testsuites (related to issue #3992).
Update 'oiiotool' tabs to use a simple 'tab' instead of 'code-tab' to
prevent synchronized tab selection, which is inconsistent with the other
tabs using the 'literalinclude' directive.
---------
Signed-off-by: Jeremy Retailleau <jeremy.retailleau@gmail.com>
These are build-breaking changes that impose a variety of new minimum
dependencies for the toolchain.
The new minimum Python version supported is now 3.7.
Get rid of 'from future' lines in python scripts in testsuite.
Remove python 2.7 specific ref images from testsuite.
Needless to say, this will not be backported to any release branches,
which guarantee that they will never raise the minimum supported
versions of any dependencies. This is just for future OIIO.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
We did `import OpenImageIO as oiio` then instead of using `oiio`, we
used `OpenImageIO`.
This was failing sometimes. Frankly, I'm not sure why it ever worked.
Maybe it works on some versions of Python but not others?
I dunno. But this fixes it everywhere and is clearly correct.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Takes the make_texture section of the imagebufalgo doc and turns it into
a unit test in both python and c++.
This adds a make_texture section to the `docs-examples-cpp` test and the
`docs-examples-python` test.
Signed-off-by: Danny Greenstein <danny.gr@gmail.com>
Convert C++ and Python examples from the "imagebufalgo" chapter into
tests within the "docs-examples" testsuites (#3992).
Signed-off-by: Jeremy Retailleau <jeremy.retailleau@gmail.com>
Slightly different set of issues, so I wanted to provide a full example
for anyone who wants to work on this chapter.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
I had previously prototyped an instance of this for the ImageOutput
chapter.
This patch makes empty placeholders for all of the other API chapters.
They don't contain any actual tests or generate any output now, but they
do build and run, so people can drop new examples into them without
having to worry about how to set up new files for each chapter.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
New theory of code examples in the docs: every one should live in the
testsuite somewhere, and merely be included by reference in the docs.
This ensures that every code example works, stays current with the
evolution of the APIs, and never breaks. It also beefs up our test cases
for more thorough code overage in the testsuite.
I've done this with just two examples here, but hopefully it serves as
an example for others to -- bit by bit -- convert all the other code
examples in the docs into tests in a similar manner.
Doing this for any one example is a perfect "good first issue," since
it's bite sized and can easily be done in a day, it doesn't require any
knowledge of deep OIIO internals, and in the process it also teaches you
something about how both the docs and the testsuite are set up.
A few notes:
* I'm structuring it (for now?) as two testsuite entry for each chapter
of the documentation (one for C++ and one for Python).
* Note how I can have many code snippets in a test source file, and use
the Sphinx `:start-after:` and `:end-before:` modifiers of
`literalinclude` to clip particular subsections of the file, using
special comment markers in the code.
While I was there, I also fixed some typos I noticed in the text of the
chapter, oops.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Marta Feriani