To geo-tag a photo, what attributes are required? More than lat/lon? - iphone

I am trying to geo-tag photos taken with the iPhone camera. Since I'm not saving the photos to the camera roll, the photos do not have any EXIF data.
So, what elements are required in valid EXIF data? I think I have written the latitude, longitude, and altitude to the EXIF data, but when I export the photo, there doesn't seem to be any EXIF data.
I suspect that for a service like Flickr to display the EXIF data, I need to add more than just the latitude and longitude or some such foolishness.
Anyone have any experience with writing EXIF data?
EDIT #3: Aha, got it now! Thanks for your help. What I had to do to address EDIT #2 was add the make, model, and software.
EDIT #2: Thanks to the first respondent (who I will give the correct answer two regardless), my photo is now being geo-tagged, but now I have a related question.
The photo gets automatically located when I upload it to Flickr (when I go to map it it suggests the location), but it doesn't show the nice chart of EXIF data.
This photo is geo-tagged. but no nice chart of EXIF data on this page:http://www.flickr.com/photos/33766454#N02/3980488205/.
This one exported from the camera roll shows a More Properties link to show the EXIF data in full: http://www.flickr.com/photos/33766454#N02/3978868900/
Now I'm wondering what I have to do get Flickr (and also Picasa on my desktop) to display the link to see the EXIF data. When I look at the photos properties on my Mac too, I don't see any EXIF data, but I know it's there.
EDIT: Based on the advice in the first two answers, I set the suggested EXIF tags and inspected them in EXIFTool. Unfortunately, though the EXIF data shows up in EXIFTool, it doesn't show up when I upload to Picasa or Flickr. Here is the output from EXIFTool. Any idea what I still might be missing?
~/Downloads: exiftool My_Photo_-_10-4-09_5_22_20AM.jpg
ExifTool Version Number : 7.96
File Name : My_Photo_-_10-4-09_5_22_20AM.jpg
Directory : .
File Size : 287 kB
File Modification Date/Time : 2009:10:04 05:22:51-07:00
File Type : JPEG
MIME Type : image/jpeg
JFIF Version : 1.01
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Exif Byte Order : Big-endian (Motorola, MM)
Orientation : Horizontal (normal)
Color Space : sRGB
Exif Image Width : 319
Exif Image Height : 480
GPS Version ID : 2.2.0.0
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Altitude Ref : Above Sea Level
Image Width : 319
Image Height : 480
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:4:4 (1 1)
GPS Altitude : 0 m Above Sea Level
GPS Latitude : 37 deg 19' 54.08" N
GPS Longitude : 122 deg 1' 50.63" W
GPS Position : 37 deg 19' 54.08" N, 122 deg 1' 50.63" W
Image Size : 319x480

I've done this to geo-tag photos which Picasa will recognise, for Picasa you need to add the following tags:
GPSVersionID ("0 0 2 2 "), GPSlongituderef ("W" or "E"), GPSlatituderef ("N" or "S") and also GPSAltitudeRef ("Above Sea Level")
Values in brackets are the ones I used. These are in addition to the lat, long and altitude tags. As Brian mentions exiftool is excellent for examining and modifying EXIF tags.
EDIT
Output from exiftool:
ExifTool Version Number : 7.01
File Name : bleatarn.jpg
Directory : .
File Size : 3 MB
File Modification Date/Time : 2008:03:01 12:43:44
File Type : JPEG
MIME Type : image/jpeg
JFIF Version : 1.1
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Exif Byte Order : Little-endian (Intel)
Software : Picasa 3.0
Exif Version : 0210
Interoperability Index : Unknown ( )
Interoperability Version : 0100
Image Unique ID : 6fda6fa9628b8615d99abc81663c9b01
GPS Version ID : 0.0.2.2
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Altitude Ref : Above Sea Level
GPS Altitude : 0 m
Caption-Abstract : Blea Tarn
Image Width : 3151
Image Height : 1375
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
GPS Latitude : 54 deg 25' 44.33" N
GPS Longitude : 3 deg 5' 27.44" W
GPS Position : 54 deg 25' 44.33" N, 3 deg 5' 27.44" W
Image Size : 3151x1375
Only difference I can see is that GPS Version ID is different, and you're Big-endian rather than little-endian (that shouldn't matter, should it?)

This may help. It details how to copy the geotagging data to a photo without geotagged data, and details the EXIF fields used by exiftool.

I would also set GPSMapDatum, as the EXIF standard strongly recommends including this tag. The value would be "WGS-84", assuming your coordinates come from a GPS unit or are based on common web maps or any other current source of location data. (If you're using a different datum, it'd be better to convert it to WGS-84 anyway, since I suspect most viewers just assume that to be the datum.)
If you're not familar, a map datum tells how to interpret the latitude and longitude values. Since the earth is not a perfect sphere, there are many ways the coordinates can be interpreted. Using the wrong interpretation can sometimes have a significant effect on where the marker will end up on a map.

Related

Where exactly is the DPI information of an image stored (other than Exif)?

We have been using a program called Onyx RIPCenter to manage poster printing for few years now. The images were generated using Photoshop and loaded onto the Onyx application on Windows.
Recently we dedcied to automate the workflow by eliminating Photoshop and automatically processing the images through a custom application built in python (using pillow python - https://pillow.readthedocs.io/en/latest/)
Now the problem I have is that when I open the images created through the custom application in RIPCenter, I get wrong sizes in millimetre.
The actual size of the image is,
924mm x 2108mm
instead I get,
2309.99mm x 5269.79mm
The reason for this is the wrong DPI read by the application, instead of 180, it reads 72 (actual size in pixels - 6548 x 14938).
The custom application does set all relevant information to the Exif data including DPI. This can be verified by checking the property of the image file in Windows. But somehow when opening the image in RIPCenter, it shows the wrong DPI value.
Here is the code that saves the image.
def save_image(modified_image, image_file, source_image):
"""
Store the processed image into a file
:param modified_image: <Obj> modified image object
:param image_file: <String> output filename
:param source_image: <Obj> original image object
:return: <Boolean> True if saved
"""
# fix Onyx printer error
# https://media.readthedocs.org/pdf/piexif/latest/piexif.pdf
exif_dict = piexif.load(source_image.info["exif"])
exif_dict["0th"][piexif.ImageIFD.XResolution] = (180.0, 1)
exif_dict["0th"][piexif.ImageIFD.YResolution] = (180.0, 1)
exif_bytes = piexif.dump(exif_dict)
# if this is not set, then the save option will throw an error for setting subsampling='keep'
modified_image.format = source_image.format
try:
modified_image.save(
image_file,
icc_profile=source_image.info.get('icc_profile'),
dpi=source_image.info.get('dpi'),
exif=exif_bytes,
format=source_image.format,
subsampling='keep',
quality=95
)
del source_image
del modified_image
return True
except IOError as e:
print(e)
return None
If the same image is opened and saved in Photoshop, then it shows the correct DPI. I have also tried Gimp and I get the same result. The image with the wrong DPI suddenly gets the right DPI when opened and saved in Gimp.
My understanding is that the pixels (height and width) and the DPI values read from the Exif data across different platforms and applications. But could it be possible that the Onyx RIPCenter application is looking for DPI in a different place?
Below is the exif data of the images.
Exif data of the image that's saved in Photoshop,
[ExifTool] ExifTool Version Number : 11.10
[System] File Name : A3-VictoriaGlenManor-RH-Copper-92.4x210.8-R.jpg
[System] Directory : /Users/vinodsudharshan/Downloads
[System] File Size : 34 MB
[System] File Modification Date/Time : 2018:08:24 14:37:25+02:00
[System] File Access Date/Time : 2018:08:27 23:27:08+02:00
[System] File Inode Change Date/Time : 2018:08:27 22:56:37+02:00
[System] File Permissions : rw-r--r--
[File] File Type : JPEG
[File] File Type Extension : jpg
[File] MIME Type : image/jpeg
[File] Exif Byte Order : Big-endian (Motorola, MM)
[File] Current IPTC Digest : cdcffa7da8c7be09057076aeaf05c34e
[File] Image Width : 6550
[File] Image Height : 14940
[File] Encoding Process : Baseline DCT, Huffman coding
[File] Bits Per Sample : 8
[File] Color Components : 4
[IFD0] Image Width : 6130
[IFD0] Image Height : 8400
[IFD0] Bits Per Sample : 8 8 8
[IFD0] Photometric Interpretation : RGB
[IFD0] Orientation : Horizontal (normal)
[IFD0] Samples Per Pixel : 3
[IFD0] X Resolution : 180
[IFD0] Y Resolution : 180
[IFD0] Resolution Unit : inches
[IFD0] Software : Adobe Photoshop CS5.1 Macintosh
[IFD0] Modify Date : 2018:08:23 17:32:21
[ExifIFD] Exif Version : 0221
[ExifIFD] Color Space : Uncalibrated
[ExifIFD] Exif Image Width : 6550
[ExifIFD] Exif Image Height : 14940
[IFD1] Compression : JPEG (old-style)
[IFD1] X Resolution : 72
[IFD1] Y Resolution : 72
[IFD1] Resolution Unit : inches
[IFD1] Thumbnail Offset : 394
[IFD1] Thumbnail Length : 2261
[IFD1] Thumbnail Image : (Binary data 2261 bytes, use -b option to extract)
[IPTC] Coded Character Set : UTF8
[IPTC] Application Record Version : 0
[Photoshop] IPTC Digest : cdcffa7da8c7be09057076aeaf05c34e
[Photoshop] X Resolution : 180
[Photoshop] Displayed Units X : inches
[Photoshop] Y Resolution : 180
[Photoshop] Displayed Units Y : inches
[Photoshop] Print Style : Centered
[Photoshop] Print Position : 0 0
[Photoshop] Print Scale : 1
[Photoshop] Global Angle : 30
[Photoshop] Global Altitude : 30
[Photoshop] URL List :
[Photoshop] Slices Group Name : A3-VictoriaGlenManor-RH-Copper-92.4x210.8-R
[Photoshop] Num Slices : 1
[Photoshop] Pixel Aspect Ratio : 1
[Photoshop] Photoshop Thumbnail : (Binary data 2261 bytes, use -b option to extract)
[Photoshop] Has Real Merged Data : Yes
[Photoshop] Writer Name : Adobe Photoshop
[Photoshop] Reader Name : Adobe Photoshop CS5.1
[Photoshop] Photoshop Quality : 12
[Photoshop] Photoshop Format : Standard
[Photoshop] Progressive Scans : 3 Scans
[XMP-x] XMP Toolkit : Adobe XMP Core 5.0-c061 64.140949, 2010/12/07-10:57:01
[XMP-xmp] Modify Date : 2018:08:23 17:32:21+02:00
[XMP-xmp] Creator Tool : Adobe Photoshop CS5.1 Macintosh
[XMP-xmp] Create Date : 2018:08:21 15:12:04+02:00
[XMP-xmp] Metadata Date : 2018:08:23 17:32:21+02:00
[XMP-crs] Already Applied : True
[XMP-photoshop] Color Mode : CMYK
[XMP-photoshop] ICC Profile Name : U.S. Web Coated (SWOP) v2
[XMP-dc] Format : image/jpeg
[XMP-xmpMM] Instance ID : xmp.iid:9F9A62F1B5206811BF6AFA75AB99E0BD
[XMP-xmpMM] Document ID : xmp.did:9E9A62F1B5206811BF6AFA75AB99E0BD
[XMP-xmpMM] Original Document ID : xmp.did:9E9A62F1B5206811BF6AFA75AB99E0BD
[XMP-xmpMM] History Action : saved, saved
[XMP-xmpMM] History Instance ID : xmp.iid:9E9A62F1B5206811BF6AFA75AB99E0BD, xmp.iid:9F9A62F1B5206811BF6AFA75AB99E0BD
[XMP-xmpMM] History When : 2018:08:23 17:32:21+02:00, 2018:08:23 17:32:21+02:00
[XMP-xmpMM] History Software Agent : Adobe Photoshop CS5.1 Macintosh, Adobe Photoshop CS5.1 Macintosh
[XMP-xmpMM] History Changed : /, /
[ICC-header] Profile CMM Type : Adobe Systems Inc.
[ICC-header] Profile Version : 2.1.0
[ICC-header] Profile Class : Output Device Profile
[ICC-header] Color Space Data : CMYK
[ICC-header] Profile Connection Space : Lab
[ICC-header] Profile Date Time : 2000:07:26 05:41:53
[ICC-header] Profile File Signature : acsp
[ICC-header] Primary Platform : Apple Computer Inc.
[ICC-header] CMM Flags : Not Embedded, Independent
[ICC-header] Device Manufacturer : Adobe Systems Inc.
[ICC-header] Device Model :
[ICC-header] Device Attributes : Reflective, Glossy, Positive, Color
[ICC-header] Rendering Intent : Media-Relative Colorimetric
[ICC-header] Connection Space Illuminant : 0.9642 1 0.82491
[ICC-header] Profile Creator : Adobe Systems Inc.
[ICC-header] Profile ID : 0
[ICC_Profile] Profile Description : U.S. Web Coated (SWOP) v2
[ICC_Profile] Profile Copyright : Copyright 2000 Adobe Systems, Inc.
[ICC_Profile] Media White Point : 0.7084 0.73595 0.57104
[ICC_Profile] A To B0 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] A To B2 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] A To B1 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] B To A0 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] B To A1 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] B To A2 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] Gamut : (Binary data 37009 bytes, use -b option to extract)
[Adobe] DCT Encode Version : 100
[Adobe] APP14 Flags 0 : [14]
[Adobe] APP14 Flags 1 : (none)
[Adobe] Color Transform : YCCK
[Composite] Image Size : 6550x14940
[Composite] Megapixels : 97.9
Exif data of the image that's saved in the Python Application,
[ExifTool] ExifTool Version Number : 11.10
[System] File Name : A3-TEST_2_EXIF-RH-Copper-92.4x210.8-R.jpg
[System] Directory : /Users/vinodsudharshan/Desktop
[System] File Size : 36 MB
[System] File Modification Date/Time : 2018:08:27 21:55:25+02:00
[System] File Access Date/Time : 2018:08:31 16:59:05+02:00
[System] File Inode Change Date/Time : 2018:08:27 22:56:37+02:00
[System] File Permissions : rw-r--r--
[File] File Type : JPEG
[File] File Type Extension : jpg
[File] MIME Type : image/jpeg
[File] Exif Byte Order : Big-endian (Motorola, MM)
[File] Image Width : 6548
[File] Image Height : 14938
[File] Encoding Process : Baseline DCT, Huffman coding
[File] Bits Per Sample : 8
[File] Color Components : 4
[Adobe] DCT Encode Version : 100
[Adobe] APP14 Flags 0 : (none)
[Adobe] APP14 Flags 1 : (none)
[Adobe] Color Transform : Unknown (RGB or CMYK)
[IFD0] Image Width : 6130
[IFD0] Image Height : 8400
[IFD0] Bits Per Sample : 8 8 8
[IFD0] Photometric Interpretation : RGB
[IFD0] Orientation : Horizontal (normal)
[IFD0] Samples Per Pixel : 3
[IFD0] X Resolution : 180
[IFD0] Y Resolution : 180
[IFD0] Resolution Unit : inches
[IFD0] Software : Adobe Photoshop CS5.1 Macintosh
[IFD0] Modify Date : 2018:07:11 17:42:24
[ExifIFD] Exif Version : 0221
[ExifIFD] Color Space : Uncalibrated
[ExifIFD] Exif Image Width : 5669
[ExifIFD] Exif Image Height : 14173
[IFD1] Compression : JPEG (old-style)
[IFD1] X Resolution : 180
[IFD1] Y Resolution : 180
[IFD1] Resolution Unit : inches
[IFD1] Thumbnail Offset : 404
[IFD1] Thumbnail Length : 2076
[IFD1] Thumbnail Image : (Binary data 2076 bytes, use -b option to extract)
[ICC-header] Profile CMM Type : Adobe Systems Inc.
[ICC-header] Profile Version : 2.1.0
[ICC-header] Profile Class : Output Device Profile
[ICC-header] Color Space Data : CMYK
[ICC-header] Profile Connection Space : Lab
[ICC-header] Profile Date Time : 2000:07:26 05:41:53
[ICC-header] Profile File Signature : acsp
[ICC-header] Primary Platform : Apple Computer Inc.
[ICC-header] CMM Flags : Not Embedded, Independent
[ICC-header] Device Manufacturer : Adobe Systems Inc.
[ICC-header] Device Model :
[ICC-header] Device Attributes : Reflective, Glossy, Positive, Color
[ICC-header] Rendering Intent : Media-Relative Colorimetric
[ICC-header] Connection Space Illuminant : 0.9642 1 0.82491
[ICC-header] Profile Creator : Adobe Systems Inc.
[ICC-header] Profile ID : 0
[ICC_Profile] Profile Description : U.S. Web Coated (SWOP) v2
[ICC_Profile] Profile Copyright : Copyright 2000 Adobe Systems, Inc.
[ICC_Profile] Media White Point : 0.7084 0.73595 0.57104
[ICC_Profile] A To B0 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] A To B2 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] A To B1 : (Binary data 41478 bytes, use -b option to extract)
[ICC_Profile] B To A0 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] B To A1 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] B To A2 : (Binary data 145588 bytes, use -b option to extract)
[ICC_Profile] Gamut : (Binary data 37009 bytes, use -b option to extract)
[Composite] Image Size : 6548x14938
[Composite] Megapixels : 97.8
I would suspect that Onyx RIPCenter is using 72 as a default (which is a common default) and that it normally reads Photoshop:X/YResolution to get the DPI. Try copying the IFD0:X/YResolution to Photoshop:X/YResolution or simply setting the Photoshop:X/YResolution to 180.
In exiftool, you could use
exiftool -Photoshop:*Resolution=180 FILEorDIR
The asterisk is a wildcard which will allow both XResolution and YResolution to be set at the same time. Replace FILEorDIR with the files/directories to be processed. This command creates backup files. Add -overwrite_original to suppress the creation of backup files. Add -r to recurse into subdirectories.

Resize image preserving exif data: focal length etc

What converter(like imagemagick) can be used to convert images with exif data preserving it?
What if I downscale images 4 times? Should I also change the focal length?
Data I have extracted from my JPG photo with exiftool
Focal Length : 50.0 mm (35 mm equivalent: 50.0 mm)
EDIT:
Seems imagemagick preserve exif data:
mogrify -resize 25% -path output_foler/ *.JPG
I believe newer versions of Imagemagick should preserve the metadata. A fall back would be to use Exiftool to copy the data with a command like exiftool -tagsfromfile OldFile -all:all NewFile.
Both of those are platform independent. To be more precise with other programs, you will need specify your OS. For example, with Windows, you can use Irfanview to convert images and it will retain most metadata as long as you enable those options.

Find the size of 1 pixel in my CMOS camera

I have a small problem with finding the pixel size of an image. I am to find size of nano and micro particles on my BW image. I used regionprops to get the area - then the diameter. Now i know the value in pixels. How do i convert to micro or nano meter scale? Do I take into account the sensor size(6.5umx6.5um) of my camera?
I use MATLAB for image processing.
Thank you
there is a function called imfinfo which will return a struct. In this struct you will maybe find three fields (it depends on the coder that you used for the image format) called XResolution, YResolution and ResolutionUnit. Using this 3 fields you can easily get pixel size, for example if XResolution=10, YResolution=10 and ResolutionUnit='meter' then you have a 100cm2 pixels (its a bit unreal i know :))
I hope this helps and that your image file contains the XResolution and YResolution information in your header.

How can I avoid that Github rotates my jpg in my readme.md?

I have added a image reference in my readme.md on github. The picture is a portrait format photo, but when I view it on the github page the picture is rotated.
I have tried clone the repo to a new location to confirm that the picture is indeed still portrait as expected in the repo.
The image part of the readme.md:
Here is a picture of the hardware setup. ![picture of the hardware setup](HelloButtonModule.jpg)
This is the affected github repo
Update
Now I am really baffled I tried to simplify the problem in a new repo, but the picture shows up unrotated as (originally) expected.
Update
I have created a repo with an exact copy of the picture. Then the picture is rotated.
You could try simply opening the file and then re-saving it. You may need to rotate 360 degrees before you save, however, this should work.
If you are on a Debian based distro, you can use exiftran.
sudo apt-get install exiftran
exiftran -ai *.jpg
This will automatically rotate all the .jpg files based on their exif data.
I ran
git clone https://github.com/steenhulthin/HelloButtonModule/
cd HelloButtonModule/
exif HelloButtonModule.jpg
and this produced:
EXIF tags in 'HelloButtonModule.jpg' ('Motorola' byte order):
--------------------+----------------------------------------------------------
Tag |Value
--------------------+----------------------------------------------------------
Image Width |4128
Image Length |2322
Manufacturer |SAMSUNG
Model |GT-I9505
Orientation |Top-left
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Software |I9505XXUDMH8
Date and Time |2013:10:16 23:22:57
YCbCr Positioning |Centred
Image Width |512
Image Length |288
Compression |JPEG compression
Orientation |Right-top
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Exposure Time |1/33 sec.
F-Number |f/2.2
Exposure Program |Normal programme
ISO Speed Ratings |100
Exif Version |Exif Version 2.2
Date and Time (Origi|2013:10:16 23:22:57
Date and Time (Digit|2013:10:16 23:22:57
Components Configura|Y Cb Cr -
Shutter Speed |5.06 EV (1/33 sec.)
Aperture |2.28 EV (f/2.2)
Brightness |2.44 EV (18.56 cd/m^2)
Exposure Bias |0.00 EV
Maximum Aperture Val|2.28 EV (f/2.2)
Metering Mode |Centre-weighted average
Light Source |Unknown
Flash |Flash did not fire
Focal Length |4.2 mm
Maker Note |98 bytes undefined data
User Comment |METADATA-START
FlashPixVersion |FlashPix Version 1.0
Colour Space |sRGB
Pixel X Dimension |4128
Pixel Y Dimension |2322
Sensing Method |One-chip colour area sensor
As you can see, the Orientation tag says top left. This means the EXIF data won't make a difference to the rotation, i.e. the image will appear the same on your computer and on Github.
I then ran
git clone https://github.com/steenhulthin/githubreadmeimagerotation2
cd githubreadmeimagerotation2/
exif HelloButtonModule.jpg
And I got:
EXIF tags in 'HelloButtonModule.jpg' ('Intel' byte order):
--------------------+----------------------------------------------------------
Tag |Value
--------------------+----------------------------------------------------------
Image Width |4128
Image Length |2322
Manufacturer |SAMSUNG
Model |GT-I9505
Orientation |Right-top
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Software |I9505XXUDMH8
Date and Time |2013:10:16 23:22:57
YCbCr Positioning |Centred
Image Width |512
Image Length |288
Compression |JPEG compression
Orientation |Right-top
X-Resolution |72
Y-Resolution |72
Resolution Unit |Inch
Exposure Time |1/33 sec.
F-Number |f/2.2
Exposure Program |Normal programme
ISO Speed Ratings |100
Exif Version |Exif Version 2.2
Date and Time (Origi|2013:10:16 23:22:57
Date and Time (Digit|2013:10:16 23:22:57
Components Configura|Y Cb Cr -
Shutter Speed |5.06 EV (1/33 sec.)
Aperture |2.28 EV (f/2.2)
Brightness |2.44 EV (18.56 cd/m^2)
Exposure Bias |0.00 EV
Maximum Aperture Val|2.28 EV (f/2.2)
Metering Mode |Centre-weighted average
Light Source |Unknown
Flash |Flash did not fire
Focal Length |4.2 mm
Maker Note |98 bytes undefined data
User Comment |METADATA-START
FlashPixVersion |FlashPix Version 1.0
Colour Space |sRGB
Pixel X Dimension |4128
Pixel Y Dimension |2322
Sensing Method |One-chip colour area sensor
Here the orientation says Right-top which means the right top corner of the image is currently in the top left corner. Github does not honor this information, so your image is displayed incorrectly.
I then ran exiftran -ai HelloButtonModule.jpg and this fixed the problem. There is a fork here https://github.com/texasflood/githubreadmeimagerotation2 which shows the correct rotation for the image.
If you are on Windows, IrfanView might work, courtesy of this question: https://superuser.com/questions/36645/how-to-rotate-images-automatically-based-on-exif-data
I think this is caused by github's missing support for the EXIF "Orientation" tag.
Github shows the image data as they are contained in the JPEG file, which is the orientation in which they have been captured by the camera photo sensor. Additionally, the JPEG file includes an EXIF tag "Orientation" containing the value "right, top", which indicates that the image data are not to be interpreted as they are, but that the right side should actually be up. Apparently, github does not honor this tag.
The image in your second repository is not identical to the first one, but seems to have been edited to add the red arrow and text. My guess is that the editor interpreted the "Orientation" tag during loading, and then saved the image data in rotated form and with an "Orientation" tag value of "top, left".
For more information, see e.g. JPEG Rotation and EXIF Orientation.
I still don't understand why this happens (#A.Donda's explanation sound plausible), but I found a solution.
I resized the picture to 50% of the original and picture is no longer rotated.
I would still be happy to know if there are alternatives to resizing though.

Extracting data from grib file based on latitude and longitude

If i have a grib2 file that contains information for whole world (for some parameters) and I want to extract data from it using wgrib2 based on latitude and longitude given by user (client software to server). I tried following command but I am getting complete grib2 file only:
wgrib2.exe input.grb -undefine out-box 10:90 -10:10 -grib output.grb
Please tell me where am I going wrong? Thanks.
This is still the top hit on Google, so even though it is a bit old, here is a more detailed explanation.
First, you need wgrib2 from the National Weather Service Climate Prediction Centre. (The installation of that is straightforward, but not too well explained. See this page, or this gist for help.)
Next, you need to use the lola function (for LOngitude-LAtitude grid).
You need to give wgrib2 several arguments:
the grib file that has the data
the longitude information:
the longitude of the southwest corner of your bounding box
the length of the bounding box in degrees
the spacing of the points in this direction
the latitude information, the same as above
the latitude of the southwest corner of your bounding box
the length of the bounding box in degrees
the spacing of the points in this direction
the file name to write to
the format of the file to write (either bin for binary, text for simple text, spread for spreadsheet format, or grib for grib2).
For example:
wgrib2 input.grb 220:100:1 20:50:1 output.grb2 grib
will create an output file that covers north america (220 E - 320 E; 20 N - 70 N) at 1 degree intervals in both directions.
Rob
I used the following command to extract information from grib2 file.
wgrib2.exe input_file.grib2 -lola LonSW:#lon:dlon LatSW:#lat:dlat file format
assuming that we are having following co-ordinates for selection:
Top: (x0,y0) (x1,y0)
Bottom: (x0,y1) (x1,y1)
"LongSW"=x0, #lon = (x0~x1), "LatSW"=y0, #lat = (y0~y1).
and dlon and dlan can be kept as 1. 'file' is the output file name and format can be grib, csv, text etc.
Substitute above values in the command shown above and you should get the answer.
If your chosen longitude was 360 and latitude was 90:
wgrib2.exe input_file.grb2 -lon 360 90 > output_file.txt
I think you can also use cdo directly on grib for this
cdo sellonlatbox,lon1,lon2,lat1,lat2 in.grb out.grb
If the grib file is on a reduced gaussian grid you may need to specify that you want a regular lat-lon output. I usually convert the output format to netcdf myself using "-f nc" as I find it easier to process in other software.