I have an image with following IFD entries
01 00 00 03 00 00 00 01 09 A0 00 00
01 01 00 03 00 00 00 01 0C B0 00 00
.
.
.
01 0D 00 02 00 00 00 0E 00 00 DF A2
.
.
Here
Tag ID - 010D (which is document name)
Tag type - 0002 (ASCII)
Count -0000000E (14)
Offset address - 0000 DFA2
Similarly, what does last 4 bytes indicates (Value or offset) in IFD entry of 0100 (Image width) and 0101 (Image length)?
This is HaraldK’s comment, which seems to have solved OP’s problem:
You will find this explained in the TIFF 6.0 specification. For the Width/Length cases, the value is a short (0x0003), and the count is 1 (2 * 1 < 4), thus the value is written "in-line". Your image is 0x9a0 * 0xcb0, or 2464 * 3248 pixels. For the DocumentName tag, the value is ASCII, the count is 14, and as this is > 4 bytes (1 * 14 > 4), the following value is an offset, and the real tag value can be found at that offset (0xdfa2).
Related
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
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?
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
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.
I have file like this:
[some_lines_unimportant]
#Field List (hex, dec, bin, char)
00 00 1e 14 0 0 30 20 999909999 000090000 0001-1110
(...)
00 00 3e 01 0 0 62 01 888888888 000088000 0100-1000
[some_lines_unimportant]
I would like to be able to extract f.e 3 lines that are under the #Field list ... line. How can I do that in bash.
EDITED:
this is the file:
# ------------------------------------------------------------------------------------
# ======= Pkt to be transmitted (hex) ================================================
01 00 fe 03 4d 00 00 00 00 02 fe 00 aa 00 00 00 00 00 00 00 04 b8 EOP
# Initiating transfer ...
# ======= Received pkt (hex) =========================================================
02 fe 03 0d 00 fe 00 aa 00 00 00 04 84 00 01 00 10 cc EOP
# ========= Reply pkt fields (hex) ===================================================
Reply SpW Addr:
02
# Initiator Log Addr (1 byte), Proto ID (1 byte), Instr (1 byte), Status (1 byte):
fe 03 0d 00
# Target Log Addr (1 byte), Trans ID (2 bytes MS LS), Reserved (1 byte):
fe 00 aa 00
# Data Length (3 bytes MS to LS), Header CRC (1 byte):
00 00 04 84
# Field List (hex, dec, bin, char, [dec line count]):
00 01 00 10 0 1 0 16 0000-0000 0000-0001 0000-0000 0001-0000 . . . . [ 1]
# Data CRC (1 byte):
cc
# End of Pkt character:
EOP
# ------------------------------------------------------------------------------------
# ######### Transaction time: 0.225 ms
######### End of online test #########################################################
Use grep like this, where -A specifies how many lines AFTER the match:
grep -A 3 "^#Field List" file
#Field List (hex, dec, bin, char)
00 00 1e 14 0 0 30 20 999909999 000090000 0001-1110
(...)
00 00 3e 01 0 0 62 01 888888888 000088000 0100-1000
Or, if you don't want the first line that matches
grep -A 3 "^#Field List" file | sed 1d
00 00 1e 14 0 0 30 20 999909999 000090000 0001-1110
(...)
00 00 3e 01 0 0 62 01 888888888 000088000 0100-1000
The circumflex (or hat, ^) matches the start of the line, i.e. the word #Field must be at the very start of the line for it to be matched.
Use grep with the --after-context/-A argument:
grep -A3 '#Field List'