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 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 ;
...
for (c=0x80 ; c ; c>>=1){
if ((currentcolor&c)==(octet&c)) incrmntcurrentRunlength();
else startNewRunlength();
}
....
}

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

 

[Bartc]

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 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 ;
...
for (c=0x80 ; c ; c>>=1){
if ((currentcolor&c)==(octet&c)) incrmntcurrentRunlength();
else startNewRunlength();
}

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);
}

 

[Willem]

Bartc wrote:
)> currentcolor =WHITE
)>
)> for (i=0 ; i<bitImageSize ; i++){
)> octet=bit_image ;
)> ...
)> for (c=0x80 ; c ; c>>=1){
)> if ((currentcolor&c)==(octet&c)) incrmntcurrentRunlength();
)> else startNewRunlength();
)> }
)
) 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]

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