Wikipedia:Reference desk/Archives/Computing/2011 May 19

From Wikipedia, the free encyclopedia
Computing desk
< May 18 << Apr | May | Jun >> May 20 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


May 19[edit]

Non-compressed GIF image[edit]

The article GIF#Non-compressed GIF notes that a GIF image file can be constructed by packing the image data with 8-bit indices to the root color table, packed as 9-bit codes with zero MSBs. It works for a small 3x5 image example. Can this be done with large images? I would like to use such a GIF file as a canvass on which pixels are individually addressable for read and write. I encounter these difficulties:

  • Is there a limit to how many indices (pixels) can be represented?
  • Does the clear code 101 100H need to be repeated, if so how often?
  • Data for a large image will be divided into sub-blocks no larger than 1+255 bytes. I chose to write the first byte FCH to be followed by 252 bytes, which contain exactly 224 9-bit codes.

I am doing something wrong because I do not get pixels to show beyond the first sub-block. Cuddlyable3 (talk) 11:10, 19 May 2011 (UTC)[reply]

OT post deleted with explanation given to poster. Cuddlyable3 (talk) 18:54, 19 May 2011 (UTC)[reply]
I sympathize with the desire to create uncompressed files, since they are easier to read in, process with a program, and write back out. However, a GIF file doesn't seem like a good choice for this, as you have to "trick" it into not compressing. I use PPM ASCII format to do the same thing, and it works well, although, of course, you can expect some huge uncompressed files. Since no index is used in PPM, each pixel is defined by it's RGB values. This also allows more than 256 colors per pic (a limitation of an 8-bit index). StuRat (talk) 19:16, 19 May 2011 (UTC)[reply]
OP here. I actually want to have the limited-but-precisely-controlled palette of a GIF file. File size is not a problem because I shall eventually turn the non-compressed GIF to properly compressed GIF. More background info,. There was a past time when people made non-compressed GIFs to avoid a Unisys patent, so maybe someone knows how. Cuddlyable3 (talk) 20:37, 19 May 2011 (UTC)[reply]
Of course, you still CAN limit yourself to 256 colors with a PPM, you just aren't FORCED to do so. (In my case, since I do eventually convert them into an animated GIF, I do limit them to 256 colors, while still a series of PPMs.) StuRat (talk) 20:51, 19 May 2011 (UTC)[reply]
According to your explanation, you want "uncompressed" animated GIFs, which does limit your options. In a 256-color GIF there are initially 258 LZW symbols defined: one for each color, one to clear the LZW state, and one for end-of-stream. Each LZW symbol is encoded in ⌈log2 n⌉ bits, where n is the number of LZW symbols in the table. After each symbol, the table length increases by one. Therefore, if you want the symbol length to remain at 9 bits, you must emit a clear code after every 253 pixels (at most). Your 224-symbol blocks could consist of 223 pixels and one clear code. By the way, the clear code is 100h; 101h is end-of-stream. Maybe that's your bug. -- BenRG (talk) 20:23, 19 May 2011 (UTC)[reply]
The bug that was in my question (corrected by striking) is not in my code. I make the first of the 224 codes in each sub-block 100H. Cuddlyable3 (talk) 20:37, 19 May 2011 (UTC)[reply]
Are you sure they were asking about animated GIFs, as opposed to a single pane ? StuRat (talk) 20:26, 19 May 2011 (UTC)[reply]
I am asking about only a static image GIF here. If that image is destined to be a frame of an animated GIF, I would certainly compress the animated GIF. Cuddlyable3 (talk) 20:43, 19 May 2011 (UTC)[reply]
It sounds like you're handling the clear codes correctly, which means I don't know what's wrong with your code. If you don't need GIF's animation features then I think you'd be better off with, for example, PPM or BMP or TGA or TIFF, even if the GIF animation software you're using doesn't support those formats. It only takes a single line of code to convert to GIF using ImageMagick after you've finished tweaking the input file. -- BenRG (talk) 17:10, 20 May 2011 (UTC)[reply]
Resolved
 – There is a working example uncompressed gif here. Cuddlyable3 (talk) 11:08, 27 May 2011 (UTC)[reply]

Mobile phones in proximity connect as walkie-talkies?[edit]

Is it conceivable that mobile phones (particularly Android-running) in proximity could connect directly to each other to talk at no cost to the user, without any special or additional hardware? --129.215.47.59 (talk) 16:44, 19 May 2011 (UTC)[reply]

Yes, this is how sharing data via bluetooth works, for example. ¦ Reisio (talk) 17:05, 19 May 2011 (UTC)[reply]
So they'd have to be within a few meters of each other, then? The signals would be sent using the bluetooth transmitter, rather than the transmitter which communicates with mobile telephone masts? --129.215.47.59 (talk) 17:23, 19 May 2011 (UTC)[reply]
"for example". Most (all?) of these phones also have "wireless hotspot" features, which effectively makes them into wireless routers, which wouldn't be using bluetooth. ¦ Reisio (talk) 05:16, 20 May 2011 (UTC)[reply]
For the record, cellular band radios are not permitted for use as walkie-talkies. (These radios operate in a controlled spectrum, in the United States, this is governed by the NTIA, and you can see their frequency allocation chart). If a device wishes to support point-to-point radio, it will need additional electronic circuitry so that it can transmit on a different frequency. Many devices do support multi-band radios, and some even do support cellular telephony. Such devices are not usually sold as "cellular telephones." A good example of such a device is the radio system in a commercial taxi-cab in the United States - it is often both a point-to-point VHF or UHF transceiver and a cellular telephone (... two or more radios in one single package). Nimur (talk) 15:29, 20 May 2011 (UTC)[reply]
There is an app called "Virtual Walkie Talkie". It requires WiFi access, and, unless you want to set up your own server on your local network, internet access as well. Note that you can use one of the phones as a server, so you don't need additional hardware; it just makes it easier. -- 188.99.196.147 (talk) 20:37, 20 May 2011 (UTC)[reply]

Google Chrome inserts an extra line break when adding a comment to a talk page[edit]

Does anyone know why Google Chrome inserts an extra line break when adding a comment to a talk page? For example, when I typed this,[1] I had only one blank line between my post and the previous one. By the time I submitted it, it changed into 2 blank lines which I fixed in my next edit.[2] Does anyone else have this problem or know how to fix it? A Quest For Knowledge (talk) 17:01, 19 May 2011 (UTC)[reply]

Sounds like a bug in our JS, I'd talk to WP:VP/T ¦ Reisio (talk) 17:07, 19 May 2011 (UTC)[reply]
Yeah, I'd noticed this too.  ajmint  (talkedits) 18:37, 19 May 2011 (UTC)[reply]