5

What I want to do :

Suppose I have an image I that I rotate -45° using imrotate (I get I_R). Then I draw two lines AB and CD (parallels). Finally, I rotate the two lines back (45°) and draw them in the original image I.

How I do that ##

I rotate I using the MATLAB function imrotate():

I_R = imrotate(I,-45);

From Matlab help, I get : B = imrotate(A,angle) rotates image A by angle degrees in a counterclockwise direction around its center point.

But it seems that imrotate add a translation to the image ! I have read the code of built-in matlab function, it seems that it uses a function called getOutputBound to check if the rotated image will fit in the figure. This translation is what I am looking for !!

The four points A,B,C,D form a two parallels lines AB & CD.

A = [x_A; u];
B = [x_B; u];

C = [x_A; d];
D = [x_B; d];

So now , I rotate the two lines, I use my function rotateTwoPoints(), by simply calling the following two lines :

[Af,Bf] = rotateTwoPoints(A,B,-45,O,true);
[Cf,Df] = rotateTwoPoints(C,D,-45,O,true);

Where O is the origin around which the rotation will be.

  • I have tried O = [0;0] I mean it is the origin of the plot. No success !
  • So I choose O the centroid of the image I using regionprops(I,"Centroid"). It was wrong because the centroid is not a center.
  • Now, I use the center of the image O = floor(size(I)/2+0.5)' or using ceil !

But when I draw the resulting lines AfBf & CfDf in image I like this :

plot([Af(1) Bf(1)],[Af(2) Bf(2)],'k');
plot([Cf(1) Df(1)],[Cf(2) Df(2)],'k'); 

I get a result that is not correct !

Problem : In I_R, the AB & CD contain what I call the BlueZone (see image 3). But the rotated back lines AfBf & CfDf do not cover it !

The results in Images

Here is the rotated image I_R and the two lines drawn (The two middle red lines correspond to AB and CD) :

The two middle lines correspond to AB and CD

I then draw the rotated lines AfBf & CfDf in original image I (the black bold point correspond to the center on which I have done the rotation) :

IMAGE UPDATED enter image description here

Problem : As you can see the BlueZone was inside the two lines AB and CD. But when rotated back it become outside, as shown in the following image (red arrows point to BlueZone) :

enter image description here


UPDATE ADDED a SNIPPET

Since my problem is not yet resolved , I selected the code that causes the problem and I add it as the following snippet (there is a variable stored in a file that you can download here) :

function Question()

% load image in I, the image is available online in the below link  
load I ;

% rotate I with -45° using imrotate
I_R = imrotate(I,-45);

% some data
x_A = 3 ;
x_B = 79;

u = 24;
d = 44;

% some meaningful Points : A,B,C and D that form two lines AB and CD
% parallels
A = [x_A; u];
B = [x_B; u];

C = [x_A; d];
D = [x_B; d];

% figure 1 contain two subplots 
figure(1);
% draw rotated image I_R
subplot(1,2,1), axis image, imagesc(I_R), hold on;
% draw two lines AB and CD in red in rotated image 
plot([A(1) B(1)],[A(2) B(2)],'r');
plot([C(1) D(1)],[C(2) D(2)],'r');
title('I_R the rotated image with the two lines AB and CD');

% draw original image I
subplot(1,2,2), axis image, imagesc(I)  , hold on;

% compute the middle of image I
axises=axis;
center = [mean(axises(1:2)),mean(axises(3:4))]';
% draw the center in red and as a point
plot(center(1),center(2),'ro');

% rotate the two lines, the result is the two lines AfBf and CfDf
[Af,Bf] = rotateTwoPoints(A,B,-45,center,true);
[Cf,Df] = rotateTwoPoints(C,D,-45,center,true);

% draw the rotated back lines in original image I
figure(1);
subplot(1,2,2);
plot([Af(1) Bf(1)],[Af(2) Bf(2)],'k');
plot([Cf(1) Df(1)],[Cf(2) Df(2)],'k');
title('the original image I with the two lines AfBf and CfDf');

function [Af,Bf] = rotateTwoPoints (A,B,t,Origin,isPlot)

% Definition of the rotation matrix (rotation around origin)
R=[ ...
    cosd(t) -sind(t)
    sind(t) cosd(t)
    ];

% translation 
At = A - Origin;
Bt = B - Origin;

% rotation of the points A and B
Ar = R*At;
Br = R*Bt;

% translation 
Af = Ar + Origin;
Bf = Br + Origin;

if isPlot == true

    figure(100)

    % Plot of the original line
    plot(A(1),A(2),'k*', B(1),B(2),'b*');
    line([A(1) B(1)],[A(2) B(2)], 'Color','r');

    grid on
    hold on

    % Plot the Origin around which the rotation will be
    plot(Origin(1),Origin(2),'k*','LineWidth',3);

    % Plot of the rotated line
    plot(Af(1),Af(2),'g*', Bf(1),Bf(2),'r*');
    line([Af(1) Bf(1)],[Af(2) Bf(2)], 'Color','b');
    legend('A','B','line AB','Origin','Af','Bf','line AfBf',['angle: ',num2str(t)],'Location','northeastoutside');
    daspect([1 1 1])

end

PS: I am using MATLAB R2012b

  • please, if you need any detail just comment ... –  May 24 '15 at 09:10
  • 1
    Have you tried `O = floor(size(I)/2)` when rotating the lines or else `O = floor(size(I_R)/2)` when rotating the lines back? – Dan May 27 '15 at 09:23
  • No I haven't done this ... but I use `regiopros` and `Centroid` to get the center of **I**. In which way this will differ ?? –  May 27 '15 at 09:33
  • 2
    The center may well not be the centroid. Give it a try – Dan May 27 '15 at 09:48
  • @Dan is correct, the centroid is something else. The centre is much easier to find: (width/2, height/2) : ) give or take a bit for odd numbers and rounding policies... – xenoclast May 27 '15 at 10:05
  • 1
    @OSryx As I understand it, the *centroid* is similar to a center of mass and so is a weighted average based on your pixel intensities. The *center* of the image is just half way down the number of pixels and half way across, i.e. it ignores the pixel intensities. If you image was completely uniform, then the two would be equal. According to the [docs](http://www.mathworks.com/help/images/ref/imrotate.html), `imrotate` rotates around the center point (not the origin, not the centroid). – Dan May 27 '15 at 10:15
  • @xenoclast I see what you mean, I will try `O = floor(size(I)/2)` tonight. –  May 27 '15 at 10:33
  • You are right, _**Centroid** is 1-by-Q vector that specifies the center of mass of the region._ as it is mentionned here : http://www.mathworks.com/help/images/ref/regionprops.html#inputarg_properties –  May 27 '15 at 10:35
  • @OSryx I think it's actually `floor((size(I)/2)+0.5)` but I can't find the reference for that. – xenoclast May 27 '15 at 13:46
  • Okey, I tried the use of **Center of Image**, I have got better result, see : http://imgur.com/8FxMJ4r But the **BlueZone** is still outside the two black lines `AfBf` & `CfDf` ! What is strange is the center (black point) is not on the middle of the image ... why please ? –  May 27 '15 at 14:16
  • I think I have to reverse it to get the right result. So `temp = floor(size(I)/2+0.5)' ` and `O = [temp(2);temp(1)]` now it is on the middle ... Matlab coordinate is just strange ! I **update** my question right now . –  May 27 '15 at 14:31
  • Hi @Dan you are right about the center of the image ... but I think I still have to do a translation ? –  May 27 '15 at 14:46
  • I **updated** the whole question. –  May 30 '15 at 10:07

5 Answers5

5

As you say the rotation is being computed correctly, as shown by the first plot. The problem then is just with the final display of the results. When you do this

plot([Af(1) Bf(1)],[Af(2) Bf(2)],'k');
plot([Cf(1) Df(1)],[Cf(2) Bf(2)],'k'); 

you have a typo in the second line (second element of second argument) - you're plotting Bf(2) as the end of the second line instead of Df(2). When I replaced this with Df(2) it plotted parallel lines as expected.

UPDATE:

In the comments I suggested refactoring this code to use transform matrices for everything, such that the same set of transforms can be applied to both the image and the overlays. Here is a generic outline of how you might set that up.

There are two main points to be aware of.

  1. Matlab's convention with images is that y=0 is the top. imshow and related then put y=0 at the top and y increasing down the plot. This is the opposite convention from plot, and so when you overlay plots and images one of them has to be inverted. This has consequences for the use of transform matrices, the main one being that the rotation angle has to be inverted.

  2. Images in matlab can be thought of as the z-data for a regular grid of pixels. However those pixel coordinates aren't stored, they're just inferred when you display the image. Consequently, when you translate an image and then imshow it again the translation is not evident, because it re-infers a new set of pixel coordinates which happen to be the same as the ones for the untransformed image. To get round this we must fix spatial referencing to an image.

In addition to this the 2d transforms are carried out using 3space matrices so we need to define out points in 3space (but then truncate them for display in 2d plots).

So let's put it all together.

% get an image
I = imread('cameraman.tif');
% get spatial referencing information
Rcb = imref2d(size(I));

% define some test points in 3space
pta = [10; 10; 0];
ptb = [ 50;  10; 0];
% construct a test line in 2space from our test points
testline = [pta(1:2) ptb(1:2)];

% overlay line on plot
figure(90); clf
imshow(I,Rcb); truesize; hold on;
plot(testline(1, :), testline(2, :), 'y', 'linewidth', 4)

% define our transforms
% rotation angle (deg)
t = 45;

% a transform suitable for images
Rimage=[ ...
    cosd(t) -sind(t) 0
    sind(t) cosd(t) 0
    0 0 1
    ];
% the same transform suitable for points
Rpoints=[ ...
    cosd(-t) -sind(-t) 0
    sind(-t) cosd(-t) 0
    0 0 1
    ];

% make tform object suitable for imwarp
tform = affine2d(Rimage);

% transform image and spatial referencing with tform
[Ir, Rr] = imwarp(I, tform);

% transform points directly using matrix multplication
ptar = Rpoints*pta;
ptbr = Rpoints*ptb;

% construct the rotated line for plotting
newline = [ptar(1:2) ptbr(1:2)];

% the results
figure(91); clf
imshow(Ir, Rr); truesize; 
hold on;
plot(testline(1, :), testline(2, :), 'y', 'linewidth', 4)
plot(newline(1, :), newline(2, :), 'g', 'linewidth', 4)

In the second plot I've plotted the transormed line in green and the original line in yellow, for comparison.

Points to note:

  1. The imwarp function doesn't use the rotation matrix directly, you have to construct a tform object from it first and then supply that. You can of course do all this in one line.

  2. Having two matrices is a bit inelegant. It's okay here where we only have a single rotation to worry about, but the whole point of using transform matrices is that you can chain a sequence of transforms together just by multiplying the matrices. If you have to do this twice it would spoil an otherwise elegant piece of code and that would never do, so probably the cleanest way of doing it would be to flip your images right at the start of the whole process, then flip them back at the very end if necessary (for exporting, say).

  3. The bookkeeping for the point data is somewhat tedious. There are lots of ways to do this, depending on the conventions you choose to adopt with respect to which coordinate is being held in which position in the column vectors. I've never found a set that plays nicely with both 3space transforms and plot, and what works best changes depending on the application. Helper functions can save some headaches for you, if not the next maintainer, and wrapping it all up in a class is the neatest, if you can justify the time.

UPDATE2:

To minimise the use of 3space coordinates I would simply use 2space vectors to describe all your points, as normal, and then add the dummy z-coordinate only when you need to perform the transform.

So you might have

testpoint = [1; 5]; % x and y xoordinates only
trpoint = Rpoints*[testpoint; 1];
trpoint = trpoint(1:2);

You could put this in a wrapper but there's no getting round the fact that you need to use a 3x3 matrix for the imwarp section, which means you need to specify your coordinates in 3space too.

Alternatively you could truncate the rotation matrix for the coordinate transform:

trpoint = Rpoints(1:2, 1:2)*testpoint;

but one way or another you'll have to do some index bookkeeping.

UPDATE3:

The OP doesn't have access to imref2d, so here's a hacky way to achieve the same result. The important line is this one

imshow(Ir, Rr);

where Rr is the spstial referencing object output by the imwarp function. If you don't have this you can supply spatial referencing to imshow manually with the 'XData' and 'YData' arguments. You need to work out the extents first, and decide on a convention. imref2d uses the convention of (0,0) as top left and when the image is rotated this corner of the original image remains as coordinate (0,0), such that the rotated image now extends from y=[-181:181] and x=[0:363]. To get these values you need to transform all four corners of the image and then work out the maxima and minima.

xmax = size(I,2);
ymax = size(I,2);
corner1 = [xmax; 0; 0]+0.5;
corner2 = [xmax; ymax; 0]+0.5;
corner3 = [0; ymax; 0]+0.5;
corner4 = [0; 0; 0]+0.5;
tc1 = Rpoints*corner1;
tc2 = Rpoints*corner2;
tc3 = Rpoints*corner3;
tc4 = Rpoints*corner4;
corners = [tc1 tc2 tc3 tc4];
xlims = minmax(corners(1,:));
ylims = minmax(corners(2,:));

you can then replace the imshow line with this one

imshow(Ir, 'xdata', xlims, 'ydata', ylims);

everything else should be the same.

Note that, when I did all this, there was a slight difference between the values I got above and the ones produced by imwarp in the imref2d object. That function returned

XWorldLimits: [0.2264 363.2264]
YWorldLimits: [-181.5000 181.5000]

Whereas mine gives

xlims: [0.7071  362.7458];
ylims: [-181.0193  181.0193];

I can't account for this without looking in the source of imwarp and, even if it isn't MEX at that level, I'm not sure how far you could go before you could be accused of IP infringement.

These numbers account for the placement of the image on the axes, so if you're using the image to choose points they may be off by a few tenths of a pixel. If you're just using the image for reference then it should be close enough.

xenoclast
  • 1,635
  • 15
  • 26
  • Well observed, I did not pay attention to that. Now they are parallels, but that answers the HALF of the question. The second part, is how to get a correct parallels line when the rotation is back. As you can see here http://imgur.com/Elr2isa in rotated I we got the BlueZone inside the two lines, when I rotated back it was outside !!! I will UPDATE right now my question. –  May 26 '15 at 17:22
  • 2
    I will wait to see your updated question but from what I can already see I expect it will be because of the rotation origin. `imrotate` rotates the image about the image centre but it seems your transform is computed with a different origin. You may need to translate the imrotated image. Personally I would use an affine transform for this incorporating both a translation and a rotation, then you could apply the combined matrix transform to both the plots, as you are currently, and the image using `imwarp`. http://uk.mathworks.com/help/images/performing-general-2-d-spatial-transformations.html – xenoclast May 27 '15 at 07:26
  • I **updated** my question. It is possible that the problem come from the **Origin of the rotation** or maybe I need to do an additional **translation**. Can you provide in your answer the code using translation & rotation ? –  May 27 '15 at 09:31
  • @Osryx I've updated my answer with an example of how you could use rotation matrices for both the image and the points. You don't need the transform for this example but if you need to add it you can do so by multiplying the transform matrix by the rotation matrix. – xenoclast May 27 '15 at 11:25
  • @OSryx Actually having researched it I don't think you can do the spatial referencing trick with `imrotate`, and `imtranslate` doesn't even exist! I removed my comment above... – xenoclast May 27 '15 at 13:47
  • @OSryx I've updated the answer with a few ideas about the use of 3space or 2space vectors. – xenoclast May 27 '15 at 13:58
  • Sorry @xenoclast I can not use your code (at some point) because `imref2d` function was introduced in Matlab **2013a**, I am using Matlab **2012b** :( as I mentionned in the bottom of my question ... –  May 27 '15 at 14:21
  • by the way, I am not using imshow I rather use imagesc but I have Y-axis problem 0 is up and it is increasing down ... I don't think it is good to not use imrotate. Refactoring my code to use only transformations is not a so good idea but it will be my last option ... –  May 27 '15 at 15:06
  • @OSryx it turns out it's possible to manually specify the spatial references for `imshow`. I've updated with a workaround. I understand your reticence - the image stuff seems like it's been shoehorned into matlab (which it has...) but this kind of problem has been thought through a lot and the set of tools they've developed is consistent. It makes more sense when you've got used to the conventions - like the (0,0) top left and the columnwise indexing. Ultimately only you know what's best for your application : ) I hope it helps anyway, good luck! – xenoclast May 27 '15 at 15:18
  • I **UPDATED** the whole question, but I think I know from where comes the problem : the `imrotate` rotate the image but in order to let the new rotated image fit in the figure, it translates it ! that's what I am looking for, if only I can get this translation. –  May 30 '15 at 10:06
  • @OSryx Try just using the `'xdata'`and `'ydata'` arguments to `imshow`: your axes, points and lines are all in a consistent coordinate frame, it's just the image that's not so if you move the image about until it aligns that might be enough. You can use the code in UPDATE3 for that and of course because you won't be using the `imwarp` you can do it all in 2space instead, which gets rid of the unwanted z-coordinates too : ) sounds like a good solution. – xenoclast May 30 '15 at 11:10
  • @OSryx I just saw you've found a solution! That's certainly shorter... : ) – xenoclast May 30 '15 at 11:11
  • Well, it is said that i should not say "thank you" in comments ... but any way thank you @xenoclast for your precious help, I learned a lot from you. –  May 30 '15 at 14:33
  • Great! I'm glad, and it's my pleasure : ) – xenoclast May 30 '15 at 19:08
1

1) you have image I

2)you rotated image I about its center (-45 Degree)=> I_R is rotated image

3)you draw two parallel lines in I_R (line1 & line2)

4)you rotate lines in respect to center of imge I

step number 4 is wrong you must choose center of image I_R for rotation center.

From Matlab Docs: By defaul imrotate creates an output image large enough to include the entire original image. pixels that fall outside the boundary of original image are set to 0 and apear as black background in the output image.

>

from comments: 1) you rotated the image about center point of "I" (-45degree)

2) when you do this using imrotate , the function rotate and translate the main picture and generates "I_R" ,

3) so the center point of I_R is the center point of "I" + some translation!.

4) so the main problem is calculating amount of translation,

5) to do this you can use this: Calculating translation value and rotation angle of a rotated 2D image or this: http://angeljohnsy.blogspot.com/2011/06/image-rotation.html or

6) simply you can use some markings on your original image (for example marking on the center of original image ) to see how much it translated ( or to see center of I_R directly) and the use this center for rotation back of lines.

Hope you find some good way to calculate translation , even you can write your own "image_rotation" script it is not so hard .

Community
  • 1
  • 1
Hadi
  • 1,203
  • 1
  • 10
  • 20
  • okey I see your point ... maybe you are right. But how to compute the center of this image : http://i.stack.imgur.com/UTURy.png there is a lot of unused data , i think we call it padding. –  May 29 '15 at 13:15
  • one another way is tor transform back(+45 d rotation) image and lines with respect to any arbitary point in space , but about finding the center of I_R i have no idea yet, and indeed its because of padding that the center of "I" is not equal to center of "I_R". – Hadi May 29 '15 at 13:34
  • well, the problem is more complicated then that. when I will rotate back the two lines, I will have to do some modifications and computation and then translate the two lines and draw them in another image !! so transform back both is not an option. –  May 29 '15 at 13:57
  • 1
    you rotated the image about center point of "I" (-45degree) when you do this using imrotate , the function rotate and translate the main picture and generates "I_R" , so the center point of I_R is the center point of "I" + translation!. so the main problem is calculating amount of translation, to do this you can use this: http://stackoverflow.com/questions/23619269/calculating-translation-value-and-rotation-angle-of-a-rotated-2d-image or this: http://angeljohnsy.blogspot.com/2011/06/image-rotation.html or simply you can use some markings on your original image (for example marking .... – Hadi May 29 '15 at 15:10
  • 1
    ... on the center of original image ) to see how much it translated ( or to see center of I_R directly) and the use this center for rotation back of lines – Hadi May 29 '15 at 15:13
  • This is very interesting ... you mean that `imrotate` not only rotate but it also translate ! if you are right that solves the problem. –  May 30 '15 at 09:55
  • 1
    I **UPDATED** the whole question, but I think I know from where comes the problem : the `imrotate` rotate the image but in order to let the new rotated image fit in the figure, it translates it ! that's what I am looking for, if only I can get this translation. –  May 30 '15 at 10:06
  • Can you rewrite your question to include your *interesting* comment, because it is the one that leads to the solution so that i can award you the 100 bounty ?? –  May 30 '15 at 14:32
  • also 'crop' command tear some portion of original image so you could not see the entire image in the I_R , i commented here because i cannot comment on yours. – Hadi May 30 '15 at 18:06
1

I found the solution !

Well, what happens is that the built-in function imrotate does not only rotate by default the image, but it does also a translation so that the rotated-image fit in the figure.

the solution is to use :

I_R = imrotate(I,-45,'nearest','crop');

the important parameter here is 'crop' (bbox) :

B = imrotate(A,angle,method,bbox) rotates image A, where bbox specifies the size of the returned image. bbox is a text string that can have one of the following values. The default value is enclosed in braces ({}).

'crop' Make output image B the same size as the input image A, cropping the rotated image to fit

{'loose'} Make output image B large enough to contain the entire rotated image. B is generally larger than A.

from the help of the function imrotate here.

0

Might not fix it, but try defining your matrix as:

R=[ ...
    cosd(t) -sind(t)
    -sind(t) -cosd(t)
    ];

When plotting over an image you need to take care of the y-axis, which automatically goes from top to bottom.

natario
  • 24,954
  • 17
  • 88
  • 158
  • the lines are still not parallels .... simply the rotation went about 90° .... I don't think it is the solution, by the way I already discussed the question of rotation and test it the old-Rotation Matrix is correct. thank you –  May 24 '15 at 09:18
  • Just gave you my first thought, will think about it. – natario May 24 '15 at 09:21
  • thank you it was a good point, I did'nt pay attention to that fact Y-axis is top-bottom on matlab .... t –  May 24 '15 at 09:21
  • It is so only when you are showing an image. You can revert it using `axis xy`. I add that as "origin" you should use the image center, not [0, 0], but maybe it is what you are doing. – natario May 24 '15 at 09:33
  • I don't really get your comment, is there two ideas ?? well the second part : I have tried to rotate back around the **Centroid of I** also –  May 24 '15 at 09:35
  • I have checked my code .... `O = centroid_I` sure of that. the O as [0,0] not working ... –  May 24 '15 at 09:38
  • I am looking on the help of `imrotate(A ...)`. It is said that the rotation is around the center of **A**. –  May 24 '15 at 09:44
  • is it possible that this distorsion happens because of using `imagesc` ??? I have `axis image` just before imagesc ... !! –  May 24 '15 at 09:52
0

I may be misunderstanding something, but what you want to do is to turn a picture, draw two lines and then turn everything including the two lines back again, right?

If so I guess that the easiest way to turn the two lines would be to translate them into polar coordinates using car2pol. http://se.mathworks.com/help/matlab/ref/cart2pol.html

Then it should be easy to turn the lines. Let me know if I misunderstood anything.

edit: I tried to make some example code, apparently I am too tired to think straight and there is some error, but I guess the idea is clear. Also please do not use structures as I did, I just thought it would be the easiest way to name the variables.

%% Load picture
close all
[pic] = dicomread('C0011866_00094.DCM');

%% Get four points
    figure, imshow(pic,[]); 
    title('Select four points'); hold on; 
    [x,y] = ginput;
    
%% Plot the lines on top of the figure
hold on
plot(x(1:2),y(1:2),'b');
hold on
plot(x(3:4),y(3:4),'r');

%% Define the lines
%In cartesian coordinates
line1.start.cart = [x(1),y(1)];
line1.end.cart = [x(2),y(2)];

line2.start.cart = [x(3),y(3)];
line2.end.cart = [x(4),y(4)];

%Middle of picture
axises=axis;
center = [mean(axises(1:2)),mean(axises(3:4))];
plot(center(1),center(2),'ro')

%In polar coordinates from center [angle,radius]
[line1.start.pol(1),line1.start.pol(2)] = cart2pol(line1.start.cart(1)-center(1),line1.start.cart(2)-center(2));
[line1.end.pol(1),line1.end.pol(2)] = cart2pol(line1.end.cart(1)-center(1),line1.end.cart(2)-center(2));

[line2.start.pol(1),line2.start.pol(2)] = cart2pol(line2.start.cart(1)-center(1),line2.start.cart(2)-center(2));
[line2.end.pol(1),line2.end.pol(2)] = cart2pol(line2.end.cart(1)-center(1),line2.end.cart(2)-center(2));

%% Rotate the image a degrees
a = 10;
newpic = imrotate(pic,a);

%% Rotate the lines
line1.start.pol(1) = line1.start.pol(1) + a;
line1.end.pol(1) = line1.end.pol(1) + a;

line2.start.pol(1) = line2.start.pol(1) + a;
line2.end.pol(1) = line2.end.pol(1) + a;

%% Transform the coordinates back to cartesian
[line1.start.cart(1), line1.start.cart(2)] = pol2cart(line1.start.pol(1),line1.start.pol(2));
line1.start.cart = line1.start.cart+center;
line1.end.cart = line1.end.cart+center;
[line1.end.cart(1), line1.end.cart(2)] = pol2cart(line1.end.pol(1),line1.end.pol(2));
line2.start.cart = line2.start.cart+center;
line2.end.cart = line2.end.cart+center;

[line2.start.cart(1), line2.start.cart(2)] = pol2cart(line2.start.pol(1),line2.start.pol(2));
[line2.end.cart(1), line2.end.cart(2)] = pol2cart(line2.end.pol(1),line2.end.pol(2));

%% Plot it again
figure
imshow(newpic,[]);
hold on
plot([line1.start.cart(1),line1.end.cart(1)],[line1.start.cart(2),line1.end.cart(2)])
hold on
plot([line2.start.cart(1),line2.end.cart(1)],[line2.start.cart(2),line2.end.cart(2)])
hold on
plot(center(2),center(1),'ro')
Nicky Mattsson
  • 3,052
  • 12
  • 28
  • You are right. I turn an image. I draw two lines. I rotate back the two lines and draw them in original image (not rotated). –  May 28 '15 at 18:04
  • The problem is that when i draw the **rotated back** the two lines and draw them in original image. I get them in the wrong place. As an example : there is a blueZone which is inside the two lines AB and CD. And NOT in AfBf and CfDf. Please, can you provide an example of code using cart2pol ? –  May 28 '15 at 18:20
  • 1
    I think the problem has to do with adding the center. If you haven't solved it by tomorrow, let me know and ill look at it again. – Nicky Mattsson May 28 '15 at 19:45
  • I am using the center of the image being rotated ! do you propose something else ? –  May 28 '15 at 19:47
  • I am trying to understand your code ... `center [mean(axises(1:2)),mean(axises(3:4))];` is similar `center=floor(size(image)/2]` ? so you keep the center I have used before but you choose to use cart2pol ?? –  May 28 '15 at 19:56
  • 1
    so axis returns [xmin xmax ymin ymax], taking the mean of the two first arguments gives x center and so for y. Yours only work if you start in (0,0). To the second question, yes - we have the same center, but I go via polar coordinates, as changing angles here are easy(ier). – Nicky Mattsson May 28 '15 at 19:58
  • Does it make sense, what I have made? – Nicky Mattsson May 28 '15 at 20:21
  • I can't check that on my computer right now .. sorry @Nicky , I will do that tomorrow –  May 28 '15 at 20:28
  • Your code is running but it has the same problem as mine. The rotated back two lines are not in coherent place. There is a problem in it, please check that ! –  May 30 '15 at 09:24
  • Here is an exemple of using your code on my image I (the one that I included its file in my question in my last update) as you can see ... the resulting lines are even outside the region ... http://imgur.com/Q4pNZLn And by the way, the **four points** are chosen from the rotated image not the original image ! –  May 30 '15 at 09:29
  • I **UPDATED** the whole question, but I think I know from where comes the problem : the `imrotate` rotate the image but in order to let the new rotated image fit in the figure, it translates it ! that's what I am looking for, if only I can get this translation. –  May 30 '15 at 10:06