The exiftool command below 'works' in that the data gets written to the file (see grep below). However, Finder, Photos and Adobe Lightroom don't recognize that the image has a position. Why not?
I took all of these values from an image that was taken with iphone and stamped 'correctly' - and that file shows position data in all of the programs above. There are seemingly hundreds of other exif attributes, so I'm not sure what's missing or invalid.
exiftool \
-GPSLongitude="110 deg 12' 12.40\" E" \
-GPSLatitude="7 deg 36' 28.92\" S" \
-GPSLatitudeRef="South" \
-GPSLongitudeRef="East" \
-GPSDateStamp="2019:06:04" \
-GPSTimeStamp="08:09:53" \
-GPSStatus="Measurement Active" \
-GPSMeasureMode="3-Dimensional Measurement" \
-GPSMapDatum="WGS-84" \
-GPSDifferential="No Correction" \
screenshot1.png
1 image files updated
exiftool screenshot1.png | grep GPS
GPS Version ID : 2.3.0.0
GPS Latitude Ref : South
GPS Longitude Ref : East
GPS Time Stamp : 08:09:53
GPS Status : Measurement Active
GPS Measure Mode : 3-Dimensional Measurement
GPS Map Datum : WGS-84
GPS Date Stamp : 2019:06:04
GPS Differential : No Correction
GPS Date/Time : 2019:06:04 08:09:53Z
GPS Latitude : 7 deg 36' 28.92" S
GPS Longitude : 110 deg 12' 12.40" E
GPS Position : 7 deg 36' 28.92" S, 110 deg 12' 12.40" E
The problem in this case is that you are using a PNG file. Software support for metadata in PNG files is lacking in most cases. If you convert it to another format, for example, TIFF, which would be a lossless conversion, then you would probably have better results.
Additionally, you might also try adding the data to the XMP group, which might give you better results with Lightroom (though probably not with the others) as XMP is an Adobe creation. Change your commands so that they have an XMP: prefix (i.e. XMP:GPSLongitude, XMP:GPSLatitude). Additionally, you would have to use XMP:GPSDateTime instead of the separate GPSDateStamp and GPSTimeStamp tags and drop the Ref tags (GPSLatitudeRef,GPSLongitudeRef, though keep GPSAltitudeRef if you have it) as XMP tags include the reference direction directly in the tag.
Related
I am doing a steganography challenge. I have a jpeg file, and when I look the metadata of it with Exiftool, I see something interesting.
Red Tone Reproduction Curve : (Binary data 64 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 64 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 64 bytes, use -b option to extract)
So I thought that maybe there is something interesting there, but I am not sure on how to extract that binary data. When I use the following command: exiftool -b -RedTRC nameOfThePicture.jpeg, then I get this message: curv ck ?Q!)2;FQw]kpz|i}0.
I think that message can be something but I don't how to extract that binary data and which type of file could it be. Any help?
That "message" is simply the binary data of that tag displayed on the command line. The curv part is the ID value for the TRC (see example code, specifically tagbase.sig = swap((long)0x63757276L); /*’curv’*/).
To extract that data to a file, you just need to redirect the output.
exiftool -b -RedTRC nameOfThePicture.jpeg >RedTRC.dat
I've got the following gps data
lat
178197561,44201
long
41176829,78193
And I'm not able to map this to any gps coordinates.
The location is somewhere in germany but I don't have an exact location
The format is milliseconds. To get GPS-coordinates the following python function can be used.
from decimal import *
def convert_to_degree(mil):
return Decimal(mil / (60*60*1000))
The comma has to be replaced with a dot beforehand.
For a detailed explanation this post might help
Convert between Degree and Milliseconds
So I used exiftool -all= command line tool to remove the metadata from an image. However, when I print the metadata of the resulting image, I get this:
$ exiftool myimage.jpg
ExifTool Version Number : 11.30
File Name : myimage.jpg
Directory : out
File Size : 2.8 MB
File Modification Date/Time : 2019:05:16 03:34:02-07:00
File Access Date/Time : 2019:05:16 03:34:02-07:00
File Inode Change Date/Time : 2019:05:16 03:34:02-07:00
File Permissions : rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
DCT Encode Version : 100
APP14 Flags 0 : [14]
APP14 Flags 1 : (none)
Color Transform : YCbCr
Image Width : 3729
Image Height : 2246
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:4:4 (1 1)
Image Size : 3729x2246
Megapixels : 8.4
I am wondering a few things:
If it is required at some level to have all of this (albeit minimal) metadata. That is, I'm wondering if we could get even more minimal and really remove all metadata.
If we can't remove all the metadata that remains, I'm wondering if I can at least remove the first 3 attributes (ExifTool Version Number, File Name, and Directory).
If any of this is possible, wondering what tool (preferrably command-line tool) could accomplish this.
Almost all that remaining data is not metadata embedded in the file. They are properties of the image or the underlying OS. Or even in the case of ExifTool Version Number, the version of exiftool you are running. The '-g' and '-G' options can show you which group each tag comes from; in particular, group families 0 and 1 can be used to see the tags that come from ExifTool and file attributes, as well as those embedded in the image file itself.
The items such as permissions, file name, directory, and the time stamps are taken directly from the underlying OS. Those are properties of every single file on the drive. Without them, the file itself does not exist.
The file/Mime type entries are properties of the file that exiftool has created when it figured out what kind of file it is.
Except for the APP14 entries, the rest are data about the image itself. How it is encoded, the format of the encoding blocks, the size of the image, etc.
The only thing that is embedded in this image is the APP14 block. This block contains no data that can identify the origin of the image. But there is a chance that removing it will significantly alter the colors of the image (see this post). It can be removed by adding -Adobe:All= to the command.
Using exiftool, if I have a file named foobar.jpeg and the shell variables lat="37.7708" and lon="-122.451".
What command do I use to set the EXIF metadata for that jpeg file such that its "geotag" / GPS metadata is set with those coordinates.
exiftool "-GPSLatitude=$lat" "-GPSLatitudeRef=$lat" "-GPSLongitude=$lon" "-GPSLongitudeRef=$lon" foobar.jpeg
Because the GPS coordinates tags are unsigned, you need to make sure and assign the values to the relevant GPSLatitudeRef/GPSLongitudeRef tags as well, especially if the location is in the Western and/or Southern hemisphere. Even though these values would normally be set with N/S and E/W, exiftool well accept the raw values and figure out the proper Ref direction from that.
Just trying to re-encode a PNG file with a specific filtering method using image magick command line tool ('convert' tool to be specific).
As per this page , we can set the quality parameter using two decimal figures , first figure being the zlib compression level used when 1-9 is used and the second figure indicates filter method to use (which is used before the compression)
But with the above option used always filter type '0' (i.e no filter) is used when encoding , even when I specify filter type other than '0'.
eg with below command
convert -quality 11 in.png out.png
I should get output image with zlib compression level 1 (which I am not bothered about) and filter type '1' ('sub' type of filtering).
But the out image is always with filter type '0' , even if I change quality level to 11 , 12 ..15 etc (corresponding to filters '1' , '2' ...'5' etc).
Also tried with controls as per this page , but results are same.
Helps are appreciated!
The "filter method" in the IHDR chunk of any PNG file is always 0.
What ImageMagick/GraphicsMagick's "quality" digit controls is the
filter type used in each scanline. So "-quality 11" will produce
a PNG file that has filter_method=0 in IHDR, and "filter_type=1" as
the first byte of each row.
If you have "pngtest" that comes with libpng, you can find out which
filter types are used:
pngtest -m out.png
yields for example
PASS (3396 zero samples)
Filter 1 was used 24 times
Filter 2 was used 478 times
Filter 3 was used 2 times
Filter 4 was used 241 times
libpng passes test
EDIT: There does seem to have been a fleeting problem with ImageMagick. Under version 7.0.2-9, "-quality 11"
is producing an image with all rows having filter_type 0 as you noted.
"-quality 15" does work properly, with all four filter_types being present.
GraphicsMagick, ImageMagick-7.0.3-0, and ImageMagick-6.9.5-9 are working properly.