New LabVIEW tool: Embed/Extract data in PNG files

[BitPack Tools]

Hi everyone,

I just released a small LabVIEW tool that allows you to embed custom data into PNG files and extract it back. The image remains fully viewable while carrying hidden data. Optionally, the data can also be exported in XML format.

Included VIs:

• Encode VI – Appends data to a PNG file or exports to XML.

• Decode VI – Retrieves the embedded data from a PNG file, including XML if used.

Key Features:

• Preserve image appearance while storing hidden data.

• Optional XML export for structured data.

• Combine images and related data in a single portable file.

• Store hidden notes or annotations without affecting the image.

Possible Use Cases:

• Data + Image packaging for measurement results.

• Metadata storage (experiment details, settings, version info).

• Lightweight data transport.

• Scientific experiments or field work with images + sensor readings.

• Archiving visual and numerical data together.

• Secure sharing of proprietary information.

Dependencies:
The tool uses two VIs from the MGI Library (BSD 3-Clause License). For simplicity, these VIs are included directly in the repo.

You can check it out and download it here: https://github.com/BitPackTools/pixpack

Feedback and suggestions are welcome!

 

Edited yesterday at 11:43 AM by BitPack Tools

[ShaunR]

It doesn't seem to produce a valid png (either as XML or "not encoded").

I've changed the extension name of the produced file (.notaping) because the web interface will not allow uploading as a png.

PicPack_Embedded.notapng

[BitPack Tools]

Hi ShaunR,

Thanks a lot for checking it out and giving feedback! You were actually right — the issue came from LabVIEW’s “prepend array or string size” option in the Binary Write VI, which adds the array length (U32) at the start. That’s why the file didn’t start with a proper PNG signature.

I’ve fixed it, and now the decode VI also returns the image separately, so it should work nicely even in LabVIEW. Really appreciate you taking the time to try it!

Just a note: this isn’t a strictly valid PNG, since the extra data isn’t stored in chunks but appended after IEND. Still, image processing tools usually don’t mind, as they only read up to IEND.

[ShaunR]

OK. Now we're cooking with gas.

Some minor (and one major*) comments.

1. Data does not survive a copy operation.*
2. Error in (No error) shouldn't be required.
3. Add a document that states the licence conditions that you are distributing under (e.g. MIT, BSD, Creative Commons etc)
4. Use a Hex Encode and Decode you have written. Don't use the two MGI utilities.
5. Make your logo smaller. 

With regards #4.

You are only using two MGI utils to convert to and from hex chars. That can easily be done natively without requiring installation of a 3rd party toolkit. Using those two requires the end user add an additional copyright statement to their binary distribution that they may not be aware of (were you?). Save them (and yourself) the copyright issues.

Quote

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

If you are going to use 3rd party toolkit, require they install them as a dependency then you will not have copyright issues ... but you don't need it for this.

Edited 8 hours ago by ShaunR

[BitPack Tools]

Thanks again for taking the time to review and comment! 

• About the hex encode/decode: good point. Those two small functions originally came from the MGI Utilities, which are under the BSD-3-Clause license. I’ve copied them into the repo together with the license notice, so there is no hidden copyright issue and no need for users to install the full toolkit (as also noted on GitHub).

• The Error In terminal is intentionally required — that’s by design and will remain so.

• You also mentioned “Data does not survive a copy operation”. Could you clarify or give me an example? I’d like to reproduce that issue, since I haven’t encountered it myself.

Thanks again for helping improve this!

[ShaunR]

2 hours ago, BitPack Tools said:

so there is no hidden copyright issue

There is. If they create an executable they need to add the copyright to their documentation or distribution in some way as the licence is contained in the MGI VI's description.

2 hours ago, BitPack Tools said:

You also mentioned “Data does not survive a copy operation”. Could you clarify or give me an example? I’d like to reproduce that issue, since I haven’t encountered it myself.

Example_1.vi

[BitPack Tools]

I’ve added it, the license is now available on GitHub. I can’t open the VI you sent — I’m using LabVIEW 2020.

[BitPack Tools]

The password is the filename, meaning the filename carries the payload’s password. I am fully aware of the drawbacks of this approach. Users can just as easily forget the given password as they can rename the file—which is why it didn’t work for you, though you probably knew that 😃. The solution is freely modifiable, and if there is a real need, I can add an option for a custom password. 🙃