Archivo de la categoría: Manipulación y Preservación de Datos TTP

Computadora mecánica binaria: Digi-Comp II

Digi-Comp II.

http://woodgears.ca/marbleadd/index.html

http://woodgears.ca/marbleadd/plans/index.html

http://woodgears.ca/marbleadd/more.html

 

3MF Project: What’s In A GIF – Animation and Transparency

What’s In A GIF – Animation and Transparency

vía 3MF Project: What’s In A GIF – Animation and Transparency.

Project: What’s In A GIF – Animation and Transparency

In addition to being able to store simple image data like some old bmp file, GIF files (specifically GIF89a files) allow for some special features. Tricks such as transparency and animation can be accomplished with the help of the Graphics Control Extension block. Here’s a sample of what this block looks like:

GIF graphics control ext block layout

I’ll show you how to manipulate the bytes in this block to achieve these special effects.

Animation

Cartoons are created by animators who draw a bunch of pictures, each slightly different from the one before, which, when rapidly shown one after the other, give the illusion of motion. Animation in GIF images is achieved in much the same way. Multiple images may be stored in the same file and you can tell the computer how much time to wait before showing the next image. Let’s walk though the parts that make up this simple traffic light animation.

sample animated traffic light

47 49 46 38 39 61 0B 00 1D 00 A2 05 00 FF 00 00 00 FF 00 FF FF 00 8E 8E 8E 00 00 00 FF FF FF 00 00 00 00 00 00 21 FF 0B 4E 45 54 53 43 41 50 45 32 2E 30 03 01 00 00 00 21 F9 04 04 64 00 00 00 2C 00 00 00 00 0B 00 1D 00 00 03 30 48 BA DC DE 23 BE 48 21 AD EB 62 A5 25 D3 93 F7 8C E4 27 9A 1B D7 A1 17 9B 1E A0 F3 96 34 13 DC CF AD 37 7A 6F F7 B8 05 30 28 F4 39 76 B5 64 02 00 21 F9 04 04 32 00 00 00 2C 02 00 0B 00 07 00 10 00 00 03 19 78 27 AC CB 0D CA 49 E1 B3 0A BB CD F7 F8 CE 27 1E 62 69 9E A3 19 82 47 02 00 21 F9 04 04 64 00 00 00 2C 02 00 02 00 07 00 10 00 00 03 19 78 07 AC CB 0D CA 49 E1 B3 0A BB CD F7 F8 CE 27 1E 62 69 9E A3 19 82 45 02 00 3B

This file is similar to the ones we’ve previously encountered. The bytes start out with the GIF header. Next we have a logical screen descriptor which tells us that our image is 11px by 29 px and will have a global color table with 8 colors in it (of which we only really need 5). Immediately after, follows the global color table which tells us what those colors are (0=red, 1=green, 2=yellow, 3=light grey, 4=black, 5=white, 6=black [not used], 7=black [not used] ).

Next we encounter an application extension block. This is this block that causes our animation to repeat rather than play once and stop. The first three bytes tell us we are looking at (1) an extension block (2) of type «application» which is followed by (3) 11 bytes of fixed length data. These 11 bytes contain the ASCII character codes for «NETSCAPE2.0». Then begins the actual «application data» which is contained in sub-blocks. There are two values that are stored in these sub-blocks. The first value is always the byte 01. Then we have a value in the unsigned (lo-hi byte) format that says how many times the animation should repeat. You can see that our sample image has a value of 0; this means the animation should loop forever. These three bytes are preceded by the 03 that lets the decoder know that three bytes of data follow, and they are terminated by 00, the block terminator.

This very basic animation is essentially made up of three different «scenes». The first is the one with the green light lit, the second with the yellow, and the last with the red. You should be able to see three separate chunks of image data in the bytes above.

1 2 3
scene 1: green light scene 2: yellow light scene 3: red light

The first chunk begins immediately after the application extension block. It is there we encounter our first graphic control extension. As with all extensions, it begins with 21. Next, the type specific label for the graphic control type of extension is F9. Next we see the byte size of the data in the block; this should always be 04. The first of these four data blocks is a packed field.

The packed field stores three values. The first three (highest) bits are «reserved for future use» so those have been left as zeros. The next three bits indicate the disposal method. The disposal method specifies what happens to the current image data when you move onto the next. We have three bits which means we can represent a number between 0 and 7. Our sample animated image has a value of 1 which tells the decoder to leave the image in place and draw the next image on top of it. A value of 2 would have meant that the canvas should be restored to the background color (as indicated by the logical screen descriptor). A value of 3 is defined to mean that the decoder should restore the canvas to its previous state before the current image was drawn. I don’t believe that this value is widely supported but haven’t had the chance to test it out. The behavior for values 4-7 are yet to be defined. If this image were not animated, these bits would have been set to 0 which indicates that do not wish to specify a disposal method. The seventh bit in they byte is the user input flag. When set to 1, that means that the decoder will wait for some sort of «input» from the person viewing the image before moving on to the next scene. I’m guessing it’s highly unlikeley that you will encounter any other value that 0 for this bit. The final bit is the transparency flag. We will go into more detail about transparency in the next section. Since this image isn’t using any transparency, we see this bit has been left at 0.

The next two bytes are the delay time. This value is in the usual unsigned format as all the other integers in the file. This number represents the number of hundredths of a second to wait before moving on to the next scene. We see that our sample image has specified a value of 100 (64 00) in the first graphics control block which means we would wait 1 second before changing our green light to yellow.

Our graphics control extension block ends with the block terminator 00. You will notice this type of block appearing two more times in this image, the second instance differing only in the delay time (the yellow light only stays up for half a second).

The next chunk is an image descriptor. The block declares that it will be drawing an image starting at the top left corner and taking up the whole canvas (11px x 29px). This block is followed by the image data that contains all the codes to draw the first scene, the one with the green light on.

Green (Difference) Yellow
green light enlarged difference between green and yellow images yellow light enlarged

If we compare the first and the second scene, we see they share many of the same pixel color values. Rather than redrawing the whole canvas, we can specify just the part that changes (that is, the smallest rectangle that covers the part that changes). You’ll see that the image descriptor before the second block of image data specifies that it will start at the pixel at (2, 11) and draws a box that’s 7px wide by 16px tall. This is just large enough to cover the bottom two lights. The works because we chose the «do not dispose» disposal method for out graphics control extension block. In the same way, the third and final image data block only renders the top two circles to both fill in the red and cover up the yellow.

Transparency

Normally, GIF images are rectangles that cover up what ever background may be beneath them. Transparency allows you to «see though» the image to whatever is below. This is a very simple trick to pull off in a GIF image. You can set up one color in your color table that is converted to «invisible ink.» Then, as the image is drawn, whenever this special color is encountered, the background is allowed to show through.

There are only two pieces of data we have to set to pull this off. First we must set the Transparency Color Flag to 1. This is the lowest bit in the packed byte of the Graphic Control Extension. This will tell the decoder that we want our image to have a transparent component. Secondly we must tell the decoder which color we want to use as our invisible ink. The decoder will then all you to see thought every pixel that contains this color. Therefore make sure it’s not a color that you are using else where in your image. The color you choose must be in the active color table and you specify its value in the Transparent Color Index byte by setting this value to the index of the color in the color table.

Let’s demonstrate this by revisiting the sample image we used in Bits and Bytes. We will update this file to make the white center part transparent. Let’s start creating the Graphic Control Extension block that will do this for us. Again we start with the 21 F9 04 punch. In the next byte, we need to flip the transparent color flag to 1 (we can leave the others at zero) so this whole byte is simply 01. The next two bytes can be left at zero.

We must now specify which color to disappear. Recall that our sample image had the following global color table:

Index Color
0 White
1 Red
2 Blue
3 Black

We already know what we want to make all the white sections transparent. The color white has an index of 0. Therefore we will specify a value of 00 for the transparent color index block. Had we wanted to make the red transparent we would have used 01, or 02 for blue. Lastly we tack on the block terminator of 00 and we’re done. We have created the following block:

21 F9 04 01 00 00 00 00

Now, all we have to do is plug this into our sample image right before the image descriptor. I’ve placed our original sample image on a black background as well as the one we just made so you can see the results. I’ve also included ones where red or blue are transparent. The last three differ by only the transparent color index byte.

Original Transparent
White (00)
Transparent
Red (01)
Transparent
Blue (02)
previous sample transparent white transparent red transparent blue

What’s In A GIF – LZW Image Data

What’s In A GIF – LZW Image Data

vía 3MF Project: What’s In A GIF – LZW Image Data.

What’s In A GIF – LZW Image Data

Now let’s look at exactly how we go about storing an image in a GIF file. The GIF format is a raster format, meaning it stores image data by remembering the color of every pixel in the image. More specifically, GIF files remember the index of the color in a color table for each pixel. To make that more clear, let me again show the sample image we used in the first section.

Actual Size

sample gif, actual size
(10×10)

Enlarged

sample gif, enlarged
(100×100)

Color Table

Index Color
0 White
1 Red
2 Blue
3 Black

The color table came from the global color table block. The colors are listed in the order which they appear in the file. The first color is given an index of zero. When we send the codes, we always start at the top left of the image and work our way right. When we get to the end of the line, the very next code is the one that starts the next line. (The decoder will «wrap» the image based on the image dimensions.) We could encode our sample image in the following way:

1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 2, 2, 2, …

The above listing shows the sequence required to render the first five lines of the image. We could continue with this method until we’ve specified the color for every pixel; however, this can result in a rather large file. Luckily for us, the GIF format allows us to take advantage of repetition in our output and to compress our data.

[ Much of the following information came from John Barkaus’s LZW and GIF Explained. I’ve tried to provide more detailed samples as well as illustrations to make the process even clearer; but if i’ve made something unclear, i would recommend consulting John’s original guide. ]

LZW Compression

The compression method we can use is called LZW compression. (Actually it is a slight variation from the standard LZW for use in GIF images.) To start using this method, we need a code table. This code table will allow us to use special codes to indicate a sequence of colors rather than just one at a time. The first thing we do is to initialize the code table. We start by adding a code for each of the colors in the color table. This would be a local color table if one was provided, or the global color table. (I will be starting all codes with «#» to distinguish them from color indexes.)

Code Color(s)
#0 0
#1 1
#2 2
#3 3
#4 Clear Code
#5 End Of Information Code

I added a code for each of the colors in the global color table of our sample image. I also snuck in two special control codes. (These special codes are only used in the GIF version of LZW, not in standard LZW compression.) Our code table is now considered initialized.

Let me now explain what those special codes are for. The first new code is the clear code (CC). Whenever you come across the clear code in the image data, it’s your cue to reinitialize the code table. (I’ll explain why you might need to do this in a bit.) The second new code is the end of information code (EOI). When you come across this code, this means you’ve reached the end of the image. Here i’ve placed the special codes right after the color codes, but actually the value of the special codes depends on the value of the LZW minimum code size from the image data block. If the LZW minimum code size is the same as the color table size, then special codes immediatly follow the colors; however it is possible to specify a larger LWZ minimum code size which may leave a gap in the codes where no colors are assigned. This can be summarizaed in the following table.

LWZ Min Code
Size
Color
Codes
Clear
Code
EOI
Code
2 #0-#3 #4 #5
3 #0-#7 #8 #9
4 #0-#15 #16 #17
5 #0-#31 #32 #33
6 #0-#63 #64 #65
7 #0-#127 #128 #129
8 #0-#255 #256 #257

Before we proceed, let me define two more terms. First the index stream will be the list of indexes of the color for each of the pixels. This is the input we will be compressing. The code stream will be the list of codes we generate as output. The index buffer will be the list of color indexes we care «currently looking at.» The index buffer will contain a list of one or more color indexes. Now we can step though the LZW compression algorithm. First, i’ll just list the steps. After that i’ll walk through the steps with our specific example.

  • Initialize code table
  • Always start by sending a clear code to the code stream.
  • Read first index from index stream. This value is now the value for the index buffer
  • <LOOP POINT>
  • Get the next index from the index stream to the index buffer. We will call this index, K
  • Is index buffer + K in our code table?
  • Yes:
    • add K to the end of the index buffer
    • if there are more indexes, return to LOOP POINT
  • No:
    • Add a row for index buffer + K into our code table with the next smallest code
    • Output the code for just the index buffer to our code steam
    • Index buffer is set to K
    • K is set to nothing
    • if there are more indexes, return to LOOP POINT
  • Output code for contents of index buffer
  • Output end-of-information code

Seems simple enough, right? It really isn’t all that bad. Let’s walk though our sample image to show you how this works. (The steps I will be describing are summarized in the following table. Numbers highlighted in green are in the index buffer; numbers in purple are the current K value.) We have already initialized our code table. We start by doing two things: we output our clear code (#4) to the code stream, and we read the first color index from the index stream, 1, into our index buffer [Step 0].

Now we enter the main loop of the algorithm. We read the next index in the index stream, 1, into K [Step 1]. Next we see if we have a record for the index buffer plus K in the code stream. In this case we looking for 1,1. Currently our code table only contains single colors so this value is not in there. Now we will actually add a new row to our code table that does contain this value. The next available code is #6, we will let #6 be 1,1. Note that we do not actually send this code to the code stream, instead we send just the code for the value(s) in the index buffer. The index buffer is just 1 and the code for 1 is #1. This is the code we output. We now reset the index buffer to just the value in K and K becomes nothing. [Step 2].

We continue by reading the next index into K. [Step 3]. Now K is 1 and the index buffer is 1. Again we look to see if there is a value in our code table for the buffer plus K (1,1) and this time there is. (In fact we just added it.) Therefore we add K to the end of the index buffer and clear out K. Now our index buffer is 1,1. [Step 4].

The next index in the index stream is yet another 1. This is our new K [Step 5]. Now the index buffer plus K is 1,1,1 which we do not have a code for in our code table. As we did before, we define a new code and add it to the code table. The next code would be #7; thus #7 = 1, 1, 1. Now we kick out the code for just the values in the index buffer (#6 = 1,1) to the code stream and set the index buffer to be K. [Step 6].

Step Action Index Stream New Code Table Row Code Stream
0 Init 11111222221111 #4
1 Read 11111222221111 #4
2 Not Found 11111222221111 #6 – 1, 1 #4 #1
3 Read 11111222221111 #4 #1
4 Found 11111222221111 #4 #1
5 Read 11111222221111 #4 #1
6 Not Found 11111222221111 #7 – 1, 1, 1 #4 #1 #6
7 Read 11111222221111 #4 #1 #6
8 Found 11111222221111 #4 #1 #6
9 Read 11111222221111 #4 #1 #6
10 Not Found 11111222221111 #8 – 1, 1, 2 #4 #1 #6 #6
11 Read 11111222221111 #4 #1 #6 #6
12 Not Found 11111222221111 #9 – 2, 2 #4 #1 #6 #6 #2
13 Read 11111222221111 #4 #1 #6 #6 #2
14 Found 11111222221111 #4 #1 #6 #6 #2
15 Read 11111222221111 #4 #1 #6 #6 #2
16 Not Found 11111222221111 #10 – 2, 2, 2 #4 #1 #6 #6 #2 #9
17 Read 11111222221111 #4 #1 #6 #6 #2 #9
18 Found 11111222221111 #4 #1 #6 #6 #2 #9
19 Read 11111222221111 #4 #1 #6 #6 #2 #9
20 Not Found 11111222221111 #11 – 2, 2, 1 #4 #1 #6 #6 #2 #9 #9
21 Read 11111222221111 #4 #1 #6 #6 #2 #9 #9
22 Found 11111222221111 #4 #1 #6 #6 #2 #9 #9
23 Read 11111222221111 #4 #1 #6 #6 #2 #9 #9
24 Found 11111222221111 #4 #1 #6 #6 #2 #9 #9
25 Read 11111222221111 #4 #1 #6 #6 #2 #9 #9
26 Not Found 11111222221111 #12 – 1, 1, 1, 1 #4 #1 #6 #6 #2 #9 #9 #7

I’ve included a few more steps to help you see the pattern. You keep going until you run out of indexes in the index stream. When there is nothing new to read, you simply write out the code for whatever values you may have in your index buffer. Finally you should send the end-of-information code to the code stream. In this example, that code is #5. (View the complete code table.)

As you can see we dynamically built many new codes for our code table as we compressed the data. For large files this can turn into a large number of codes. It turns out that the GIF format specifies a maximum code of #4095 (this happens to be the largest 12-bit number). If you want to use a new code, you have to clear out all of your old codes. You do this by sending the clear code (which for our sample was the #4). This tells the decoder that you are reinitializing your code table and it should too. Then you start building your own codes again starting just after the value for your end-of-information code (in our sample, we would start again at #6).

The final code stream would look like this:

#4 #1 #6 #6 #2 #9 #9 #7 #8 #10 #2 #12 #1 #14 #15 #6 #0 #21 #0 #10 #7 #22 #23 #18 #26 #7 #10 #29 #13 #24 #12 #18 #16 #36 #12 #5

This is only 36 codes versus the 100 that would be required without compression.

LZW Decompression

At some point we will probably need to turn this code stream back into a picture. To do this, we only need to know the values in the stream and the size of the color table that was used. That’s it. You remember that big code table we built during compression? We actually have enough information in the code stream itself to be able to rebuild it.

Again, i’ll list the algorithm and then we will walk though an example. Let me define a few terms i will be using. CODE will be current code we’re working with. CODE-1 will be the code just before CODE in the code stream. {CODE} will be the value for CODE in the code table. For example, using the code table we created during compression, if CODE=#7 then {CODE}=1,1,1. In the same way, {CODE-1} would be the value in the code table for the code that came before CODE. Looking at step 26 from the compression, if CODE=#7, then {CODE-1} would be {#9}, not {#6}, which was 2,2.

  • Initialize code table
  • let CODE be the first code in the code stream
  • output {CODE} to index stream
  • <LOOP POINT>
  • let CODE be the next code in the code stream
  • is CODE in the code table?
  • Yes:
    • output {CODE} to index stream
    • let K be the first index in {CODE}
    • add {CODE-1}+K to the code table
  • No:
    • let K be the first index of {CODE-1}
    • output {CODE-1}+K to index stream
    • add {CODE-1}+K to code table
  • return to LOOP POINT

Let’s start reading though the code stream we’ve created to show how to turn it back into a list of color indexes. The first value in the code stream should be a clear code. This means we should initialize our code table. To do this we must know how many colors are in our color table. (This information comes from the first byte in the image data block in the file. More on this later.) Again we will set up codes #0-#3 to be each of the four colors and add in the clear code (#4) and end of information code (#5).

The next step is to read the first color code. In the following table you will see the values of CODE highlighted in purple, and the values for CODE-1 highlighted in green. Our first CODE value is #1. We then output {#1}, or simply 1, to the index stream [Step 0].

Now we enter the main loop of the algorithm. The next code gets assigned to CODE which now makes that value #6. Next we check to see if this value is in our code table. At this time, it is not. This means we must find the first index in the value of {CODE-1} and call this K. Thus K = first index of {CODE-1} = first index of {#1} = 1. Now we output {CODE-1} + K to the index stream and add this value to our code table. The means we output 1,1 and give this value a code of #6 [Step 1].

Step Action Code Stream New Code Table Row Index Stream
0 Init #4 #1 #6 #6 #2 #9 #9 #7 … 1
1 Not Found #4 #1 #6 #6 #2 #9 #9 #7 … #6 – 1, 1 1, 1, 1
2 Found #4 #1 #6 #6 #2 #9 #9 #7 … #7 – 1, 1, 1 1, 1, 1, 1, 1
3 Found #4 #1 #6 #6 #2 #9 #9 #7 … #8 – 1, 1, 2 1, 1, 1, 1, 1, 2
4 Not Found #4 #1 #6 #6 #2 #9 #9 #7 … #9 – 2, 2 1, 1, 1, 1, 1, 2, 2, 2
5 Found #4 #1 #6 #6 #2 #9 #9 #7 … #10 – 2, 2, 2 1, 1, 1, 1, 1, 2, 2, 2, 2, 2
6 Found #4 #1 #6 #6 #2 #9 #9 #7 #11 – 2, 2, 1 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 1, 1

We start the loop again by reading the next code. CODE now would be #6 and this time we do have a record for this code in our code table. Thus we dump {#6} to the index stream which would be 1,1. Now we take the first index in {#6} and call that K. Here, {#6} has two indexes, the first of which is 1; thus K = 1. Before moving on, we add {CODE-1}+K to the code table. This #7 is now 1, 1, 1 [Step 2].

I’ve included a few more steps so you can see the algorithm in action. While the explanation may sound complicated, you can see it’s actually quite simple. You’ll also notice that you end up building the exact same code table as the one that was created during compression. This is the reason that LZW is so great; we can just share the codes and not the table.

Saving the Code Stream as Bytes

I’ve shown you how to go back and forth between index and code stream, but haven’t told you what to do with them. The index stream is used to specify the color of each of the pixel of your image and really only shows up on screen. It is the code stream that is actually saved in the GIF files on your computer or transmitted over the internet. In order to save these code streams, we must turn them into bytes. The first thought might be to store each of the codes as its own byte; however this would limit the max code to just #255 and result in a lot of wasted bits for the small codes. To solve these problems, the GIF file format actually uses flexible code sizes.

Flexible code sizes allow for further compression by limiting the bits needed to save the code stream as bytes. The code size is the number of bits it takes to store the value of the code. When we talk about bits, we’re referring to the 1’s and 0’s that make up a byte. The codes are converted to their binary values to come up with the bits. To specify the code for #4, you would look at this binary equivalent, which is 100, and see that you would need three bits to store this value. The largest code value in our sample code stream is #36 (binary: 100100) which would take 6 bits to encode. Note that the number of bits i’ve just given is the minimum number. You can make the number take up more bits by adding zeros to the front.

GIF image data block layout

We need a way to know what size each of the codes are. Recall that the image data block begins with a single byte value called the LZW minimum code size. The GIF format allows sizes as small as 2 bits and as large as 12 bits. This minimum code size value is typically the number of bits/pixel of the image. So if you have 32 colors in your image, you will need 5 bits/pixel (for numbers 0-31 because 31 in binary is 11111). Thus, this will most likely be one more than the bit value for the size of the color table you are using. (Even if you only have two colors, the minimum code size most be at least 2.) Refer to the code table above to remind yourself how that works.

Here’s the funny thing: the value for minimum code size isn’t actually the smallest code size that’s used in the encoding process. Because the minimum code size tells you how many bits are needed just for the different colors of the image, you still have to account for the two special codes that we always add to the code table. Therefore the actual smallest code size that will be used is one more than the value specified in the «minimum» code size byte. I’ll call this new value the first code size.

We now know how many bytes the first code will be. This size will probably work for the next few codes as well, but recall that the GIF format allows for flexible code sizes. As larger code values get added to your code table, you will soon realize that you need larger code sizes if you were to output those values. When you are encoding the data, you increase your code size as soon as your write out the code equal to 2^(current code size)-1. If you are decoding from codes to indexes, you need to increase your code size as soon as you add the code value that is equal to 2^(current code size)-1 to your code table. That is, the next time you grab the next section of bits, you grab one more.

Note that the largest code size allowed is 12 bits. If you get to this limit, the next code you encounter should be the clear code which would tell you to reinitialize the code table. You then go back to using the first code size and grow again when necessary.

Jumping back to our sample image, we see that we have a minimum code size value of 2 which means out first code size will be 3 bits long. Out first three codes, #1 #6 and #6, would be coded as 001 110 and 110. If you see at Step 6 of the encoding, we added a code of #7 to our code table. This is our clue to increase our code size because 7 is equal to 2^3-1 (where 3 is our current code size). Thus, the next code we write out, #2, will use the new code size of 4 and therefore look like 0010. In the decoding process, we again would increase our code size when we read the code for #7 and would read the next 4, rather than the next 3 bits, to get the next code. In the sample table above this occurs in Step 2.

Finally we must turn all these bit values into bytes. The lowest bit of the code bit value gets placed in the lowest available bit of the byte. After you’ve filled up the 8 bits in the byte, you take any left over bits and start a new byte. Take a look at the following illustration to see how that works with the codes from our sample image.

Encoding LZW Codes

You can see in the first byte that was returned (8C) that the lowest three bits (because that was our first code size) contain 110 which is the binary value of 4 so that would be the clear code we started with, #4. In the three bits to the left, you see 001 which out or first data code of #1. You can also see when we switched into code sizes of 4 bits in the second byte (2D).

When you run out of codes but have filled less than 8 bits of the byte, you should just fill the remaining bits with zeros. Recall that the image data must be broken up onto data sub-blocks. Each of the data sub-blocks begins with a byte that specifies how many bytes of data. The value will be between 1 and 255. After you read those bytes, the next byte indicates again how many bytes of data follow. You stop when you encounter a subblock that has a lenght of zero. That tells you when you’ve reached the end of the image data. In our sample the image the byte just after the LZW code size is 16 which indicates that 22 bytes of data follow. After we reach those, we see the next byte is 00 which means we are all done.

Return codes from bytes the basically just the same process in reverse. A sample illustration of the process follows which shows how you would extract codes if the first code size were 5 bits.

Decoding LZW Bytes

Next: Animation and Transparency

That is pretty much everything you need to know to read or generate a basic image file. One of the reasons the GIF becames such a popular format was because it also allowed for «fancier» features. These features include animation and transparency. Next we’ll look at how those work. Continue…

3MF Project: What’s In A GIF – Bit by Byte

What’s In A GIF – Bit by Byte

vía 3MF Project: What’s In A GIF – Bit by Byte.

We sill start off by walking though the different parts of a GIF file. (The information on this page is primarily drawn from the W3C GIF89a specification.) A GIF file is made up of a bunch of different «blocks» of data. The following diagram shows all of the different types of blocks and where they belong in the file. The file starts at the left and works it’s way right. At each branch you may go one way or the other. The large «middle» section can be repeated as many times as needed. (Technically, it may also be omitted completely but i can’t imagine what good a GIF file with no image data would be.)

GIF file stream diagram

I’ll show you what these blocks looks like by walking through a sample GIF file. You can see the sample file and its corresponding bytes below.

Actual Size

sample gif, actual size
(10×10)

Enlarged

sample gif, enlarged
(100×100)

Bytes

47 49 46 38 39 61 0A 00 0A 00 91 00 00 FF FF FF FF 00 00 00 00 FF 00 00 00 21 F9 04 00 00 00 00 00 2C 00 00 00 00 0A 00 0A 00 00 02 16 8C 2D 99 87 2A 1C DC 33 A0 02 75 EC 95 FA A8 DE 60 8C 04 91 4C 01 00 3B

Note that not all blocks are represented in this sample file. I will provide samples of missing blocks where appropriate. The different types of blocks include: header, logical screen descriptor, global color table, graphics control extension, image descriptor, local color table, image data, plain text extension, application extension, comment extension, and trailer. Let’s get started with the first block!

Header Block

From Sample File: 47 49 46 38 39 61

All GIF files must start with a header block. The header takes up the first six bytes of the file. These bytes should all correspond to ASCII character codes. We actually have two pieces of information here. The first three bytes are called the signature. These should always be «GIF» (ie 47=»G», 49=»I», 46=»F»). The next three specify the version of the specification that was used to encode the image. We’ll only be working with «89a» (ie 38=»8″, 39=»9″, 61=»a»). The only other recognized version string is «87a» but i doubt most people will run into those anymore.

GIF header block layout

Logical Screen Descriptor

From Sample File: 0A 00 0A 00 91 00 00

The logical screen descriptor always immediately follows the header. This block tells the decoder how much room this image will take up. It is exactly seven bytes long. It starts with the canvas width. This value can be found in the first two bytes. It’s saved in a format called the spec simply calls unsigned. Basically we’re looking at a 16-bit, nonnegative integer (0-65,535). As with all the other multi-byte values in the GIF format, the least significant byte is stored first (little-endian format). This means where we would read 0A 00 from the byte stream, we would normally write it as 000A which is the same as 10. Thus the width of our sample image is 10 pixels. As a further example 255 would be stored as FF 00 but 256 would be 00 01 . As you might expect, the canvas height follows. Again, in this sample we can see this value is 0A 00 which is 10.

Next we have a packed byte. That means that this byte actually has multiple values stored in its bits. In this case, the byte 91 can be represented as the binary number 10010001. (The built in Windows calculator is actually very useful when converting numbers into hexadecimal and binary formats. Be sure it’s in «scientific» or «programmer» mode, depending on the version of windows you have.) The first (most-significant) bit is the global color table flag. If it’s 0, then there is none. If it’s 1, then a global color table will follow. In our sample image, we can see that we will have a global color table (as will usually be the case). The next three bits represent the color resolution. The spec says this value » is the number of bits per primary color available to the original image, minus 1″ and «…represents the size of the entire palette from which the colors in the graphic were selected.» Because i don’t much about what this one does, i’ll point you to a more knowledgeable article on bit and color depth. For now 1 seems to work. Note that 001 represents 2 bits/pixel; 111 would represent 8 bits/pixel. The next single bit is the sort flag. If the values is 1, then the colors in the global color table are sorted in order of «decreasing importance,» which typically means «decreasing frequency» in the image. This can help the image decoder but is not required. Our value has been left at 0. The last three bits are the size of global color table. Well, that’s a lie; it’s not the actual size of the table. If this value is N, then the actual table size is 2^(N+1). From our sample file, we get the three bits 001 which is the binary version of 1. Our actual table size would be 2^(1+1) = 2^2 = 4. (We’ve mentioned the global color table several times with this byte, we will be talking about what it is in the next section.)

The next byte gives us the background color index. This byte is only meaningful if the global color table flag is 1. It represents which color in the global color table (by specifying its index) should be used for pixels whose value is not specified in the image data. If, by some chance, there is no global color table, this byte should be 0.

The last byte of the logical screen descriptor is the pixel aspect ratio. I’m not exactly sure what this value does. Most of the images i’ve seen have this value set to 0. The spec says that if there was a value specified in this byte, N, the actual ratio used would be (N + 15) / 64 for all N<>0.

GIF logical screen descriptor block layout

Global Color Table

From Sample File: FF FF FF FF 00 00 00 00 FF 00 00 00

We’ve mentioned the global color table a few times already now lets talk about what it actually is. As you are probably already aware, each GIF has its own color palette. That is, it has a list of all the colors that can be in the image and cannot contain colors that are not in that list. The global color table is where that list of colors is stored. Each color is stored in three bytes. Each of the bytes represents an RGB color value. The first byte is the value for red (0-255), next green, then blue. The size of the global color table is determined by the value in the packed byte of the logical screen descriptor. As we mentioned before, if the value from that byte is N, then the actual number of colors stored is 2^(N+1). This means that the global color table will take up 3*2^(N+1) bytes in the stream.

Size In Logical
Screen Desc
Number Of
Colors
Byte
Length
0 2 6
1 4 12
2 8 24
3 16 48
4 32 96
5 64 192
6 128 384
7 256 768

Or sample file has a global color table size of 1. This means it holds 2^(1+1)=2^2=4 colors. We can see that it takes up 12, (3*4), bytes as expected. We read the bytes three at a time to get each of the colors. The first color is #FFFFFF (white). This value is given an index of 0. The second color is #FF0000 (red). The color with an index value of 2 is #0000FF (blue). The last color is #000000 (black). The index numbers will be important when we decode the actual image data.

Note that this block is labeled as «optional.» Not every GIF has to specify a global color table. However, if the global color table flag is set to 1 in the logical screen descriptor block, the color table is then required to immediately follow that block.

GIF global color table block layout

Graphics Control Extension

From Sample File: 21 F9 04 00 00 00 00 00

Graphic control extension blocks are used frequently to specify transparency settings and control animations. They are completly optional. Since transparency and animations are bit complicated, I will hold off on many of the details of this block until a later section (see Transparency and Animation). In the interest of this page being complete, I will at least tell you what the bytes represent.

The first byte is the extension introducer. All extension blocks begin with 21. Next is the graphic control label, F9, which is the value that says this is a graphic control extension. Third up is the total block size in bytes. Next is a packed field. Bits 1-3 are reserved for future use. Bits 4-6 indicate disposal method. The penult bit is the user input flag and the last is the transparent color flag. The delay time value follows in the next two bytes stored in the unsigned format. After that we have the transparent color index byte. Finally we have the block terminator which is always 00.

GIF graphic control extension block layout

Image Descriptor

From Sample File: 2C 00 00 00 00 0A 00 0A 00 00

A single GIF file may contain multiple images (useful when creating animated images). Each image begins with an image descriptor block. This block is exactly 10 bytes long.

The first byte is the image separator. Every image descriptor begins with the value 2C. The next 8 bytes represent the location and size of the following image. An image in the stream may not necessarily take up the entire canvas size defined by the logical screen descriptor. Therefore, the image descriptor specifies the image left position and image top position of where the image should begin on the canvas. Next it specifies the image width and image height. Each of these values is in the two-byte, unsigned format. Our sample image indicates that the image starts at (0,0) and is 10 pixels wide by 10 pixels tall. (This image does take up the whole canvas size.)

The last byte is another packed field. In our sample file this byte is 0 so all of the sub-values will be zero. The first (most significant) bit in the byte is the local color table flag. Setting this flag to 1 allows you to specify that the image data that follows uses a different color table than the global color table. (More information on the local color table follows.) The second bit is the interlace flag.

GIF image descriptor block layout

Local Color Table

The local color table looks identical to the global color table. The local color table would always immediately follow an image descriptor but will only be there if the local color table flag is set to 1. It is effective only for the block of image data that immediately follows it. If no local color table is specified, the global color table is used for the following image data.

The size of the local color table can be calculated by the value given in the image descriptor. Just like with the global color table, if the image descriptor specifies a size of N, the color table will contain 2^(N+1) colors and will take up 3*2^(N+1) bytes. The colors are specified in RGB value triplets.

Image Data

From Sample File: 02 16 8C 2D 99 87 2A 1C DC 33 A0 02 75 EC 95 FA A8 DE 60 8C 04 91 4C 01 00

Finally we get to the actual image data. The image data is composed of a series of output codes which tell the decoder which colors to spit out to the canvas. These codes are combined into the bytes that make up the block. I’ve set an whole other section on decoding these output code into an image (see LZW Image Data). On this page i’m just going to tell you how to determine how long the block will be.

The first byte of this block is the LZW minimum code size. This value is used to decode the compressed output codes. (Again, see the section on LZW compression to see how this works.) The rest of the bytes represent data sub-blocks. Data sub-blocks are are groups of 1 – 256 bytes. The first byte in the sub-block tells you how many bytes of actual data follow. This can be a value from 0 (00) it 255 (FF). After you’ve read those bytes, the next byte you read will tell you now many more bytes of data follow that one. You continue to read until you reach a sub-block that says that zero bytes follow.

You can see our sample file has a LZW minimum code size of 2. The next byte tells us that 22 bytes of data follow it (16 hex = 22). After we’ve read those 22 bytes, we see the next value is 0. This means that no bytes follow and we have read all the data in this block.

GIF image data block layout

Plain Text Extension

Example (Not in Sample File): 21 01 0C 00 00 00 00 64 00 64 00 14 14 01 00 0B 68 65 6C 6C 6F 20 77 6F 72 6C 64 00

Oddly enough the spec allows you to specify text which you wish to have rendered on the image. I followed the spec to see if any application would understand this command; but IE, FireFox, and Photoshop all failed to render the text. Rather than explaining all the bytes, i’ll tell you how to recognize this block and skip over it

The block begins with an extension introducer as all extension block types do. This value is always 21. The next byte is the plain text label. This value of 01 is used to distinguish plain text extensions from all other extensions. The next byte is the block size. This tells you how many bytes there are until the actual text data begins, or in other words, how many bytes you can now skip. The byte value will probably be 0C which means you should jump down 12 bytes. The text that follows is encoded in data sub-blocks (see Image Data to see how these sub-blocks are formed). The block ends when you reach a sub-block of length 0.

Application Extension

Example (Not in Sample File): 21 FF 0B 4E 45 54 53 43 41 50 45 32 2E 30 03 01 05 00 00

The spec allows for application specific information to be embedded in the GIF file itself. The only reference to could find to application extensions was the NETSCAPE2.0 extension which is used to loop an animated GIF file. I’ll go into more detail on looping in when we talk about animation.

Like with all extensions, we start with 21 which is the extension introducer. Next is the extension label which for application extensions is FF. The next value is the block size which tells you how many bytes there are before the actual application data begins. This byte value should be 0B which indicates 11 bytes. These 11 bytes hold two pieces of information. First is the application identifier which takes up the first 8 bytes. These bytes should contain ASCII character codes that identify to which application the extension belongs. In the case of the example above, the application identifier is «NETSCAPE» which is conveniently 8 characters long. The next three bytes are the application authentication code. The spec says these bytes can be used to «authenticate the application identifier.» With the NETSCAPE2.0 extension, this value is simply a version number, «2.0», hence the extensions name. What follows is the application data broken into data sub-blocks. Like with the other extensions, the block terminates when you read a sub-block that has zero bytes of data.

Comment Extension

Example (Not in Sample File): 21 FE 09 62 6C 75 65 62 65 72 72 79 00

One last extension type is the comment extension. Yes, you can actually embed comments with in a GIF file. Why you would want to increase the file size with unprintable data, i’m not sure. Perhaps it would be a fun way to pass secret messages.

It’s probably no surprise by now that the first byte is the extension introducer which is 21. The next byte is always FE which is the comment label. Then we jump right to data sub-blocks containing ASCII character codes for your comment. As you can see from the example we have one data sub-block that is 9 bytes long. If you translate the character codes you see that the comment is «blueberry.» The final byte, 00, indicates a sub-block with zero bytes that follow which let’s us know we have reached the end of the block.

GIF comment extension block layout

Trailer

From sample file: 3B

The trailer block indicates when you’ve hit the end of the file. It is always a byte with a value of 3B.

GIF trailer block layout

Next: LZW Image Data

Now that you know what the basic parts of a GIF file are, let’s next focus our attention on how the actual image data is stored and compressed. Continue…

huffman code

 

 

 

 

 

 

 

beluga computing – code – applets – huffman code.

Muestra el árbol de codificación Huffman de un texto ingresado

 

 

TP Malware

TP Malware

Trabajo grupal con 2 integrantes

Haz clic para acceder a HHS_es6_Malware.pdf

  • Generar un mapa conceptual de los tipos de malware con algunas de las siguientes herramientas. Debe estar bien organizado conceptualmente con ejemplos, referencias a sitios webs e imágenes. La imagen resultante debe insertarse en el documento de presentación del trabajo
  • Explicar cada tipo de contramedidas y describir detalladamente 2 softwares de cada uno

Se debe presentar el TP como un documento compartido con los integrantes del grupo y con el docente

¿Qué es un petabyte?

InterLink Headline News 2.0 — ¿Qué es un petabyte?

Blogged with the Flock Browser

DocList API OCR Demo

Please choose a JPG, GIF, or PNG to be OCR’ed.Please note that the operation can currently take up to 40 seconds.A number of limitations: * Files must be fairly high-resolution — rule of thumb is 10 pixel character height. * Maximum file size: 10MB, maximum resolution: 25 mega pixel * The larger the file, the longer the OCR operation will take (500K: ~15s, 2MB: ~40s, 10MB: forever)

DocList API OCR Demo

Blogged with the Flock Browser

Ultimate Malware Removal Guide — Purge Your PC of Junk Files!

Ultimate Malware Removal Guide — Purge Your PC of Junk Files! – Page 1 | Maximum PC

Blogged with the Flock Browser

Unicode table for you

Unicode table for you

Blogged with the Flock Browser

Creador de archivos PDF online

Creador de archivos PDF online

Free Online PDF Creator – Convert files to PDF on the Web – PrimoOnline

Blogged with the Flock Browser

Trabajo práctico 3ro Info MPD e IBS

Backups

http://openbookproject.net/courses/intro2ict/software/backups.xhtml

Seguridad

http://openbookproject.net/courses/intro2ict/software/resources/security_lab_programs.xhtml

http://lifehacker.com/5227896/five-best-malware-removal-tools http://www.lanacion.com.ar/nota.asp?nota_id=1003555 https://alefalletti.wordpress.com/2008/09/26/tp-solucion-a-los-problemas-comunes-de-la-pc-ibs-1ro-info/

Software libre

https://alefalletti.wordpress.com/2008/02/18/tp-documental-software-libre/ http://www.fedaro.info/2007/11/20/guia-practica-sobre-software-libre-su-seleccion-y-aplicacion-local-en-america-latina-y-el-caribe/ SO

http://openbookproject.net/courses/intro2ict/software/operating_systems.xhtml

Curso Ubuntu

http://www.linuxeslibre.com.ar/cursos/course/view.php?id=7

http://bitelia.com/2008/01/curso-de-ubuntu-para-estudiantes-y-profesores

Discos Rígidos: NTFS.com Fixing and repair MBR.Fix MBR.Recover boot record.Recovery.

MBR is damaged

The Master Boot Record (MBR) will be created when you create the first partition on the hard disk. It is very important data structure on the disk. The Master Boot Record contains the Partition Table for the disk and a small amount of executable code for the boot start. The location is always the first sector on the disk.

The first 446 (0x1BE) bytes are MBR itself, the next 64 bytes are the Partition Table, the last two bytes in the sector are a signature word for the sector and are always 0x55AA.

For our disk layout we have MBR:

Physical Sector: Cyl 0, Side 0, Sector 1
000000000   33 C0 8E D0 BC 00 7C FB  50 07 50 1F FC BE 1B 7C   3AZ??.|uP.P.u?.|
000000010   BF 1B 06 50 57 B9 E5 01  F3 A4 CB BE BE 07 B1 04   ?..PW?a.o¤E??.±.
000000020   38 2C 7C 09 75 15 83 C6  10 E2 F5 CD 18 8B 14 8B   8,|.u.??.aoI.‹.‹
000000030   EE 83 C6 10 49 74 16 38  2C 74 F6 BE 10 07 4E AC   i??.It.8,to?..N¬
000000040   3C 00 74 FA BB 07 00 B4  0E CD 10 EB F2 89 46 25   <.tu»..?.I.eo‰F%
000000050   96 8A 46 04 B4 06 3C 0E  74 11 B4 0B 3C 0C 74 05   –SF.?.<.t.?.<.t.
000000060   3A C4 75 2B 40 C6 46 25  06 75 24 BB AA 55 50 B4   :Au+@?F%.u$»?UP?
000000070   41 CD 13 58 72 16 81 FB  55 AA 75 10 F6 C1 01 74   AI.Xr.?uU?u.oA.t
000000080   0B 8A E0 88 56 24 C7 06  A1 06 EB 1E 88 66 04 BF   .Sa?V$C.?.e.?f.?
000000090   0A 00 B8 01 02 8B DC 33  C9 83 FF 05 7F 03 8B 4E   ..?..‹U3E?y..‹N
0000000A0   25 03 4E 02 CD 13 72 29  BE 46 07 81 3E FE 7D 55   %.N.I.r)?F.?>?}U
0000000B0   AA 74 5A 83 EF 05 7F DA  85 F6 75 83 BE 27 07 EB   ?tZ?i.U…ou??'.e
0000000C0   8A 98 91 52 99 03 46 08  13 56 0A E8 12 00 5A EB   S?‘R™.F..V.e..Ze
0000000D0   D5 4F 74 E4 33 C0 CD 13  EB B8 00 00 00 00 00 00   OOta3AI.e?......
0000000E0   56 33 F6 56 56 52 50 06  53 51 BE 10 00 56 8B F4   V3oVVRP.SQ?..V‹o
0000000F0   50 52 B8 00 42 8A 56 24  CD 13 5A 58 8D 64 10 72   PR?.BSV$I.ZX?d.r
000000100   0A 40 75 01 42 80 C7 02  E2 F7 F8 5E C3 EB 74 49   .@u.B€C.a?o^AetI
000000110   6E 76 61 6C 69 64 20 70  61 72 74 69 74 69 6F 6E   nvalid partition
000000120   20 74 61 62 6C 65 00 45  72 72 6F 72 20 6C 6F 61    table.Error loa
000000130   64 69 6E 67 20 6F 70 65  72 61 74 69 6E 67 20 73   ding operating s
000000140   79 73 74 65 6D 00 4D 69  73 73 69 6E 67 20 6F 70   ystem.Missing op
000000150   65 72 61 74 69 6E 67 20  73 79 73 74 65 6D 00 00   erating system..
000000160   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000000170   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000000180   00 00 00 8B FC 1E 57 8B  F5 CB 00 00 00 00 00 00   ...‹u.W‹oE......
000000190   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0000001A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0000001B0   00 00 00 00 00 00 00 00  A6 34 1F BA 00 00 80 01   ........¦4.?..€.
0000001C0   01 00 07 FE 7F 3E 3F 00  00 00 40 32 4E 00 00 00   ...?>?...@2N...
0000001D0   41 3F 06 FE 7F 64 7F 32  4E 00 A6 50 09 00 00 00   A?.?d2N.¦P....
0000001E0   41 65 0F FE BF 4A 25 83  57 00 66 61 38 00 00 00   Ae.??J%?W.fa8...
0000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA   ..............U?

 

What will happen if the first sector has been damaged (by virus, for example)?

Lets overwrite the first 16 bytes with zeros.

000000000   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
000000010   BF 1B 06 50 57 B9 E5 01  F3 A4 CB BE BE 07 B1 04   ?..PW?a.o¤E??.±.

 

When we try to boot after hardware testing procedures, we see just blank screen without any messages. It means the piece of code at the beginning of the MBR could not be executed properly. That’s why even error messages could not be displayed. However, if we boot from the floppy, we can see FAT partition, files on it and we are able to perform standard operations like file copy, program execution… It happens because in our example only part of the MBR has been damaged which does not allow the system to boot properly. However, the partition table is safe and we can access our drives when we boot from the operating system installed on the other drive.

What will happen if sector signature (last word 0x55AA) has been removed or damaged?

Lets write zeros to the location of sector signature.

Physical Sector: Cyl 0, Side 0, Sector 1
0000001E0   41 65 0F FE BF 4A 25 83  57 00 66 61 38 00 00 00   Ae.??J%?W.fa8...
0000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

When we try to boot now, we see an error message like «Operating System not found».

Thus the first thing if computer does not boot is to run Disk Viewer and check the first physical sector on HDD, whether it looks like valid MBR or not:

  • check, may be it’s filled up with zeros or any other single character
  • check whether error messages (like you can see above «Invalid partition table»…) are present or not
  • check whether disk signature (0x55AA) is present or not

The simplest way to repair or re-create MBR is to run Microsoft’s standard utility called FDISK with a parameter /MBR, like

	A:\> FDISK.EXE  /MBR

FDISK is a standard utility included in MS-DOS, Windows 95, 98, ME.

If you have Windows NT / 2000 / XP, you can boot from startup floppy disks or CD-ROM, choose repair option during setup, and run Recovery Console. When you are logged on, you can run FIXMBR command to fix MBR.

Also you can use third party MBR recovery software or if you’ve created MBR backup, restore it from there (Active@ Partition Recovery has such capabilities).

What will happen if the first sector is bad/unreadable?

Most likely we’ll get the same black screen, which we got when trying to boot. When you try to read it using Disk Viewer/Editor you should get an error message saying that sector is unreadable. In this case recovery software is unable to help you to bring HDD back to the working condition, i.e. physical partition recovery is not possible. The only thing that can be done is to scan and search for partitions (i.e. perform virtual partition recovery), and in case if something is found – display them and give the user an opportunity to save important data to another location. Third party software, like Active@ UNERASER, will help you here.

 

Recommended software:

Active@ Partition Recovery

NTFS.com Fixing and repair MBR.Fix MBR.Recover boot record.Recovery.

Blogged with the Flock Browser

Lifehacker – Five Best Malware Removal Tools – Malware Removal

Lifehacker – Five Best Malware Removal Tools – Malware Removal

Blogged with the Flock Browser

Copiar y pegar de una computadora a otra. Hey! Paste It

Copiar y pegar de una computadora a otra.

Hey! Paste It

Blogged with the Flock Browser

Posters TI

Muy buen material para nuestras salas de informática

y hay varios más en

Royal Pingdom » IT posters to cover your empty walls

Blogged with the Flock Browser

Tags: , , ,

Juego Binario

http://forums.cisco.com/CertCom/game/binary_game_page.htm

Informática Escuela ORT

Blogged with the Flock Browser

Tags: , ,

TP Digitalización de textos – 1ro Info 2008

TP Digitalización de textos
1ro Info 2008
26-sep

Digitalización del ideario del Complejo Educativo «Dr. F. de Gurruchaga»


La finalidad del presente trabajo es a digitalización, el almacenamiento, procesado y difusión del ideario del Complejo Educativo «Dr. F. de Gurruchaga» , guía y basamento de nuestra institución. La finalidad de la fase de digitalización es conseguir la captura digital del documento que va a formar parte del sistema de información de la institución con un nivel de corrección suficiente como para que las imágenes o textos digitales obtenidos cumplan unos requerimientos de calidad adecuados.
Partimos de la base de que no sólo el conocimiento de la tecnología a aplicar para la obtención de versiones digitales de documentos en su origen no digital garantiza una captura correcta, sino que también es imprescindible considerar, comprender y precisar con exactitud las características del documento original que deberán estar reproducidas con suficiente nivel de corrección en su versión digital.
A través de la implantación de un sistema de información que permita el acceso a imágenes digitales se persigue evitar en la mayor medida posible el acceso al objeto original,que es sustituido por la versión digital que el usuario obtiene en pantalla o por impresora.El usuario debe poder encontrar en esa versión aquella información del original que necesita obtener. Esto es, al comienzo del proyecto de digitalización hay que tener suficientemente claro qué es lo que se quiere difundir, o lo que es lo mismo, qué información de estos objetos va a ser posible ofrecer a través de sus versiones digitales, y el nivel de corrección de la información que sobre éstos se ofrecerá; y si esa información y calidad satisface a las personas que harán uso de esas versiones digitales.
Nos encontramos, en consecuencia, con una serie de variables que deben ser consideradas en dicha fase inicial; y que se articulan en torno a dos ejes: por una parte, la información del documento que es posible reproducir a través de un medio digital; y por otra parte, la información del documento original que los usuarios necesitan para el uso que van a dar a esos documentos, y que debería estar representada en las versiones digitales que se le ofrecen en el medio digital puesto a su alcance. Estas variables son muy dependientes de la concepción que los responsables del proceso de digitalización tienen de la naturaleza de los propios documentos que van a ser difundidos y de las necesidades de los usuarios con respecto a éstos.
Los elementos físicos del documento desde el punto de vista material a considerar son: el soporte, el medio de escritura o representación gráfica empleado, los trazos que conforman el texto escrito o elementos gráficos, la información textual o gráfica incrustada en soporte (marcas de agua), y cualquier otro elemento añadido al soporte (sellos, recortes…)
En proceso diferenciamos las siguientes fases: caracterización física del documento a digitalizar, definición de las técnicas y parámetros más adecuados para la captura digital y el control de calidad de los productos digitales, definición de procesos de restauración digital a realizar en las versiones de legibilidad mejorada de los documentos, definición del protocolo de digitalización, proceso de digitalización, obtención de las diferentes versiones digitales del documento (texto, imagen y audio) , control de calidad y corrección de resultados o repetición de procesos.

Guía para la digitalización de textos
http://www.katarsis-net.com.ar/archivos/guia-para-la-digitalizacion-de-textos.php#more-133

Tratamiento y ajuste de textos digitalizados
http://www.quesabesde.com/camdig/articulos.asp?articulo=166

Convertir de texto a voz
http://vozme.com/index.php?lang=es

1. En que difiere la digitalización de imágenes con la digitalización de textos?

2. Realice un gráfico explicativo del procedimiento de digitalización de texto. Aclare cuales son los elementos hardware y software que intervienen.

Wired Science . Education | PBS

In Your Classroom: Audio Files

Wired Science . Education | PBS

Blogged with the Flock Browser

vozMe – De texto a voz

vozMe – De texto a voz

Blogged with the Flock Browser
A %d blogueros les gusta esto: