By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,015 Members | 1,016 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,015 IT Pros & Developers. It's quick & easy.

finding color of bits

P: n/a
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)) 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
Jun 27 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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
Jun 27 '08 #2

P: n/a

"harryos" <os**********@gmail.comwrote in message
news:07**********************************@s33g2000 pri.googlegroups.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)) 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);
}

--
Bartc

Jun 27 '08 #3

P: n/a
Bartc wrote:
) "harryos" <os**********@gmail.comwrote:
)currentcolor =WHITE
)>
)for (i=0 ; i<bitImageSize ; i++){
) octet=bit_image[i] ;
) ...
) 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
Jun 27 '08 #4

P: n/a
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
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.