What is the file format of the 16bit bitmap hex file? - image

I am new to this area; so excuse me if I did not describe the issue well.
I have a hex file which should contain three images (width: 640, height: 333). The hex file is 1.2 MB. So if we do a little calculation, we obtain that each pixel should have 16-bit of data.
Some of hex code of the file is as below:
90 eb 6f 14 02 02 fd fd 4e 01 80 02 00 00 00 00
90 eb 6f 14 82 82 7d 7d 4e 01 80 02 03 00 00 00
90 eb 6f 14 c2 c2 3d 3d 4e 01 80 02 00 00 8e 08
a7 33 0f d4 00 01 00 01 00 01 43 01 f8 03 0e 17
00 01 00 00 00 00 02 00 00 00 00 00 00 00 01 00
00 04 00 00 01 01 00 00 00 00 00 00 00 00 00 00
00 00 01 01 00 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 01 01
00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 01
00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00
00 01 00 00 08 01 00 00 00 00 00 00 00 00 00 00
00 01 00 00 00 00 00 01 00 00 00 00 00 0a 01 00
00 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00
02 00 00 01 00 00 00 01 00 00 00 00 00 00 00 01
As you can see there is a header with 4 row content which 3 of them is similar. the bitmap data begins. The repeating row is repeated another two times in the file. So I assume that the repeating structure is at the beginning of each of 3 images. But the data between these headers are 210 KB, which means 8-bit per pixel. So I read every 8-bit as an tiny integer and set it to rgb of corresponding pixels of images. So I obtained 3 gray images. Also 630 KB of data remains unread in the file.
Here is magnified version of the original image as gray (original version of the picture is colored) and obtained image. As you see, there are some pixels (every other pixel) which are totally different in compare to original pixels, but whole image is almost correct.
So, my questions are as below:
What is the true structure of the hex file? How should I read the hex file?
How can I achieve original colored file?
What is the extra 630 KB of data!? And what is the wrong pixels?!
also here is original image(i.stack.imgur.com/NdBOa.png), original image as gray(i.stack.imgur.com/wDUPB.png) and obtained image (i.stack.imgur.com/lY3ib.png).

Nothing conclusive, but here is what I have found...
If you hex dump the file and look at the start, you find 90eb and if you look for that throughout the file, you get this:
xxd a.raw | egrep "90eb"
0000000: 90eb 6f14 0202 fdfd 4e01 8002 0000 0000 ..o.....N.......
0000010: 90eb 6f14 8282 7d7d 4e01 8002 0300 0000 ..o...}}N.......
0000020: 90eb 6f14 c2c2 3d3d 4e01 8002 0000 8e08 ..o...==N.......
0034340: e773 2bf4 90eb 6f14 c2c2 3d3d 4e01 8002 .s+...o...==N...
0068660: 0301 0100 ca03 0104 90eb 6f14 c2c2 3d3d ..........o...==
The data looks to begin 32 bytes after every 90eb. If the image is 640x333, there will be 213,120 bytes per image. So we can extract the basic planes/channels of the image like this with ImageMagick:
dd if=a.raw bs=1 skip=64 count=213120 | convert -depth 8 -size 640x333 gray:- a.png
dd if=a.raw bs=1 skip=213860 count=213120 | convert -depth 8 -size 640x333 gray:- b.png
dd if=a.raw bs=1 skip=427656 count=213120 | convert -depth 8 -size 640x333 gray:- c.png
Now we have a problem - the individual images are not positioned the same in all three images - you can see that if I animate the 3 frames together like this:
convert -delay 80 a.png b.png c.png -normalize anim.gif
So now I am a bit lost - are there multiple cameras since the viewpoint seems to move?
I don't know - maybe my findings will inspire someone else! Let's see.
Another approach may be to compare the statistics - if you look at the "original" image's statistics, you get this:
identify -verbose original.png | egrep "Red:|Green:|Blue:|mean:|deviation"
Red:
mean: 5.77718 (0.0226556)
standard deviation: 17.0501 (0.066863)
Green:
mean: 13.7015 (0.0537312)
standard deviation: 38.4053 (0.150609)
Blue:
mean: 10.2863 (0.0403386)
standard deviation: 30.1792 (0.11835)
If you now look at the statistics for the a.png, b.png and c.png as extracted above, you get this:
identify -verbose a.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 2.48532 (0.00974635)
standard deviation: 9.00678 (0.0353207)
identify -verbose b.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 10.1611 (0.0398473)
standard deviation: 30.2288 (0.118544)
identify -verbose c.png | egrep "Red:|Green:|Blue:|Gray:|mean:|deviation"
Gray:
mean: 2.26135 (0.00886804)
standard deviation: 7.43093 (0.0291409)
And there doesn't seem to be any correlation between the statistics of the "original" image and the putative "channels" of the extracted images... I think there is more going on here than I can guess.

Related

Lattice ECP5 UART, no signal on terminal emulator

I followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.
I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.
Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.
The following worked for me and it will probably work for others too. I'm assuming you're using openocd.
Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü'
I just post this here for future reference, we're not going to use the stock eeprom.
We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü|
Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:
vendor_id=0x403
product_id=0x6010
filename="eeprom_RS232.bin"
flash_raw=true
With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.
Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:
# this supports ECP5 Evaluation Board
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0xfff8 0xfffb
reset_config none
# default speed
adapter_khz 5000
# ECP5 device - LFE5UM5G-85F
jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
Then, create your svf file as you usually do and flash it with the following command:
sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.
One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.

How can I forge a DHCP Discovery packet using Bash?

I would like to send via network (LAN) a classic DHCP Discover package using command line, in order to trigger a response from any DHCP server listening, so I could capture it with something like (say my IP address is 192.168.0.30 ):
tcpdump -i eth0 host 192.168.0.30 -n -s 0 -vvv -w listening.pcap
I think about this as a simple method to detect rogue DHCP servers on a network.
How can I do this using Bash ?
Further data:
Other tools allowed, but lets try to keep ti simple: NetCat, sed, grep... etc.
Similar example for forging WOL packet: Bash one-line command to send wake on LAN magic packet without specific tool
Full Solution
The solution is similar to 'hacker' with the difference that the UDP Discover package will be generated manually in the shell.
The code is only intended to replace the given MAC of the network card with the form of spaces instead of colons and assigning to a variable (type in Bash):
# manualy:
MAC=ab:ab:ab:ab:ab:ab; MAC=`printf "$(echo $MAC | sed 's/:/ /g')%.0s"`
# or automaticaly:
MAC=`printf "$(echo $(ifconfig -a |awk -v RS= '/eth0/' |awk '/ether/ {print($2)}') | sed 's/:/ /g')%.0s"`
# or simply type (spaces instead of colons!):
MAC="a6 a6 a6 a6 a6 a6"
Using xxd generate a file containing the DHCPDISCOVER package ready to be sent. I use the fact that the checksum is not checked in practice by all DHCP servers. This avoids significant complications with the checksum calculation and its recording. The only element that needs to be changed is the MAC of the network card.
The site was very helpful: DHCP (in Russian)
echo -e $(echo -n -e "01 01 06 00 62 48 94 CA 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $MAC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 01 FF") |xxd -r -p >blobfile
For the DHCPDISCOVER packet to reach the DHCP server without distortion, it must be sent as binary data. Unfortunately, Bash receives some binary sequences as control commands.
HEX codes from 00 to 1F are the range for control characters, different depending on the system. Many of them will be interpreted by BASH, e.g. 1F, 0d etc.
Added to this are control sequences, e.g. 082008 or 610860.
MAC addresses are theoretically 16777216, they usually contain parts identifying the manufacturer and hardware.
There are more and more producers, also computers, there is also the practice of assigning imaginary or generating random MAC addresses. The chance of using control characters is therefore considerable.
This excludes the use of echo Bash*. We will use cat.
cat blobfile | nc -w1 -u -b 255.255.255.255 67
A fragment of the result from Wireshark:
Client MAC address: ab:ab:ab:ab:ab:ab (ab:ab:ab:ab:ab:ab)
Option: (53) DHCP Message Type (Discover)
The solution boils down to 2 lines of code using only cat and xxd and netcat assuming manually entering the MAC address in the shell.
I didn't find a way to make Bash immune to binary data without breaking it. That is why I suggest excluding it from the package sending phase It may make sense to write the generator in C which will get rid of redirection to the file and the cat program and pack everything into 1 line. However, this is not the subject of the question.
EDIT:
The solution to the Bash problem is to install the rc shell from Plan 9. It is very small (96kB), fast, and most importantly, does not interpret binary characters as controlling. I checked on the standard version rc 1.7.4-1 Debian Linux available via apt. Now just follow the instructions below to send the correct DHCP Discover packet without using cat and the stub file, only shell and xxd and nc.
MAC='08 20 08 1f 0d ff'
echo -n -e "01 01 06 00 62 48 94 CA 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $MAC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 35 01 01 FF" |xxd -r -p | nc -w1 -u -b 255.255.255.255 67
Replacement solution - in the name of convenience.
Wouldn't it be easier to scan the network for DHCP servers?
# nmap -sU -p 67 --script=dhcp-discover 192.168.43.0/24 |awk -v RS= '/dhcp-discover/'
result:
Starting Nmap 7.40 ( https://nmap.org ) at 2020-05-29 18:38 UTC
Nmap scan report for 192.168.43.1
Host is up (0.0052s latency).
PORT STATE SERVICE
67/udp open dhcps
| dhcp-discover:
| DHCP Message Type: DHCPACK
| Server Identifier: 192.168.43.1
| IP Address Lease Time: 47m22s
| Subnet Mask: 255.255.255.0
| Broadcast Address: 192.168.43.255
| Router: 192.168.43.1
| Domain Name Server: 192.168.43.1
|_ Vendor Specific Information: ANDROID_METERED
MAC Address: xx:xx:xx:xx:xx:xx (Chiun Mai Communication Systems)
Perhaps it would be more sensible to secure yourself with the use of "dhcp snooping" (layer 2 OSI model ) on the switch, which consists in rejecting any DHCP packets that do not come from a trusted interface.
"Hacker" solution
The question asked raises three issues:
the use of Bash echo
Shipment of the UDP DHCPDISCOVER package
generating the DHCPDISCOVER package
For the DHCPDISCOVER packet to reach the DHCP server without distortion, it must be sent as binary data. Unfortunately, Bash receives some binary sequences as control commands. This excludes the use of echo Bash.
The cat command does not cause this problem as long as the input is from a file (bypassing bash). The package is shipped as follows:
cat blobfile | nc -w1 -u -b 255.255.255.255 67
The package is sent correctly, server DHCP returns the package DHCP Offer. A fragment of the log from tcpdump:
DHCP-Message Option 53, length 1: Discover
and server answer:
DHCP-Message Option 53, length 1: Offer
Where to get the shipping details is a separate matter.
I got them by intercepting DHCPDISCOVER shipping using ncat in such a way:
ncat -l -p 67 --udp >blobfile
Having such a block is enough to send DHCPDISCOVER packets and thus solve the basic task.
To be precise, you would have to write the DHCPDISCOVER package generator, unfortunately RFC 2132 and other has a rather complex structure and recording format - see my "full solution".

Smallest possible valid .tif file

I'm curious about what the smallest possible valid tif file is(still opens without errors, I'm using IrFanView to test validity for this purpose). The smallest I've been able to put together through a hex editor so far is 72 bytes. We're using this for a health check that runs many thousands of times per day, and would like a file as small as possible. I realize at this point, going much smaller would be a trivial difference, but was curious if anything could be trimmed off of this to make it smaller, or if there's a different way to go about making a tiny file. Here's the hex for the image that's 72 bytes:
49 49 2A 00 0A 00 00 00 00 00 05 00 00 01 03 00
01 00 00 00 01 00 00 00 01 01 03 00 01 00 00 00
01 00 00 00 03 01 03 00 01 00 00 00 01 00 00 00
11 01 04 00 01 00 00 00 08 00 00 00 17 01 04 00
01 00 00 00 01 00 00 00
Image here:
lil.tiff
Update:
We've done a little more research and switched to Big Endian Encoding. We've been able to create a 46 byte file using the following:
4D 4D 00 2A 00 00 00 08
00 03 01 00 00 03 00 00
00 01 00 01 00 00 01 01
00 03 00 00 00 01 00 01
00 00 01 11 00 03 00 00
00 01 00 00 00 00
From everything I've seen, attributes 01 10(width), 01 10(height), and 01 11(strip offsets) are required 12 byte attributes. The 03 on line two above indicates the three attributes, changing this to 2, 1, or 0 and removing any combination of the attributes results in an invalid image. I've tried adding compression(attribute 01 13), but apparently the file size is small enough it still results in a loss. At this point, is there anything that can be done to shrink the file size(mostly out of curiosity sake).
New Image Here: Updated 46bytes.tiff

Jpeg values in decimal are being saved but wont display image

I currently took a photo with a camera which returned to me all its values in decimal and after extracting the values my jpeg file are(i converted them to hex here but they were still saved in decimal)
FF
D8
FF
FE
00
24
30
00
9D
08
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
F0
00
40
01
0C
00
32
............
00
54
65
6B
D9
9F
FF
FF
D9
i saved theses value into a file called image.jpg (they were saved in decimal)
however the image file was not able to read it and I can not use the linux command convert as it tells me "Bogus marker length". What would i be doing wrong that doesnt allow me to see the image?

How to convert a PNG to 1-bit BMP

So, I'm trying to understand how PNG to BMP conversion actually takes place. I created the following 8x8 pixel PNG using a tool online:
I then performed a conversion using the ImageMagik tool in OSX terminal:
$ convert -monochrome pic.png pic.bmp
Afterwards, I did a hexdump of the image:
$ hexdump -C pic.bmp
00000000 42 4d 4a 01 00 00 00 00 00 00 8a 00 00 00 7c 00 |BMJ...........|.|
00000010 00 00 08 00 00 00 08 00 00 00 01 00 18 00 00 00 |................|
00000020 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 |................|
00000040 00 00 00 00 00 ff 42 47 52 73 8f c2 f5 28 51 b8 |......BGRs...(Q.|
00000050 1e 15 1e 85 eb 01 33 33 33 13 66 66 66 26 66 66 |......333.fff&ff|
00000060 66 06 99 99 99 09 3d 0a d7 03 28 5c 8f 32 00 00 |f.....=...(\.2..|
00000070 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff |................|
00000090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000130 ff ff 00 00 00 ff ff ff ff ff ff ff ff ff ff ff |................|
00000140 ff ff ff ff ff ff ff ff ff ff |..........|
0000014a
So, obviously we have a BMP header from 0x00 - 0x8C. Then we have FF for white pixels and 00 for black. That all makes sense, but the structure of the output doesn't. So far, it seems that there is a 3 to 1 ratio. 3 bytes per pixel. I'm assuming this means black, white, no-color?
I need to fully understand why there are 3 bytes per pixel instead of 2. Ideally, I would like a binary 1 or 0 for each pixel instead. Is there a way to do this? And if not, can someone please explain the layout of bytes? Specifically: Why are the 3 00s at 0x132 - 0x134 and not the very beginning?
Thanks
Imagemagick, in fact, does support 1-bit BMP, if using either BMP3 or BMP2 formats, but not BMP4 which is just BMP. So if you want 1-bit depth per channel, then do
Input:
convert image.png -depth 1 BMP3:result.bmp
If you want a 1-bit depth for the whole image (i.e. binary), then do
convert image.png -depth 1 -type bilevel BMP3:result2.bmp
Or
convert image.png -depth 1 -threshold 50% BMP3:result3.bmp
I'm not sure which question this will answer, but from the Usage docs
IM can not produce BMP's at depth levels other than 8. However you can
use NetPBM image processing set to do the final conversion to other depth
levels (This needs at least a Q16 version of IM)...
So if we leverage NetPBM
$ convert pic.png -depth 1 ppm:- | hexdump
Which gives (Note the values are 0 & 1, but you still have a RGB channels)
0000000 50 36 0a 38 20 38 0a 31 0a 00 00 00 01 01 01 01
0000010 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
*
00000c0 01 01 01 01 01 01 01 01 01
00000c9
So a workaround my be as simple as
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppm2bmp > pic.bmp
On Fedora 27 that command is:
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppmtobmp > pic.bmp
You need:
$ dnf install netpbm-progs

Resources