By carefully choosing the right 1s and 0s to burn to a CD, it is possible to burn visible images on normal CD-Rs. These images rely on the fact that the 1s and 0s created by pits in the CDs surface reflect light differently.
Remove these ads by
Signing UpStep 1: Learn how CDs and CD-Rs work
Data on a CD, or any optical media, is stored as a sequence of pits of varying lengths. To be precise, a 1 is represented by the change from pit to no-pit or the change from no-pit to pit, and a 0 is represented by no change in height (pit to pit or no-pit to no-pit). The pits and no-pits reflect different amounts of light; thus it is possible to draw images on CDs by appropriately arranging these 1s and 0s.
How do you arrange the 1s and 0s? It helps to know that the data is written along a spiral that starts from the center of the CD and spirals outward in a clockwise direction. The length of each bit is a fairly precise value (more on this later), and the pitch of the spiral, or the distance between successive spirals, is also a fairly precise value. Thus, using some math and some guesswork, it is possible to create a mapping from the nth bit in your data to an x,y coordinate.
Now we really have to look under the hood of CD data storage to figure out how to tell the CD writer to write a 0 or 1 for the nth bit. Data is organized as a sequence of sectors, each of which is 2352 bytes long. The data within each sector is organized in a particular way depending on what type of CD your are dealing with (data, audio, etc...). The most "raw" type of organization is known as "mode 2." Mode 2 does away with many of the nice things about CDs like error correction, but it gives us the most control over the bits. In a mode 2 sector, the first 12 bytes contain "syncing" data and the next 4 contain specific information about the sector. These bytes cannot be changed at the software level. (Maybe it is possible to write a driver that could change these?) The next 2336 bytes are free to be anything though. If this were all that happened to the data, our job would be easy. Unfortunately, there's a lot more data manipulation before the data actually gets written to the CD.
First, the data in each sector is "scrambled" by which we mean it is run through some math function which is supposed to "whiten" the data (i.e. keep the average height of the data on the CD half-way between pit and no-pit).
Second, the data is sent through a CIRC encoder, which applies some error correction codes.
Finally, the data is sent though an eight-to-fourteen modulator (EFM). This maps each 8-bit byte to a 14-bit sequence. This is to prevent long sequences of 0's (no change in height) which are hard for the CD drive to read.
The point is: drawing pictures on CDs is possible, so it should be done.
For a more complete (but still at some times cryptic) explanation of CDs, check out the freely available ECMA-130 specification.
How do you arrange the 1s and 0s? It helps to know that the data is written along a spiral that starts from the center of the CD and spirals outward in a clockwise direction. The length of each bit is a fairly precise value (more on this later), and the pitch of the spiral, or the distance between successive spirals, is also a fairly precise value. Thus, using some math and some guesswork, it is possible to create a mapping from the nth bit in your data to an x,y coordinate.
Now we really have to look under the hood of CD data storage to figure out how to tell the CD writer to write a 0 or 1 for the nth bit. Data is organized as a sequence of sectors, each of which is 2352 bytes long. The data within each sector is organized in a particular way depending on what type of CD your are dealing with (data, audio, etc...). The most "raw" type of organization is known as "mode 2." Mode 2 does away with many of the nice things about CDs like error correction, but it gives us the most control over the bits. In a mode 2 sector, the first 12 bytes contain "syncing" data and the next 4 contain specific information about the sector. These bytes cannot be changed at the software level. (Maybe it is possible to write a driver that could change these?) The next 2336 bytes are free to be anything though. If this were all that happened to the data, our job would be easy. Unfortunately, there's a lot more data manipulation before the data actually gets written to the CD.
First, the data in each sector is "scrambled" by which we mean it is run through some math function which is supposed to "whiten" the data (i.e. keep the average height of the data on the CD half-way between pit and no-pit).
Second, the data is sent through a CIRC encoder, which applies some error correction codes.
Finally, the data is sent though an eight-to-fourteen modulator (EFM). This maps each 8-bit byte to a 14-bit sequence. This is to prevent long sequences of 0's (no change in height) which are hard for the CD drive to read.
The point is: drawing pictures on CDs is possible, so it should be done.
For a more complete (but still at some times cryptic) explanation of CDs, check out the freely available ECMA-130 specification.
Visit Our Store »
Go Pro Today »
if FF is white, 00 is black, and 01 means to go to the next line,
FF00FF0100FF00010000000100FF00
represents a small image of the letter A. This only indicates lines of black and white, so what you see here is already being used by the program.
P.S. That string of numbers works as follows:
FF00FF0100FF00010000000100FF00
which becomes this when splitting bytes apart with spaces:
FF 00 FF 01 00 FF 00 01 00 00 00 01 00 FF 00
then, converting 01 to a new line, 00 to #, and FF to a space:
and you should be able to read the letter in that.
octave:1> img2cd('logo.gif')
n128sec = 1
error: invalid row index = 83
error: invalid column index = 142
error: evaluating binary operator `<' near line 176, column 25
error: if: error evaluating conditional expression
error: evaluating if command near line 176, column 5
error: evaluating for command near line 174, column 3
error: evaluating for command near line 156, column 1
error: called from `img2cd' in file `/home/pabs/img2cd.m'
Any idea how to fix this?
octave:1> img = imread('sohv.jpg')
octave:2> img2cd(img)
Regards
JB
Talking about a C/C++ ver, this code is easy to read and understand to a c++ programer(noob or pro!). It would be easy to convert it.(open in free SCITE to read it first!)
C++ Code simplified (I am a noob at C!)
< Start >
/* Simple C++ code convertion for matlab code */
/*
This is the base of the C code you would need. You would have to xor the data. Note: Looked for C++ BITXOR/XOR function but could not find any!
"this sequence of bytes is xored with the bytes of sector to "scramble" the data" --matlab code
Then setup the calabration for the type or brand of CD used. Get the center radius and other things. The comments were not clear in the program!
There was picture adjustment code to make the picture as it was on the computer screen.
"i came up with these fudge factors to attempt to straighten my picture. they work OK for my CD-Rs.they probably won't work for yours" --matlab code
Then write the image to 1/0 bits as a file. The matlab code tried to write at 128 sectors( A second?)
>>>>> NOTE: Most of the code in the MATLAB is math! The C++ code would be much better to read and less lines! <<<<<
*/
#include <stdio.h>
int main ()
{
FILE * CDfile;
/* First lines of the MATLAB code I can't get about the Xor :( */
char code[] = { The Code };
/* State the variable || (Below) open the file on the CD to be writen to. */
CDfile = fopen ( "f:/temp/CDHOLOGRAM.data" , "wb" );
/* Write the data (file) to the CD */
fwrite (code , 1 , sizeof(code) , CDfile );
/*
Sorry! I don't know how to write it to the CD (fwrite?). . Close the file (below code).
*/
fclose (CDfile);
return 0;
}
/* This takes much more time to read, then to load http://www.3-z.net (My website) ! */
< End >
I hope that C++ pro will take this on!
error: syntax error before '=' token
img2cd.c:7:1: warning: "RAND_MAX" redefined
In file included from img2cd.c:3:
stdlib.h:29:1: warning: this is the location of the previous definition
img2cd.c: In function `main':
img2cd.c:53: error: `PICTURE_X' undeclared (first use in this function)
error: `PICTURE_Y' undeclared (first use in this function)
error: `f1tof2Frame' undeclared (first use in this function)
GOD!
At last... Have I to put something after {(at the end)?
static unsigned char picture[PIC_HEIGHT][PIC_WIDTH] = {
Don't kill me XD
A lot of CD/DVD burners nowadays have the ability.
http://www.medcosm.com/prog_CGHmaker.htm
mechanically, at amasci.com or google "hand-drawn holograms",
and also some instructables on it. If you can do the math AND
burn the curves with this instructable's way, you can Make all the
holograms you want.
Suggestions: Holographic and/or digital sundial CD!
or, CD clock with 3D numbers and hands, using a quartz movement.
WIth c being enough points between 0 and 2 x pi, and radius r
x= r cos(c) ; y=r sin(c) makes circular fresnel curves,
and r determines the depth or projection distance of the image.
This then has to be remapped onto the CD using similar math,
converting voxel coordinates to pits bit and byte addresses.
A second conversion is needed to try to find the tracks and bytes
of every hologram pit burnt on the surface of the disc relative
to the center, using polar coordinates instead of x,y.
"for" all x and y that x2+y2=r2 is the pythagorean theorem way
to do the same thing... both maths are useful for triangles and
circles also. I hope you know a good geometry teacher if you
need help.
Don't fear the math, it just does what you can easily do by hand
with a coaster and a double pointed circle making compass,
when you make "hand drawn holograms". And if you can doodle
a video game on graph paper, that's related too, to where your
pixels are when you're laser burning your own hologram coaster.
??? Attempted to access img(83,142); index out of bounds because size(img)=(1,9).
Error in ==> img2cd at 176
if img(ny(k), nx(k))<128