Optimise Steganography API

[ShaunR]

Hi all.

A bit of nerdy fun if you can spare some brain cycles.

I've written a Steganography API (0.9.0) and will be putting it on my site under a BSD-3 licence. It currently only uses the LSB method but I may do others if there is interest.

I've optimised it as much as I can but I expect that better people than I can improve it's performance. So. The task is to make it as fast as possible.

There is a benchmark with some images included so we can do comparative benchmarks. I'm looking forward to some innovative improvements. The winner gets a mention in the readme under SALUTATIONS.

If you can find the time and/or inclination then please post your times for the vanilla installation and then after any improvements as shown below.

Times to beat so far:

LabVIEW 2009 x64, Win10

Before Modification:
Encode: 297.9 ms
Decode: 98.1 ms

After Modification:
Encode: 297.9 ms
Decode: 98.1 ms

Oh yes. And finally. If you find any bugs, let me know and I'll fix them.

[Neil Pate]

Love the choice of embedded image 🙂

[ShaunR]

17 hours ago, Neil Pate said:

Love the choice of embedded image 🙂

The llama is cuter

[Neil Pate]

but not quite as punny... or am I just not smart enough to get that one?

[ShaunR]

27 minutes ago, Neil Pate said:

but not quite as punny... or am I just not smart enough to get that one?

Nah. It was just an icon I generated for an Ollama client.

 

[ShaunR]

Nothing? No improvements. No bugs? 

Not even the superfluous length parameter or the example images in the wrong location?

I'll give it one more week then release the version 1.0.0

[Neil Pate]

You might have more success posting this on the Discord. Most of the conversations happen there these days.

[ShaunR]

2 hours ago, Neil Pate said:

You might have more success posting this on the Discord. Most of the conversations happen there these days.

I don't do Discord. I don't even do Ni.com.

Feedback isn't really necessary. I only knocked it up because I went down a rabbit hole and wasn't impressed with the existing LabVIEW solutions. I thought I'd throw it in here to see if someone could improve it. My solution is optimised but there may have been a better alternative solution or maybe someone had a nice JPEG one (LSB doesn't survive JPEG compression).

You might get a mention in the readme just for responding  

[Mads]

I had a brief look at the code when you first posted it and thought perhaps it could benefit by working more on U8 arrays directly instead of the boolean arrays, but sticking to U8 all the way would not be practical either, so after some minor test runs I left that trail...

PS: One thing I did find was that the imgs folder is placed incorrectly in relation to the Example, making the default path to image incorrect. 🕵️‍♂️ 

The benchmark code, if it is going to be included in the release, might also look more logical if it was timing the individual steganography sub-components but with the contribution from other functions currently so small (relative to the current encode/decode functions at least) it has not much to say in practice.

[ShaunR]

14 hours ago, Mads said:

I had a brief look at the code when you first posted it and thought perhaps it could benefit by working more on U8 arrays directly instead of the boolean arrays, but sticking to U8 all the way would not be practical either, so after some minor test runs I left that trail

You can get some of the way like that but there are a couple of bits per byte that have to be concatenated. So at some stage you have to convert to bits. The speed of the encoding for-loops with shift was a surprise to me though.

14 hours ago, Mads said:

imgs folder is placed incorrectly in relation to the Example, making the default path to image incorrect

Yup.

On 11/12/2025 at 9:35 AM, ShaunR said:

Not even the superfluous length parameter or the example images in the wrong location?

 

14 hours ago, Mads said:

The benchmark code, if it is going to be included in the release, might also look more logical if it was timing the individual steganography sub-components but with the contribution from other functions currently so small (relative to the current encode/decode functions at least) it has not much to say in practice.

It was purely for relative performances and will not be included in the release proper. For this sort of thing I would rather deal with relative performance (removes differences between systems that they are bench-marked on). The in-built Performance>Profile Performance and Memory is better for identifying which individual components contribute what; so I would use that if someone found a better solution.