I wanted to build an awesome place for people to discuss module specific issues, but I don't have any more time for this, and there are much better places to discuss Perl-related issues. I'd recommend asking your question on Stack Overflow or on Perl Monks.
If you are looking for a Perl tutorial or Perl-related news, I hope these links will serve you well.
Posted on 2008-11-11 09:47:32-08 by igor77 in response to 9275
Re: batch change previews in RAW-files
Hi, Bogdan!
Thanks for explanation. I've already understood it when I wrote my previous post. To change orientation tag in RAW is wrong way. May be more productive idea was the second one.
First of all I suppose, there can be cases when there is no information about orientation in RAW tags. May be it is incorrect opinion, but still. In this case if JPEG is already horizontal, we can embed it 'as is'. If JPEG is not horizontal - it's like a lottery. We can rotate it to make horizontal, but can't be sure, if it is correct. Result can be rotated to 180 degree relatively to RAW position.
Next, DPP as you say, always make properly orientated image with 'horizontal' tag. But JPEG can be made by another program and this tag can be important. In theory it can be big mess in tags, width/height and the real orientation. We need to find the real orientation of JPEG and do reverse rotation according to CR2 tag.
We have to make the assumption that (1) JPEG which we want to embed is properly oriented (when we look on it in a viewer) OR (2) it has the orientation like RAW has (we can convert RAW without implementation of rotation) - it looks like vertical image lies sideways.
In the second case (if JPEG have to be seen vertical - height more than width - but it is horizontal in fact) we embed it 'as is'.

Well. I try to prepare algorithm.
1. Compare width/height of JPEG. If width>height than we have value '2' (horizontal). If width<height than we have value '1' (vertical). It may be other values - it is important only for calculation, see step #2.
2. Next look at the orientation tag of JPEG. When we see the image in the viewer, we see it with applied tag.
We have value '3' if image rotates 180 degree CW, '1' for 0 degree, '6' for 90 degree and '8' for 270 degree. May be it can be another functional dependence, but we can see that for even number we change orientation, and for odd value we have the same orientation, but may be rotate it upside down.
3. Then we sum up value from step 1 and step 2.
If result is even number (1+1 or 1+3 or 2+6 or 2+8) - we will see in viewer vertical image.
If result is odd (2+1 or 2+3 or 1+6 or 1+8) - it is horizontal image.
We have to remember about mentioned assumptions.
We need only information 'vertical' or 'horizontal' and we have it.
Now we have the position of JPEG, which we can see in a viewer.
4. Look at the orientation tag in RAW.
4.1. If it is '1' (90 degree) or '3' (270 degree) - image is vertical.
4.1.1. But if in the step #3 we have 'horizontal' - we embed JPEG 'as is' (look assumption #2). To be honest, we have to apply JPEG rotation (tag in step #2), because we work with final view of the image in a viewer.
4.1.2. If in step #3 we have 'vertical' - all is Ok - we make reverse rotation and embed received JPEG. It is important that we must have in view JPEG rotation (tag in step #2).
4.2. If it is '0' and in the step #3 we have 'horizontal' - we embed JPEG 'as is'. If in this case JPEG is vertical - it is incorrect. May be it is situation "no information about orientation in RAW tags" mentioned above.

May be it is not complete logic, but may be it can help. Two heads are better than one :-)

But... there is a little problem if JPEG is croped image with changed orientation. For instance, vertical portrait croped from horizontal image. Well, it is impossible to predict all situations :-)
Best Regards,
Igor
P.S. About language. Bogdan, I understand you very well. I guess, you are Russian-speaking :-) We have the same way of thinking.
Direct Responses: 9279 | Write a response