Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

How to make a one bit per pixel image file?


  • Please log in to reply
4 replies to this topic

#1 raphaelta

raphaelta

  • Members
  • 2 posts
  • OFFLINE
  •  
  • Local time:11:38 AM

Posted 29 September 2016 - 05:19 AM

Hiya!

 

I am trying do make a black and white pixelated image, with 10x10 pixels, which should have a final size of around 100 bits, from simple my calculations.

 

I created a 10x10 pix canvas on SketchBookExpress and then did the black/white drawing on Paint (probably could have done all in paint, but nevermind). Then I used IrfanView to get the color depth down to 2 and saved the file as .bmp

 

The thing is, now the file has 102 bytes. So it seems like its using 8 bits (1byte) per pixel + some addressing (?).

 

How can I have a 100-bit sized image file?

 

Or, straightforwardly: What image format\configuration can I use to have a 1 bit per pixel image?

 

Thank you in advance!



BC AdBot (Login to Remove)

 


#2 hamluis

hamluis

    Moderator


  • Moderator
  • 55,758 posts
  • ONLINE
  •  
  • Gender:Male
  • Location:Killeen, TX
  • Local time:09:38 AM

Posted 29 September 2016 - 08:08 AM

I use a graphics editor to adjust pixels/bits for an image.  Using Paint, you may not be able to refine the size as efficiently as you would be able to do by using a graphics editor.

 

Moved topic to a forum where you may get better answers to your question.

 

Louis



#3 Platypus

Platypus

  • Moderator
  • 14,502 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Australia
  • Local time:12:38 AM

Posted 29 September 2016 - 09:57 AM

The thing is, now the file has 102 bytes. So it seems like its using 8 bits (1byte) per pixel + some addressing (?).


No, I don't think so. There is more overhead than that in a .bmp file. There are two mandatory headers, a Color Table when Bits per Pixel is 8 or less (as it is here) and row sizes are padded to multiples of 4, so your rows of 10 will occupy 12 bits each and total 15 bytes in the pixel array.

https://en.wikipedia.org/wiki/BMP_file_format

How can I have a 100-bit sized image file?

Or, straightforwardly: What image format\configuration can I use to have a 1 bit per pixel image?


A 100-bit sized file will simply be a 13 byte binary file containing a bitmap and four padding bits, it will not be of any image format. An image format incorporates data to define how the bitmap must be rasterized to produce an image. A bitmap on its own is simply a matrix of values that could be interpreted in many different ways.

The second way of putting it is actually a different question, and it looks to me like you have a 1 bit per pixel image file with the .bmp you created.

Top 5 things that never get done:

1.


#4 raphaelta

raphaelta
  • Topic Starter

  • Members
  • 2 posts
  • OFFLINE
  •  
  • Local time:11:38 AM

Posted 30 September 2016 - 04:43 AM

1) Thank you very much for helping me! =D

 

2) How can I make a 13 byte binary file? And how can I read it as an image later?

 

3) So I found out I was able to change the format to .pbm (which in theory only has 1 bit per pixel, and 2 header bytes) and the file did in fact shrink, but to 29 bytes. Which is still 2x what I would hope. Is there a way to shave off those extra bits?

 

4) I used command line xxd -b to look at the binary code of the image, and since my first row only has 10 black pixels, I was able to find where the first row of the image was (a sequence of 10 ones). This is how the file looks in binary (i've darkened the row I think is the first of the image):

 

01010000 00110100 00001010 00110001 00110000 00100000 
00110001 00110000 00001010 11111111 11000000 11110000 
11000000 11111011 01000000 11111011 01000000 11111100
11000000 11111110 01000000 11110000 01000000 11111110 
11000000 11111110 11000000 11111100 11000000         
 

I realize the first two bytes mean P4, which is the type of .pbm file. But what about the rest?

*Edit: Ok, I actually think I got this one, the first 2 bytes are P4, then there's a '0a' symbol (00001010 in binary) - seems to mean 'line feed' - then 2 bytes for the height, then one byte for space, then another 2 bytes for the width, then that '0a' again.

 

But there's still the question of why are there still 160 bits for the image, instead of only 100 bits after the headers..

 

Once again, thank you very much!


Edited by raphaelta, 30 September 2016 - 05:09 AM.


#5 Platypus

Platypus

  • Moderator
  • 14,502 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Australia
  • Local time:12:38 AM

Posted 30 September 2016 - 08:04 AM

The .pbm format is a good find.
 

But there's still the question of why are there still 160 bits for the image, instead of only 100 bits after the headers.


The bitmap for each row is stored in however many bytes are needed to accommodate the bitcount. Your image has rows of 10, so it takes two bytes to store each row of 10 bits. The remaining 6 bits in each second byte are wasted - as you can see the last 6 bits of each second byte is always 000000. 6 bits unused for each of 10 rows gives you the extra 60 bits bringing 100 bits up to 160.

The problem of having to use a larger structure to hold small amounts of data is called granularity, and in this case it happens because a byte is the smallest data unit a computer can directly access. If your image had rows of 8 pixels, it could be stored in half the space, because each row could be stored in a single byte.

The theoretically smallest result (the 13 byte) requires the bit map to be slid across from each byte into the wasted spaces in the previous byte, which makes it more messy to then extract the parts of each byte that belong to each row. I'd be very surprised if an existing image format bothered doing this, for such reasons as there is no or little benefit if rows are a multiple of 8 or a little under, and for files of any substantial size, other compression techniques can reduce the file size much more.

If you wanted to actually get in and find out how to do such things yourself, you'd need to use a programming language to read and write files, display the results on screen and manipulate individual bits as required using logic functions. That could be interesting, but I found that sort of thing tedious whenever it was required in the little bit of DOS system hobby programming I did many years ago, and my grasp of it all was a bit tenuous.

Edited by Platypus, 30 September 2016 - 09:50 AM.

Top 5 things that never get done:

1.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users