Picturizer
Picturizer takes any file and converts the raw data in it into a picture. The resulting picture is fairly useless beyond its amusement value.
| License:Boredom Software Freeware License | Language: Compiled Binary |
| Platform(s): Win32 (NT 5.0+) | |
| How To Open 7-Zip Files | |
Webmasters: Please Link To This Page, Not To The File Itself.
This is an example of Picturizer's output. The above image is an early build of Picturizer itself. Click the image for the full sized version (1.23MB)
Current Version
The most current version of Picturizer is 0.12 Beta (Last update: 1/11/11).
Changelog
- 0.11 - 0.12
- Reduced memory use by 33%
- Added option to force using the slow renderer
- Fixed integer overflow bug in the progressbar. Progress will now be accurately indicated for files up to 18.45 exabytes.
- 0.10 - 0.11
- Holy shitloads faster in exchange for ungodly increase in memory use.
- Added block counter for your counting pleasure
- 0.10
- First release
Files Included in the Download
- picturizer.exe - Program executable
- ReadMe.txt - ReadMe File
- License.txt - License
Installation
Picturizer does not require installation. Simply execute the picturizer.exe file to run it.
Issues
The resulting images are PNG files themselves so they are NOT bit-for-bit duplicates of the input files but rather a visual representation of the raw data. As such, please don't expect to reverse the process to get your file back and expect the size of the picture file to be close to, but not exactly, the size of the input. Bear that in mind before popping your terabyte-sized files in there mmkay?
Render times are very roughly 500KB per second for fast mode and 50KB per second for slow mode. Memory usage is 2x + 8MB the size of the input data for fast mode and 1x + 8MB for slow mode. Picturizer will fail if your computer doesn't have enough memory for the file being rendered even in slow mode.
Also, since the picture produced is a perfect square (same number of pixels down as across) Picturizer will truncate or pad the input data as necessary to fit into the picture's dimensions. There's something wrong with my math somewhere as it seems that files are being padded too much resulting in extra padding (black) blocks at the end of the image.
Each pixel in the output represents three bytes from the input converted to a (RGB) color which I call color blocks :)
Write a comment
Posts: 1
Reply #1 on : Wed December 14, 2011, 15:48:56