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:

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.

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

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

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)

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.

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 (10×10)

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.

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.

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.

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.)

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 (10×10)

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.

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.

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.

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.

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.

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.

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.

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.

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…

Campaña “Internet Segura” CEG

Para una navegación responsable, provechosa y divertida. Campaña “Internet Segura” del Complejo Educativo “Dr. F. de Gurruchaga” – Rosario

Con alumnos de 2do, 3ro y 4to del área Informática del CEG.

Excelente experiencia!

 

 

 

Campaña “Internet Segura” CEG.

Curso de Lógica binaria

Lógica binaria.

 

1. Introducción
Señales analógicas y digitales

2. Código binario, decimal  y hexadecimal
Introducción
De binario a decimal
De decimal a binario
Sistema hexadecimal

3. Tabla de verdad
La tabla de verdad

4. Funciones lógicas
Operaciones lógicas básicas
Función lógica vs  tabla de verdad
Tabla de verdad vs función lógica
Álgebra de Boole

huffman code

 

 

 

 

 

 

 

beluga computing – code – applets – huffman code.

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

 

 

Copiad malditos! Documental

http://alt1040.com/2011/04/copiad-malditos

Posted from WordPress for Android

Aprender a programar con Hackety Hack via reddit.com

Learn to program with Hackety Hack via reddit.com.

Run Android on Your Netbook or Desktop – How-To Geek

 

 

Run Android on Your Netbook or Desktop – How-To Geek.

TP Malware

TP Malware

Trabajo grupal con 2 integrantes

http://www.hackerhighschool.org/lessons/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

http://www.mindomo.com/

http://bubbl.us/

http://www.mindmeister.com/es/home

http://www.bbc.co.uk/scotland/pinball/

http://www.exploratree.org.uk/

http://www.spinscape.com/

http://wisemapping.com/c/home.htm

• 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

Cree a Virtual Private Network (VPN) en Windows

Cree a Virtual Private Network (VPN) in Windows

Las Redes Privadas Virtuales o VPN  permiten a los empleados conectarse de forma segura a sus computadoras de escritorio o portátil de la red de la oficina desde cualquier lugar del mundo utilizando una conexión a Internet normal.

Si está trabajando desde su casa, puede conectarse a la red corporativa a través de VPN y tendrá acceso inmediato a sus correos electrónicos, páginas web internas, unidades de red, y otras cosas que de otro modo sólo está disponible en las computadoras dentro de los locales de oficina. Algunos clientes VPN también permiten compartir la pantalla y el acceso remoto para facilitar la comunicación entre los miembros del equipo.

Podemos crear una VP free usando  Gbridge – para Windows y puede usarla con Google Account.

vía How to Setup a Virtual Private Network (VPN) in Windows – Step by Step Guide.

Remote Access | GoToMyPC

Remote Access | GoToMyPC.

How to Fix Your Relatives’ Terrible Computer – Repair – Lifehacker

How to Fix Your Relatives’ Terrible Computer – Repair – Lifehacker

Computer won’t boot, needs a re-install

The problem: Turning on the computer results in a message that states Windows can’t boot because something is missing (a boot loader, an important file, etc.) or something is wrong. There are many variations on this message, but they all say basically the same thing: You will not be getting into Windows.

Quick-fix triage: Load the original XP, Vista, or Windows 7 (Really? Broken already?) CD or DVD in the system and boot the system from there, which might require hitting a key to bring up “boot options” or pressing a key when asked to “Press any key to boot from CD.” Wait for the CD to load—it may seem like it’s installing, but it’s just loading a mini-system for installation and, in this case, repair. Follow the prompts to repair an existing installation, or, in the case of Vista or 7, ask it to repair the startup process.

What you’ll need:

• XP, Vista, or Windows 7 installation CD/DVD: It may be from a computer manufacturer and not look like a Microsoft-obtained, holograph-packed disc, so look around a bit. If it’s a “System Restoration” disc, be sure that you can boot from it and install a full copy of Windows from it.
• USB thumb drive: At least 1GB in size.
• External USB drive or blank DVDs: For backing up important files.
• Ubuntu Live CD or Knoppix Live CD: Both are Linux distributions, but we’re just using them because they run on most kinds of hardware without installing, and can transfer the files you need to your backup media. Ubuntu should work; if it doesn’t, give Knoppix a go. You can use the free tool UNetBootin to transfer the ISO you downloaded to a thumb drive, which is necessary if you’re backing up to DVDs, and recommended in any case to speed things up.

  If that doesn’t work, and you really feel this system can boot again except for some silly error, try creating an Ultimate Recovery CD, as detailed at the How-To Geek’s home away from Lifehacker.

  If that worked, hooray! If not, soldier on to the next step.

  Back up the files: Have your USB hard drive or blank DVDs handy, and remove the Windows CD/DVD from the computer if you tried to use that for a fix. Stick your thumb drive with the Ubuntu (or Knoppix) image into a USB slot, then boot up the computer. You may have to hit F12 or another key to boot from USB, or change a setting in the BIOS (which you can access by hitting a key—written in that fast-disappearing text—at boot-up). You’ll be asked to choose a language, then hit the option to “Try Ubuntu without any changes.” After some loading, you’ll arrive at an Ubuntu desktop.

  Move your cursor to the “Places” menu, and check to see that your USB drive (MyBook, in my case) or blank DVD is showing up. You should also see the hard drive Windows is running from. On an XP or Vista system, there’s usually just one, but on Windows 7, there are two—a “System Reserved” (fairly small) and a larger, main drive. Check to see that you can open and access those files as well.

  Ask your relatives which files and documents are important to them. When doing my own tech support work, I usually back up the entire “My Documents” folder (with “My Music” and “My Pictures” included), their Outlook or (yes, sometimes) Outlook Express email data (explained here), and their Firefox profile or, more likely, their “Favorites” folder for Internet Explorer (C:\Documents and Settings\Username\Favorites in XP, or C:\Users\Username\Favorites in Vista or 7). In any case, always ask, and make sure there isn’t any software they can’t locate a license for.

  When you’re ready to back up, simply open your USB drive from the Places menu, then open your main Windows drive, and drag files to copy from your Windows system onto the backup medium.

  If you’re burning to DVD, head to the Applications menu in your temporary Ubuntu system, mouse over the Accessories sub-menu, and select “CD/DVD Creator” when it pops up. You’ll get a folder you can drag files you want to burn into, then hit “Write to Disc” to burn them.

  When you’re all done backing up files, head to the menu with the power icon next to it (labeled “Live user,” most likely) and select “Shut Down.” You’ll eventually be prompted to remove your live CD or USB stick—do so, and swap in the Windows installation CD or DVD. Turn off the system, then turn it back on. Follow the instructions to install Windows on the system, erasing whatever partitions or data exist on there at the moment (assuming you’re sure the important stuff is backed up).

  Clogged with crapware

  The problem: The computer boots up … eventually. Programs open very slowly, the hard drive seems to click and whir endlessly, and messages, reminders, and pop-up windows jump onto the screen every few minutes.

  Quick-fix triage: If you don’t suspect there’s anything actually malicious and infectious on the system—that is, you’re fairly sure they’ve been running and updating an anti-virus and anti-malware client—grab a copy of Revo Uninstaller Portable (direct ZIP file link), and run it off the USB stick you brought with you.

  Click the “Tools” button, choose the Autorun menu on the left, and look through the items on the right. Uncheck the stuff that’s really unnecessary—most of it, really, unless they constantly use a printer/scanner or run an antivirus app—and remind your host to un-check the toolbars and “helper” apps offered when installing things.

  If things are much better now, and you don’t imagine that malware is an issue, you’re all done. Otherwise …

  What you’ll need: Mostly a small batch of software, recommended by this author and the How-To Geek. You can run these once and remove them, or run them off a thumb drive, in some cases. The last download is one you’ll keep installed on the system.

  • Revo Uninstaller Portable: Completely, utterly removes the programs, toolbars, and other junk apps that aren’t needed.
  • SuperAntiSpyware: For cleaning (you guessed it) spyware.
  • Malwarebytes (or its portable version): For the clingy cookies, add-ons, and apps that try and do unauthorized stuff.
  • CCleaner Portable: For freeing up hard drive space and clearing out temp/cache files that bog down the system index.
  • Microsoft Security Essentials or Panda Cloud Antivirus: The former for a system that’s got enough horsepower to be adequate, the latter for a system that’s light on resources.

  The fixing process? It’s nothing special, actually—just run the quick-fix triage in any case, removing the auto-run apps that bog down system resources, and then run these secondary apps, generally in the order they’re listed. Keep Security Essentials or Panda Cloud Antivirus installed (not both!), and, while you’re being helpful, back up this computer’s pictures, music, and important documents.

  Tuning up and bomb-proofing

  Maybe everything technically “works,” but watching your relatives open emails in Outlook Express and browse on Internet Explorer 6 is just, well, painful. Here are the steps we recommend to get things moving:

  • Run the basics of the “clogged with crapware” section: The one involving Revo Uninstaller and startup programs, under the “quick-fix triage” sub-section, and installing either Microsoft Security Essentials or Panda Cloud Antivirus.
  • Install Firefox and make it the default: Be sure to use the bookmark and setting import from Internet Explorer. You could even go with Google Chrome for even tighter security and speed, if your relatives wouldn’t mind the abrupt shift in look and feel.
  • Set up their email in Gmail: Gmail has made it much easier to import email accounts, whether they’re AOL, cable company, or other defaults that just stuck around. You can make a simple switch in the settings to keep your relatives receiving and sending email from their same address (or multiple addresses). Save their Gmail password in Firefox, but make sure they know it, and they’ll even get some new-fangled email portability.
  • Physically clean the beast: Stop by the local office store, grab a can of compressed air, and clean out the “dust bunnies”, especially if you can hear the exhaust fans over the mid-day football.
  • Replace cruddy programs with superior alternatives: Gina’s 2008 recommendations still hold up, but we updated them a bit, and made them super-easy to install in one shot, with our Lifehacker Pack 2009. Or use Ninite for a similar one-click awesomeware package.

Blogged with the Flock Browser

Install Windows 7 Via USB Stick | TechToggle – Its All About Technology

Install Windows 7 Via USB Stick | TechToggle – Its All About Technology

Blogged with the Flock Browser

Trabajo Práctico Evolución de los Procesadores y los Sistemas Operativos

Trabajo Práctico Evolución de los Procesadores y los Sistemas Operativos

http://www.kbglob.com/gnulinux/evolucion-de-los-sistemas-operativos/

• Realizar en una hoja de calculo de http://docs.google.com un cuadro comparativo con las siguientes caracteristicas de los procesadores: año, empresa, modelo, cantidad de transistores, velocidad, bus de datos, bus de direcciones, memoria, dispositivos de almacenamiento, precio, sistema operativo, imagen.

• Detallar los requerimientos mínimos de cada versión de S.O.

• Crear un video sobre evolución de los sistemas operativos en http://animoto.com/

http://es.wikipedia.org/wiki/Microprocesador
http://www.pcworld.com.ve/n21/articulos/intel.html
http://orbita.starmedia.com/~osander/Historia1.htm
http://www.alpertron.com.ar/INTEL.HTM
http://www.conozcasuhardware.com/quees/micro1.htm
La historia de la PC
http://www.kbglob.com/gnulinux/evolucion-de-los-sistemas-operativos/
http://es.wikipedia.org/wiki/CP/M

TP Aplicaciones portables

TP Aplicaciones portables

Qué son?
Cuál es su uso?
Cómo funcionan?
Qué dispositivos se necesitan?

• http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_port%C3%A1til
• http://www.mouse.cl/2005/productos/09/09/index.asp

Analizar categorías
Seleccionar una aplicación de cada tipo y explicar su uso

• http://www.lupopensuite.com/suite.htm
• http://portableapps.com/apps
• http://www.pendriveapps.com/
• http://es.wikipedia.org/wiki/Lista_de_aplicaciones_port%C3%A1tiles

Descargar suit:

• http://www.lupopensuite.com/index.htm
• http://portableapps.com/suite
• http://www.programasportables.com/

Trabajos Prácticos Software Libre

TP Nº 1 Documental Software Libre

http://alefalletti.wordpress.com/2008/02/18/tp-documental-software-libre/

TP Documental Software Libre « HiperEidon

Documental código linux

Presentar un informe del contenido del documento.

Preguntas a responder:

1. ¿Qué medio de comunicación usa la comunidad Linux para estar constantemente en contacto? ¿Hubiera existido Linux si este medio de comunicación no hubiera existido? ¿Qué piensas tu?

2. ¿En qué otro sistema operativo (muy importante) anterior se basó Linus para crear Linux?

3. ¿Por qué Linus decidió compartir Linux libremente por la red y no venderlo?

4. ¿Qué primer nombre quería darle Linus a Linux?

5. La gente que programa linux no lo hace por dinero ¿Por qué trabajan en eso entonces?

6. ¿Por qué los paises menos desarrollados o con menos recursos están usando Linux mas que Windows?

7. ¿Cuál es tu opinión sobre todas las personas que aparecen en el documental?

¿Qué es un petabyte?

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

Blogged with the Flock Browser

Ninite Easy PC Setup and Multiple App Installer – Great For Win7 Upgrades

Ninite Easy PC Setup and Multiple App Installer – Great For Win7 Upgrades

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