Image Steganography Project Report and Documentation Guide

What an image steganography project report should establish

An image steganography project report should document a verifiable path from a cover image to an embedded message and back again. Steganography is the practice of hiding the existence of a message by placing it inside ordinary-looking carrier data, such as a digital image. This is distinct from encryption, which makes a message unreadable but does not hide that communication is occurring, and distinct from watermarking, which is primarily concerned with marking ownership or provenance rather than concealing communication. The report needs to explain which parts of the image are modified, why those modifications are difficult to notice, how a receiver can recover the payload, and what limits exist under real image transformations or statistical inspection.

Core components of the documentation

A complete project document normally separates the report from the project documentation. The report presents the objective, method, implementation, tests and results. The project documentation focuses on repeatable use: setup, API or command interface, input requirements, output expectations and limitations. Combining them is practical for small projects, but the distinction helps a reader distinguish conceptual explanation from operating instructions.

Problem statement and scope boundary

The opening section should define what the project attempts and what it deliberately excludes. A focused project might cover spatial-domain least significant bit embedding in PNG and BMP files only, while explicitly excluding JPEG, palette transparency behavior, encryption or watermarking. Stating the scope prevents a reviewer from expecting properties the method was never designed to provide.

Embedding and extraction pipeline

The report should show one end-to-end path. The typical stages are: read the cover image into a suitable pixel representation, prepare the payload with any needed length header, embed the bits into selected carrier elements, write a valid output image, then read that output and perform the inverse operation to recover the payload. Each stage must specify how the receiver learns the payload length and the choice of carrier pixels or coefficients.

Least significant bit substitution

LSB substitution is the standard introductory method because the operation is simple to describe. Each pixel is represented by numeric channel values, typically red, green and blue integers. The least significant bit of a channel contributes the smallest visible change, so replacing it with one payload bit alters the channel by at most one unit. The extraction step reads only the agreed least significant bit from each selected channel and reassembles those bits into bytes.

Example of a simplified 8-bit embedding rule:

cover_byte = 0b10010110
payload_bit = 1
stego_byte = (cover_byte & 0b11111110) | payload_bit
# Result: 0b10010111

A project should state the selection order precisely. Embedding sequentially from the top-left pixel without a key makes extraction deterministic but also makes the method easy for an informed observer to invert. A keyed pseudo-random ordering makes casual extraction harder but introduces requirements for key agreement and reproducible selection.

Image format constraints

Image format choice is a condition of the method, not an implementation detail. Lossless formats such as PNG and BMP preserve the written pixel values, so the receiver can read back exactly the bits that were embedded. Lossy formats such as JPEG compress the image with quantization and rounding; payload placed in spatial-domain pixel values will not survive that compression. JPEG steganography instead requires methods that operate on transform coefficients, and the report must say which coefficient embedding rule is used and why it survives the format pipeline.

Palette images introduce another constraint. A palette maps a small indexed value to a full color. Changing the least significant bit of an index can move to a visually distant color, but changing a rarely used palette entry affects every pixel that shares that index. Documentation should explain whether the method treats the palette as fixed, embeds in palette entries, or limits itself to truecolor images.

Alpha channels must also be considered. Transparent or semi-transparent pixels can lose their color contribution when composited, and image viewers may normalize invisible color values. If the method embeds in channels that a renderer discards, the payload may not survive ordinary display or re-encoding.

Payload framing and extraction metadata

Hidden data is a sequence of bits, but extraction must know where those bits end. A common design reserves an initial header for the byte length of the message, embeds the header first, then embeds the message bytes. The receiver reads the header, calculates how many carrier elements the message requires, and recovers only that many bits. Without a length field, the extractor will return either a fixed maximum block or meaningless trailing bits.

The report should document the byte order, bit order and character encoding of the recovered payload. Reconstructing bytes from individual bits is order-sensitive, and a textual payload interpreted with the wrong encoding becomes unreadable even when the bit extraction is correct.

Capacity

Payload capacity is method-specific. In a truecolor BMP image with no metadata overhead, embedding one payload bit per channel provides roughly three bits per pixel, or about 0.375 bytes per pixel. Embedding in only the red channel provides about one bit per pixel. These are upper bounds for the carrier elements actually selected; any length header, parity data or error-correction overhead reduces the space available for the message.

Capacity cannot be stated as a universal property of image steganography. The practical carrying limit also depends on how much visible distortion remains acceptable and whether the image will later be compressed, cropped, resampled or re-saved.

Visual distortion

LSB substitution is generally perceptually subtle because the numeric change is small. However, the visible impact is not zero across every image and payload volume. Smooth areas with little texture can expose a subtle change more readily than busy areas, and embedding at high capacity may create faint banding or noise. A documentation section can include side-by-side crops of the original and stego image and, where available, a per-pixel difference map that shows exactly which locations were modified without prematurely emphasizing the hidden bits themselves.

Steganalysis limitations

Steganalysis is the attempt to detect the presence of hidden data, recover its length, or extract it. A claim like "undetectable" is not supportable as a general statement; detectability depends on the method, the embedding rate, the cover source and the specific steganalysis check applied. Simple sequential LSB replacement distorts statistical relationships in natural images in ways that some detectors can expose, especially at high payload rates or when the replacement pattern is regular.

A credible report states what was tested and what was not. If the project evaluated only visual quality, the documentation should say that statistical detection was not assessed. If it tested against a particular detector or compared a baseline image with an embedded image at a specified payload size, the report should describe the test conditions and the measured result without generalizing to all steganalysis.

Resistance to transformations

Robustness is not a default property of image steganography. LSB embedding in spatial samples is fragile: cropping, resizing, rotation, conversion to another format, compression or even a lossy re-save can destroy the payload. A document that reports successful extraction on the untouched output image has not demonstrated robustness. If robustness is a stated goal, the method must be designed around transformations, and the report must specify which transformations were tested and whether the recovered payload was bit-exact or only partially correct.

Implementation documentation

The implementation section should identify the language, libraries, image-reading path and exact embedding locations. Reproducible documentation does not need to narrate every line, but it should enable another person to run the same operation and get the same output for a fixed cover image, payload and key.

Acceptance and verification

Verification should address several separate questions. The stego image must be a valid image file that opens in an image viewer or library. The recovered payload must match the original payload byte for byte, including the header interpretation. The stego image should not be saved through an intermediate lossy step that silently changes the embedded values. If a source image is reused in a report, the documentation should clarify whether the displayed image is the exact carrier or a resized or compressed representation.

Common gaps to flag

• No length header or termination rule, leaving the extractor dependent on an implicit fixed size.
• No stated bit order, channel order or byte order.
• No statement of image format compatibility, especially for lossy formats.
• No distinction between encryption keys, concealment keys and ordinary image metadata fields.
• No distinction between hiding a message and marking an image with a watermark.
• No test of extraction after re-saving or transformation when robustness is implied.
• A general claim of undetectability without evidence or qualified scope.

Suggested report structure

• Problem statement and scope, including what is excluded.
• Background that defines steganography, cover, stego image, payload, and the difference from encryption and watermarking.
• Method description with election order, bit placement, header design and image format assumptions.
• Implementation notes including language, libraries and reproducible command or interface steps.
• Tests with exact cover, payload, key and environment, plus extraction and error results.
• Limitations covering capacity, visual distortion, detection risk and transformation fragility.
• Conclusion that restates what has been demonstrated, not absolute claims.

Suggested supporting tables and examples

Component || What the report should record

Cover image || Resolution, number of channels, bit depth, palette use, format

Payload || Byte length before bit framing, character encoding, whether treated as text or bytes

Embedding rule || Channel order, bit position, sequential or keyed selection

Length framing || How extractor knows the bit count or byte count

Output image || Format, validity check, file size, visual inspection result

Extraction || Input assumptions, recovered bytes, comparison with original payload

Reported capacity || Bits or bytes per carrier element plus framing overhead

Writing the conclusion without unsupported guarantees

The conclusion should claim only what the project implemented and measured. A safe summary states the method, the image formats in which extraction was demonstrated, the capacity rule used, and the conditions under which extraction failed or was not tested. This keeps the report technically honest while still giving the reader enough detail to reproduce, criticize or extend the work.