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. 
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.
Related
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.
Using ImageMagick's convert to barrel-distort a photo to correct a strongly visible pincushion distortion, I provide positive a, b or c values (from a database for my lens + focal length). This results in an image that is corrected, has the original width and height, but includes a non-rectangular, bent/distorted border, as the image is corrected towards its center. Simplified example:
convert rose: -virtual-pixel black -distort Barrel '+0.0 +0.1 +0.0' out.png
How can I automatically crop the black, bent border to the largest possible rectangle in the original aspect ratio within the rose?
The ImageMagick website says, that a parameter "d" is automatically calculated, that could do this (resulting in linear distortion effectively zooming into the image and pushing the bent border right outside the image bounds), but the imagemagick-calculated value seems to aim for something different (v6.6.9 on ubuntu 12.04). If I guess and manually specify a "d", I can get the intended result:
convert rose: -virtual-pixel black -distort Barrel '+0.0 +0.1 +0.0 +0.6' out.png
The given formular a+b+c+d=1 does not seem to be a proper d for my cropping case. Also, d seems to depend on the aspect ratio of the image and not only on a/b/c. How do I make ImageMagick crop the image, or, how to I calculate a proper d?
Update
I found Fred's ImageMagick script innercrop (http://www.fmwconcepts.com/imagemagick/innercrop/index.php) that does a bit what I need, but has drawbacks and is no solution for me. It asumes arbitrary outer areas, so it takes long to find the cropping rectangle. It does not work within Unix pipes, and it does not keep the original aspect ratio.
Update 2
Contemplating on the problem makes me think that calculating a "d" is not the solution, as changing d introduces more or less bending and seems to do more than just zoom. The d=1-(a+b+c) that is calculated by imagemagick results in the bent image touching the upper/lower bounds (for landscape images) or the left/right bounds (for portrait images). So I think the proper solution would be to calculate where one of the new 4 corners will be given a/b/c/d, and then crop to those new corners.
The way I understand the docs, you do not use commas to separate the parameters for the barrel-distort operator.
Here is an example image, alongside the output of the two commands you gave:
convert o.png -virtual-pixel black -distort Barrel '+0.0 +0.1 +0.0' out0.png
convert o.png -virtual-pixel black -distort Barrel '+0.0 +0.1 +0.0 +0.6' out1.png
I created the example image in order to better visualize what you possibly want to achieve.
However, I do not see the point you stated about the automatically calculated parameter 'd', and I do not see the effect you stated about using 'd=+0.6'...
I'm not sure I understand your wanted result correctly, so I'm assuming you want the area marked by the yellow rectangle cropped.
The image on the left is out0.png as created by the first command above.
In order to guess the required coordinates, we have to determine the image dimensions first:
identify out0.png
out0.png PNG 700x700 700x700+0+0 8-bit sRGB 36KB 0.000u 0:00.000
The image in the center is marked up with the white rectangle. The rectangle is there so you can look at it and tell me if that is the region you want cropped. The image on the right is the cropped image (without scaling it back to the original size).
Is this what you want? If yes, I can possibly update the answer in order to automatically determine the required coordinates of the cropping. (For now I've done it based on guessing.)
Update
I think you may have mis-understood the purpose of the barrel-distortion operation. It is meant for correcting a barrel (slight) distortion, as is produced by camera lenses. The 3 parameters a, b and c to be used for any specific combination of camera, lens and current zoom could possibly be stated in your photo's EXIF data. The formula were a+b+c+d = 1 is meant to be used when the new, distortion-corrected image should have the same dimensions as the original (distorted) image.
So to imitate the barrel-correction, we should probably use the second image from the last row above as our input:
convert out3.png -virtual-pixel gray -distort barrel '0 -0.2 0' corrected.png
Result:
Here is the problem to change an image resolution from 300 dpi to 200 dpi or 600 dpi.
i am using matlab but how can i be. so for i have use the imresize function which down sample the image and up sample it.
imresize(image, scale ,interpolation).
how can down sample the image to reduce its quality too. so that i may check the difference between the original image and the down sampled image.
j= imresize(I,0.2,'nearest');
where I is the original image and j is the down sampled image. is this changing the dpi of an image.
Dots per inch (DPI) has nothing to do with the type of resizing done by imresize. In fact, changing the DPI does not even require changing the actual image data, just the metadata -- a property or label. DPI gives you the information needed to go from pixels -> inches (print size).
I have read a lot about BMP file format structure but I still cannot get what is the real meaning of the fields "biXPelsPermeter" and "biYPelsPermeter". I mean in practical way, how is it used or how it can be utilized. Any example or experience? Thanks a lot
biXPelsPermeter
Specifies the horizontal print resolution, in pixels per meter, of the target device for the bitmap.
biYPelsPermeter
Specifies the vertical print resolution.
Its not very important. You can leave them on 2835 its not going to ruin the image.
(72 DPI × 39.3701 inches per meter yields 2834.6472)
Think of it this way: The image bits within the BMP structure define the shape of the image using that much data (that much information describes the image), but that information must then be translated to a target device using a measuring system to indicate its applied resolution in practical use.
For example, if the BMP is 10,000 pixels wide, and 4,000 pixels high, that explains how much raw detail exists within the image bits. However, that image information must then be applied to some target. It uses the relationship to the dpi and its target to derive the applied resolution.
If it were printed at 1000 dpi then it's only going to give you an image with 10" x 4" but one with extremely high detail to the naked eye (more pixels per square inch). By contrast, if it's printed at only 100 dpi, then you'll get an image that's 100" x 40" with low detail (fewer pixels per square inch), but both of them have the same overall number of bits within. You can actually scale an image without scaling any of its internal image data by merely changing the dpi to non-standard values.
Also, using 72 dpi is a throwback to ancient printing techniques (https://en.wikipedia.org/wiki/Twip) which are not really relevant in moving forward (except to maintain compatibility with standards) as modern hardware devices often use other values for their fundamental relationships to image data. For video screens, for example, Macs use 72 dpi as the default. Windows uses 96 dpi. Others are similar. In theory you can set it to whatever you want, but be warned that not all software honors the internal settings and will instead assume a particular size. This can affect the way images are scaled within the app, even though the actual image data within hasn't changed.
I've gotten some graphics files for buttons etc. from the designer. Most of the retina files have one or both dimensions odd, like 29 x 30 or 79 x 61, and then the dimensions of the corresponding non-retina files will be 15 x 15 or 39 x 31, for example. The dimensions of the UIImageView s that hold each image exactly match the size of the non-retina files they hold, so on a non-retina phone there is no distortion and everything looks fine.
On a retina phone, these images (icons and such) only look fine when the images happen to be even dimensions (like 30 x 30 or 46 x 80); when there's an odd dimension to the image, it gets distorted slightly.
Should the pixel dimensions of a retina image always be twice the size of the non-retina dimensions, and of the dimensions of the frame that displays it?
As the name (#2X) implies, it is indeed assumed that the retina-version is exactly twice the size of the non-retina version. Otherwise, as you have seen, there might be distortions.
On a side note, this has only indirectly to do with the displaying frame, e.g. think of scrollviews.
Ask your designer to always design the UI (not necessarily the components themselves) for the non-retina version first, and then just double up the sizes for the retina version. This way, you won't run into distortion-problems. If he designs for retina-first and then scales all components back to half their sizes, he will likely end up with odd dimensions.
Oh, and give your designer this link:
http://www.smashingmagazine.com/2010/11/17/designing-for-iphone-4-retina-display-techniques-and-workflow/
Yes, image files that have #2x appended should be exactly double the size of the 'non'-retina image. Thus should only have even dimensions.
It would appear so.
When you create a view which is 30 points by 30 points on a regular display the backing store (the data that gets drawn on the screen) will be created 30 pixels by 30 pixels.
On a retina display that backing store is simply multiplied by a scale factor. Currently that scale factor is 2 for iPhone 4 and iPhone 4s. This means that the backing stores on retina displays will always be a multiple of 2.
Your 30 point by 30 point view would have a 60 pixel by 60 pixel backing store. If your images aren't drawn properly for retina displays it would seem that the #2x image needs to be the full size of the backing store, and hence exactly double the size of the view in points.