crop coordinates must be divided by 2
Posted: Wed Apr 11, 2007 9:38 pm
trying to convert a series of canon raw .cr2 images with nconvert
i'm finding that i have this problem:
if my image (camera is a 5d, btw) is x x x i would normally
issue a command something like nconvert -crop 286 374 3856 2169
to get an image of a 16x9 ratio.
the image produced by the above is not correct, however. in order to get
my image to crop to the right size i have to divide all of the numbers
by 2. that produces a command:
nconvert -crop 143 187 1928 2169
this produces an image that is properly cropped.
i noticed similar behaviour with irfanview a while back and, among
other reasons, switches to xnview to solve the problem. i found
that irfanview misreported the image size in addition to being unable
to crop properly. i found that xnview did report the proper image size.
now that i'm getting in a little deeper, however, i'm finding this
similar problem with the cr2 files.
what's happening here? is xnview actually reading the file at half
it's dimensions? or is it just a bug wherein the numbers need to be
halved but the data is actually correct?
thanks and will continue testing,
BabaG
i'm finding that i have this problem:
if my image (camera is a 5d, btw) is x x x i would normally
issue a command something like nconvert -crop 286 374 3856 2169
to get an image of a 16x9 ratio.
the image produced by the above is not correct, however. in order to get
my image to crop to the right size i have to divide all of the numbers
by 2. that produces a command:
nconvert -crop 143 187 1928 2169
this produces an image that is properly cropped.
i noticed similar behaviour with irfanview a while back and, among
other reasons, switches to xnview to solve the problem. i found
that irfanview misreported the image size in addition to being unable
to crop properly. i found that xnview did report the proper image size.
now that i'm getting in a little deeper, however, i'm finding this
similar problem with the cr2 files.
what's happening here? is xnview actually reading the file at half
it's dimensions? or is it just a bug wherein the numbers need to be
halved but the data is actually correct?
thanks and will continue testing,
BabaG