James Harkins

Context is alpha masking: rgb2luma, then increase the brightness.

Only you can't use brcosa to increase brightness of a grayscale matrix.

Except... jit.op seemingly can't do this? As far as I can see, the @val gets clipped to 0 to 255, then for purposes of multiplication, taken as "val / 256." and then this factor is the operand.

I had really not wanted to get into jit.gen right away with a class of complete beginners with Jitter, but... is that basically it? I guess I could push it into a float32 matrix, do the op, and cast back to char, but that's two extra jit.matrix storage blocks, which seems redundant to me. I'm guessing jit.gen is faster and memory-lighter...?

Context is alpha masking: rgb2luma, then increase the brightness.

Only you can't use brcosa to increase brightness of a grayscale...

best-way-to-increase-gain-of-a-char-image

yes to unclamp the operator you must use float32 types

I guess I'll assume, then, that jit.gen is more efficient than converting the matrix, doing jit.op, and then reconverting... not sure how to benchmark that since [timer] measures logical time, not elapsed.

here is a benchmark example. Obviously, it takes (much) more time to do char-to-float32 conversion then  "*" operation then float32-char operation  than just a "*"

Well, while thinking about it, this is purely for educationnal purpose. I believe jit.gen works in float32 internally anyway, so there is no need to do these extra char-to-float-to-char conversion anyway.

EDIT: added a 3rd example. If you really don't want to use jit.gen, you could use [jit.op @type float32 @op *] which will let you multiply by a float value while still outputing a char matrix. Seems equivalent to the jit.gen solution in terms of performance.

Yes, of course. If I'm understanding it right, jit.gen will do one iteration over the matrix, applying the operations inside to every pixel, while converting the type is one iteration, performing the operation is another iteration, and re-converting is a third iteration. I'd certainly expect the extra conversions to be quite a bit slower, especially for large matrices.

Ah, I'd overlooked the @type attribute. But it looks to me like @val is still clamped to 0.0 - 1.0. Two screenshots: the first one is using jit.gen, the second, jit.op. 2nd pwindow is the alpha mask. The jit.gen version's right-hand operand = 8; jit.op, I set it from a dial+scale and it should be somewhere around 14 or 15, but the output is much darker than the jit.gen result (relative to the original luma values).

For this purpose, it's OK if the post-multiplication alpha values are clamped -- but necessary that the operand not be clamped. This appears to be impossible if the matrix going into jit.op is char. Here, I can understand from a design perspective why that would be. From a user perspective, however, it makes a really basic operation like "grayscale brightness" difficult enough that I couldn't do it without posting to the forum.

Ah you're right, I didn't noticed that [jit.op @type float32 @op *] whas clamping its @val!

Anyway, if your goal is to perform further realtime operation with these images, I would suggest to use jit.gl objects instead and stay with float32.

Best way to increase gain of a char image?