cc @nigeltao

I'm open to merging 1-bit support, although if it's not too much extra work, it'd be nice to also get 2-bit and 4-bit support.

I'll look into 2/4 bit.

Is writer support needed? It does not seem that the 1/2/4 bit formats are supported in the image pkg, but I may be missing something:

https://golang.org/pkg/image/color/#Model

Writer support is not needed.

When reading, decode to an image.Paletted or image.RGBA, even for 1/2/4 bits per pixel.

But how to write to 1bit then? I'm also missing something. Is there any blog or example you can point us @nigeltao, please?
Because, if using image filters like dithering, you will always get bw 1bit result. With my limiting knowledge, I always end up using image.Gray, and that is not what I need. Looking at image.Gray, I think I see it is defined as h.bpp = 8. How to get it to be 1?

If you really must write 1bpp images, then I think you're going to have to fork the bmp package, as the image package doesn't have a specific representation for 1bpp. Or write your own package. If your input is always going to be 1bpp, writing that particular subset of the BMP file format shouldn't be that complicated.

If you're talking about dithering, it's already possible (using Go's standard and x libraries) to dither to a 2-element palette (black and white). You can either encode that directly, or convert that to your own 1bpp representation.

The thing is, 1bit bmp has its use and purpose. One such is for laser engraver machines.
In particular, I wanted to write the Go variant of uploader/control software for one such, very common device. The same thing exists, thanks to community doing reverse engineering, in almost any language you can imagine, all on github, in Swift, C#, Qt, Python and so on...
But not in Go. I'll simply use different language for this project now, but please, do consider implementing 1bit bmp support. Thank you.

@ALTree @nigeltao I've created a 1/2/4bit bitmap writer.
Can you review it when I sent a PR?

Can you review it when I sent a PR?

I could possibly be persuaded otherwise, but I'll repeat my earlier comment: "If you really must write 1bpp images, then I think you're going to have to fork the bmp package, as the image package doesn't have a specific representation for 1bpp."

Not every useful feature has to live in the Go standard library or the golang.org/x libraries.

@nigeltao
Thank you for your reply :)

Not every useful feature has to live in the Go standard library or the golang.org/x libraries.
Could you tell me why you decline contributes? Is it for maintenance?
I'm thinking 1bit support is not so big change.

IMO, I'm not sure if there's a demand for 2/4 bit bitmap support. However, there is a demand for 1bit bitmap support.
Therefore, I thought this issue was created. Also the above comments say there must be some demands.
Actually, I needed 1bit bitmap, therefore I wrote the writer.
Recently, QR codes are being used everywhere. For example, payment, logistics management and so on.
And sometime it's required 1bit bitmap by special devices.
So there is a worth to support it as a library for golang community.

Could you tell me why you decline contributes? Is it for maintenance?

Partly maintenance, but partly because it's not obvious how to adapt or extend the encoding API in a backwards compatible way, that doesn't involve changes to the standard library (e.g. its image.Image concrete types), but also plays well with current and future encoding APIs and options (e.g. color spaces and other metadata, speed-quality trade-offs, multi-threadedness) for other standard-or-x image libraries, again noting their compatibility constraints.

there is a demand for 1bit bitmap support.

I'm not denying that 1-bit BMPs are a useful feature. To repeat myself, I'm saying that not every useful feature has to live in the Go standard library or the golang.org/x libraries.

I see. Thank you for your reply.

Seems like this PR got stuck on the question of writing 1-bit files, but it does implement reading, which is great for our use case. Is it worth merging? Would love 2 and 4 bit support as well but this is a good start.

I'm OK with that but IIUC it's up to @cbrake to start a PR.

I'm interested in getting this merged, but it would take me some time to get through all the steps to get set up as a Go contributor (review license CLA, set up accounts, etc) as I'm no longer working on this project and don't have funding to do this work. If anyone else is interested, please feel free to use my patch in any way helpful.