I'm looking for GPS metadata inside a photo. I know I can use ExifTool and many other tools but I want to analyse the photograph at hex level. So I read that Exif metadata is stored in an APP1 section and there may be more than one APP1 section. The application data in an Exif
APP1 section begins with: 45 78 69 66 00 00 So I looked around there, but nothing.
I then looked at the exif-spec for GPS (http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/GPS.html) and it said that latitude is at offset 0x0002. Offset 0x0002 is the header of the JPG (FF D8 FF).
At the top of the top of the exif GPS specs, it says that the tags may be in a different IFD(image
file directory) within the exif information.
So I'm a bit confused now. Anyone know a proven method of viewing GPS exif in hex?
Thanks in advance.
Yes. ExifTool to the rescue:
1) exiftool -htmldump image.jpg > out.html
2) open "out.html" with your favourite web browser
As far as I know, ExifTool is the best (only?) hex dump utility for TIFF/EXIF metadata.
Related
I have been working with dicom files that are about 4 MB each but I recently received some which are 280 KB each. I am not sure whether this is because they are from different CT scanners or if the new dicoms were compressed before being given to me.
Is there a way to find out and if they are compressed is there a way to uncompressed them to the original size?
This is in continuation to the other answer from #kritzel_sw.
If you see any of the following UIDs in (0002,0010) Transfer Syntax UID element:
1.2.840.10008.1.2 Implicit VR Endian: Default Transfer Syntax for DICOM
1.2.840.10008.1.2.1 Explicit VR Little Endian
1.2.840.10008.1.2.2 Explicit VR Big Endian
then the Pixel Data (7FE0,0010) Pixel Data is uncompressed. You will generally observe bigger file size here.
Not a part of your question, but objects other than image (PDF may be in case of Structured Report) can be encapsulated with following Transfer Syntax:
1.2.840.10008.1.2.1.99 Deflated Explicit VR Little Endian
Other well known values for Transfer Syntax mean that the Pixel Data is compressed.
Note that there are also private Transfer Syntax values possible for data set. Implementation of those values is generally private to the respective manufacturer.
Yes and yes.
I recommend the binary tools from the OFFIS DICOM toolkit, but you will be able to achieve the same results with different toolkits. You can find the dcmtk here.
How to find out if your files are compressed:
dcmdump <filename>
Have a look at the metaheader, the attribute Transfer Syntax UID (0002,0010) in particular. Dcmdump "translates" the unique identifier to the human readable transfer syntax, e.g.
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
The Transfer Syntax tells you whether or not the pixel data in this DICOM file is compressed.
How to decompress compressed images:
dcmdjpeg <compressed DICOM file in> <uncompressed DICOM file out>
I have a bunch jpeg image that is obtained from FLIR camera. Along with that images I collected the GPS coordinates also. Now I'm trying to take the GPS latitude and longitude to the metadata of the image.
I wrote a program in R programming language to find the GPS location of each image with respect to the time(when ever the GPS location time and the camera time matches, I took that coordinates).
ie, for a particular image, I have GPSLatitude <- 19.33423 and GPSLongitude <- 72.090834
But now I need to add those exact GPS location to the image.
I tried to do that with Exiftool. I'm using Mac osX sierra. In that I installed exiftool. But now I don't know the how to update GPS data using that.
Can anyone help me. If possible let me know the method to update the data directly from the R programming language itself
Thanks
To add the gps coordinates with exiftool:
exiftool -XMP:GPSLongitude="-84.683333" -XMP:GPSLatitude="10.502117" -GPSLongitudeRef="West" -GPSLatitudeRef="North" photo.jpg
The values are just floating point numbers as got from Google Maps for example.
Result from the thread on the exiftool forum
output <- system(sprintf("exiftool -GPSLatitude=%f -GPSLongitude=%f %s",q,p,aa))
or
output <- system(paste("exiftool -GPSLatitude=",q," -GPSLongitude=",p," ", aa))
When trying to do a similar thing as suggested by Casto Salobreña i got the following error:
$ exiftool -XMP:GPSLatitude=1.2843265 -XMP:GPSLongitude=36.8798949 -GPSLatitudeRef=South -GPSLongitudeRef=East -P test.jpeg
Warning: Truncated PreviewIFD directory. IFD dropped. - test.jpeg
Error: [minor] Bad PreviewIFD directory - test.jpeg
0 image files updated
1 files weren't updated due to errors
to fix this i have dropped the Ref options removing and by changing the South direction (or potentially would need to do the same for West) to a negative number:
$ exiftool -XMP:GPSLatitude=-1.2843265 -XMP:GPSLongitude=36.8798949 -P test.jpeg
1 image files updated
now i test:
$ exiftool -l test.jpeg
...
GPS Position
1 deg 17' 3.58" S, 36 deg 52' 47.62" E
...
In order to deal with latitude and longitude possible negative values, I suggest to first import in XMP, then copy from XMP to EXIF :
(bash code)
exiftool -XMP:GPSLatitude="$latitude" -XMP:GPSLongitude="$longitude" "$image"
exiftool "-gps:all<xmp-exif:all" "-gps:all<composite:all" "-gpsdatestamp<gpsdatetime" "-gpstimestamp<gpsdatetime" "$image"
exiftool -EXIF:GPSAltitude="$altitude" -EXIF:GPSAltitudeRef#="0" -EXIF:GPSMapDatum='WGS-84' "$image"
copy xmp->exif https://exiftool.org/forum/index.php?topic=2257.0
delete gps tags https://exiftool.org/forum/index.php?topic=4686.0
I downloaded the 3GPP AMR-WB codec (26.173) from http://www.3gpp.org/DynaReport/26173.htm and successfully compiled it. However, the file format generated from the decoder is some so-called binary synthesized speech file (*.out). I am wondering what is the exact format and how I can play the the file? Thanks
For AMR-WB, output will be raw PCM with following properties
16000 (16Khz) sampling frequency
1 (mono) channel
16 bits per channel
You can play it using Audacity or any other player which supports PCM input.
When ever we program a micro controller we convert the C file into a hex file and then we burn that into controller.
My question is that why a hex file only, is that hex file a hexadecimal version of binary executable?
If yes then why do not we use a binary file instead?
if you are talking about an "intel hex" file the reason being is that it is ascii which makes it easy to examine and parse. true, it is innefficient in one way but compared to a raw binary it might be smaller. With a raw binary you only have one if any address associated, the starting address (not embedded in the file) in a hex file or motorola srecord which is a similar and often used format as well. both the ihex and srec formats are basically lines of ascii/hex numbers that represent a type a starting address, length data, and a checksum. there are non data lines in there but much of it will be data. so if your program has a few bytes at address 0x1000 and a few bytes at 0x80000000 then a .bin file would be at its smallest 0x8000000-0x1000 plus a few bytes but would typically be 0x80000000+ a few bytes (right, 2 gigabytes). Where an ihex or srec would be in the dozens of bytes total. the ihex and srec have built in checksums to help protect against corrupt files, not perfect of course but better than nothing at all...
Since then elf and coff and other formats have become popular. these are also based on blocks of data and not a complete memory image. these are binary, not ascii formats, but they are not just a memory image. chunks of data with address, type, etc are provided.
Because the ihex and srec are so simple to create and parse they will continue to be used for a long time, it does not take a lot of resources in a bootloader for example to handle receiving an ihex or srec file. (same with a binary of course, but the binary has a lot of fill data in it costing a lot of unnecessary transmission time).
I am trying to write a unix command line utility that will extract the "application" icon from a Windows Mobile executable. When I look inside the .exe with wrestool from the icoutils package, I see multiple icon and group_icon resources. I am trying to figure out which icon the Windows Mobile Programs view would choose to display to the end user.
At first, I figured it would be the icon with name 32512 (IDI_APPLICATION), but then I found several Windows Mobile binaries that lacked this icon resource, but sure enough had visible icons in the Programs view.
Is there a simple but correct algorithm? like lowest resource id? Is there another resource in the .exe that tells me what is the application icon? Is there something obvious that I am missing?
Any insight would be appreciated.
It's the first RT_GROUP_ICON resource in the executable.
Let's show by steps. First, you need to look what is inside your EXE:
wrestool -l file.exe
Normally, the best icon its the first GROUP_ICON, but when the GROUP_ICONs names are words instead of numbers, then is the GROUP_ICON with the biggest size (or the second biggest size if the first GROUP_ICON is blank, you will need to extract both).
wrestool -x -t14 -n(GROUP_ICON name) file.exe > file.ico
If you want to create a perfect code, you probably should include the GROUP_ICON language too (sometimes the exe won't have a language (16-bit applications), so you will need to put both of the codes):
wrestool -x -t14 -n(GROUP_ICON name) -l(GROUP_ICON language) file.exe > file.ico
In some apps, the GROUP_ICON extraction will fail. That's because some new apps (like new games) are using GROUP_ICON as a link, and inserting the real icons inside ICONs. Then, you will need to extract the biggest ICON with that code:
wrestool -x -R -t3 -n(ICON name) -o. file.exe > file.ico
BUT there will be a BIG problem. That will extract the ICON, but a little part of the file will be missing, which is essential to open this file as an .ico. You will need to open that file in a Hexadecimal Editor and insert in the file a little HEX code before everything else.
00 00 01 00 01 00 80 80 00 00 01 00 18 00 28 C8 00 00 16 00 00 00
Probably, now you think this is the end. NO. The worse part is coming: extract the correct pic from the ICO. Firstly, you will need not only wrestool, but icotool. Then, use that code:
icotool -l file.ico
Then, you will need to extract the file with the biggest width, height and bit-depth.
icotool -x -o. -w(Width) -h(Height) -b(Bit-depth) file.ico
The result will be a PNG file with the perfect icon. Sometimes, that code can fail (Example: The program "Robust Motion Deblurring"), then you will need a second conversor to change from ICO to PNG, but that conversor can fail in some cases (Example: The game "Mass Effect"), so you probably will need both in your code.
I have used that logic in an Objective-C program once, so I know that it's functional (and until now, with 99,9% of success).