I built Drive Imager around four output formats: E01, Ex01, AFF4, and raw DD. I have my native Go imager written from the ground up which handles E01, Ex01, and AFF4 but you can also choose a different imaging engine if you prefer. You can choose from the native imager written in Go, the tried and true ewfacquire, or raw unix dd.
One of the benefits of the native Go imager is that specifically for E01 and AFF4, a single source drive can spill-over to multiple destination drives. For example, one 8 TB source drive can image to four 2 TB drives. The native go Imager can also embed SHA-256 and Blake hashes into the E01 files so you don't need a sidecar for tracking modern hashes.
E01 is the compatibility choice and default. It is broadly accepted by forensic tools, it compresses, and it splits the image into numbered segments that are easier to move between storage systems. E01 also carries the case name, evidence number, examiner, and description inside the image, so those details travel with the segments.
Ex01 is the newer EnCase v2 (EWF2) format. By combining the public information about EWF2 with analysis of known-good images, I was able to build that capability into my native Go imaging engine. It supports compression and segmenting like E01. With Full acquisition hashing selected, both native formats record MD5, SHA-1, SHA-256, and BLAKE3 while the source is read. Ex01 can handle larger drives than E01 formats.
AFF4 is the open-container choice. It can be one unsplit file or a set of configured-size segments, and those segments can be distributed across multiple destination drives. A less common format but open source and modern.
Raw DD leaves the container out completely. The output is an uncompressed bit-for-bit image, so tools that understand raw disk images can read it without unpacking EWF or AFF4. The trade-off is size and context: the DD file itself carries no case metadata, and it does not use the compression or container-segmentation controls.