Page MenuHome

Py_imbuf add image manipulation functions
AbandonedPublic

Authored by Richard Antalik (ISS) on Jul 15 2018, 10:59 PM.

Details

Summary

manifest: T54272
I am not familiar with imbuf API, so hopefully it will be useful.

As I am here i want to ask a few things:
Would it be ok to move/merge (some) sequencer effects to imbuf, since these are in fact image effects?

for transformation I used code from bke/seqeffects.c
I would merge imbuf/rotate.c and imbuf/scaling.c to imbuf/transform.c but then there will be multiple functions for scaling...

for direct pixel access:
I read somewhere, that there is a concern about processing speed (realtime use case). Have you considered some other interface than buffer? Maybe if we implement smarter interface in C it will be easier to use and may reduce python code overhead. Or am I thinking too far ahead?

Diff Detail

Event Timeline

source/blender/imbuf/intern/rotate.c
128

I used this function from VSE, because I am most familiar with VSE code.
But imbuf module has more similar functions it seems.

199

This is probably stupid...

source/blender/python/generic/imbuf_py_api.c
164

Or should I rather use tuples for x/y coords?

source/blender/python/generic/imbuf_py_api.c
164

yes, (x, y) should be a pair. other functions too.

source/blender/imbuf/intern/divers.c
1043–1067

Why not invert in-place?

source/blender/imbuf/intern/divers.c
995

Why add a float buffer when color transformations run?

The developer should do this themselves if they need it.

source/blender/imbuf/intern/rotate.c
36

Can use <math.h> for standard defines.

Richard Antalik (ISS) marked 7 inline comments as done.Aug 13 2018, 9:08 PM

should I mark inlines as done and then update diff?

source/blender/imbuf/intern/rotate.c
36
// Define _USE_MATH_DEFINES before including <math.h> to expose these macro
// definitions for common math constants.  These are placed under an #ifdef
// since these commonly-defined names are not part of the C or C++ standards

I did this, but I cannot test with other compilers than MSVC

source/blender/python/generic/imbuf_py_api.c
237

This may be interpreted as translation point, so I could use tuple, but to me it is more like "how much"

Richard Antalik (ISS) marked an inline comment as done.

I found some quite stupid mistakes - sorry for that

I tested modified invert and contrast functions, and found out that I tested rectf conversion wrong way.
But even now it doesn't work.
I tested rect vs rectf output of IMB_saturation (I did not wrote this one), and there is subtle difference. In IMB_brightness also.

I assumed, that rectf will contain values 0-1
by looking at function

void rgb_uchar_to_float(float r_col[3], const unsigned char col_ub[3])
{
	r_col[0] = ((float)col_ub[0]) * (1.0f / 255.0f);
	r_col[1] = ((float)col_ub[1]) * (1.0f / 255.0f);
	r_col[2] = ((float)col_ub[2]) * (1.0f / 255.0f);
}

is there any set range for rectf? or should I use conversion?

Thanks.

source/blender/imbuf/intern/divers.c
1042–1057

rectf branch produces incorrect result after conversion to uchar and processing it same way as uchar.

I am confused...

diff obsolete