finding color of bits

[harryos]

hi
i am reading thru a book on digitizing text lines using c code.They
use a font data file containing unsigned char fonts [][16] with
elements like 0x00,0x7e,0x81 etc to represent each character .After a
text line is scanned 16 times the equivalent codes are stored in an
unsigned char[] bitImage.
Now the digitized line stored in bitImage is taken 1 character at a
time(ie 8 bits) and color of each is to be determined whether black or
white.
The book says that 'quickest method will be to write assembler code to
shift each octect(ie bitImage[i] in a for loop of i=0 to
i<bitImageSize ) left 8 times so that carry flag will have color of
each bit'.The book says that no high level language can access the
carry flag and so a different method needs to be found.

I didn't quite understand that part.can someone clarify..?

The book continues to point out that 'bits in each octect can be got
by shifting it and ANDing with a constant'.Being new to bit
manipulation etc i couldn't quite write the code.if someone can help
pls do.

Finally the book comes up with a solution ,defining an unsigned char
c =0x80 and uses it as below

....
#define WHITE 0x00
#define BLACK 0xff
....
unsigned char octet ;
unsigned char *bit_image ;
....
currentcolor =WHITE

for (i=0 ; i<bitImageSize ; i++){
octet=bit_image[i] ;
...
for (c=0x80 ; c ; c>>=1){
if ((currentcolor& c)==(octet&c)) incrmntcurrentR unlength();
else startNewRunleng th();
}
....
}

if somebody can explain what happens in this loop it would be a great
help..Being a beginner in c/bit manip etc i find it a little difficult
to understand these..

thanks in adv
harry

[pete]

Re: finding color of bits

harryos wrote:

The book continues to point out that 'bits in each octect can be got
by shifting it and ANDing with a constant'.Being new to bit
manipulation etc i couldn't quite write the code.if someone can help
pls do.

Least Bit == octet >0 & 1
Next bit == octet >1 & 1
Next next bit == octet >2 & 1

or

Least Bit == (octet & 1) != 0
Next bit == (octet & 2) != 0
Next next bit == (octet & 4) != 0

--
pete

[Bartc]

Re: finding color of bits


"harryos" <oswald.harry@g mail.comwrote in message
news:079248d4-6194-4c66-8304-e38817fbfa89@s3 3g2000pri.googl egroups.com...

hi
i am reading thru a book on digitizing text lines using c code.They
use a font data file containing unsigned char fonts [][16] with
elements like 0x00,0x7e,0x81 etc to represent each character .After a
text line is scanned 16 times the equivalent codes are stored in an
unsigned char[] bitImage.

So each of these numbers represents 8 horizontal bits of one 'scanline' of a
character. A 1 might indicate Black and a 0 might indicate White (or vice
versa, since it depends on whether you're displaying black text on a white
background, or white text on black).

The book says that 'quickest method will be to write assembler code to
shift each octect(ie bitImage[i] in a for loop of i=0 to
i<bitImageSize ) left 8 times so that carry flag will have color of
each bit'.The book says that no high level language can access the
carry flag and so a different method needs to be found.

That sounds like nonsense. Looking at your 0x7E, the bits here are 01111110,
bits 7 to bits 0, although they will likely represent pixel 0 to pixel 7 if
you number them left-to-right on the screen. So the leftmost pixel is White,
and the next six are Black, and finally White again.

currentcolor =WHITE
>
for (i=0 ; i<bitImageSize ; i++){
octet=bit_image[i] ;
...
for (c=0x80 ; c ; c>>=1){
if ((currentcolor& c)==(octet&c)) incrmntcurrentR unlength();
else startNewRunleng th();
}

There's too much superfluous code here, and it seems concerned with some
compression scheme.

The essence of it is here, where M contains the current pattern (eg. your
0x7E example from above), or the 'octet':

int M=0x7E;
int i;
int colour;
#define BLACK 0XFF
#define WHITE 0X00

for (i=0x80; i!=0; i>>=1) {
colour = (M & i) ? BLACK : WHITE;
printf("%d ",colour);
}

--
Bartc

[Willem]

Re: finding color of bits

Bartc wrote:
) "harryos" <oswald.harry@g mail.comwrote:
)currentcolor =WHITE
)>
)for (i=0 ; i<bitImageSize ; i++){
) octet=bit_image[i] ;
) ...
) for (c=0x80 ; c ; c>>=1){
) if ((currentcolor& c)==(octet&c)) incrmntcurrentR unlength();
) else startNewRunleng th();
) }
)
) There's too much superfluous code here, and it seems concerned with some
) compression scheme.

FAX, perhaps ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[harryos]

Re: finding color of bits

Ernie,
thanks for the detailed reply..it was a lot,lot helpful...
Willem was right..it was a book about Fax and it uses modified huffman
codes for compression..

thanks again
harry