command line tool to normalize exif orientation flag

Hello,

I have for years problem with the orientation tag in digikam.

I just now try to compile the last digikam, but don't know if I will
succeed (Already failed to do so sometime ago).

I finally could understand the problem. On my 2.2.0 digikam the "set
orientation to normal" do *not* work. Normal photos are top, left (for
example, the true value do not matter). A vertical photo that have to
stay vertical says "right, top". Asking digikam to change thi to
"normal" do not do anything.

for men waiting any new digikam version, it could be as simple as
using exiftools on command line to do the normalisation job. But I
don't know the exiftool systax and before RTFM for some hours, may be
some body here already know this.

I could then rotate the photos at will, then say "all is normal"

thanks
jdd

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

On 5/30/12, jdd <[hidden email]> wrote:

> I have for years problem with the orientation tag in digikam.  But I
> don't know the exiftool systax and before RTFM for some hours, may be
> some body here already know this.

Hi jdd

Try this:
http://ninedegreesbelow.com/photography/exiftool-commands.html#orientation

Test, test, and retest in a test directory on a small sample of images
before using on your main photo directory, to make sure you have all
the syntax correct and it's doing exactly what you want. I've made
syntax errors with exiftool that scattered files all over the place.

To be doubly safe, make a backup of your main image folders before
using exiftool to change the orientation tag.
--
Elle Stone
http://ninedegreesbelow.com


--
Elle Stone
http://ninedegreesbelow.com
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[John Stumbles]

On 31/05/12 16:21, Elle Stone wrote:

> To be doubly safe, make a backup of your main image folders before
> using exiftool to change the orientation tag.

On a unix-ey filesystem with hard links doing
   cp -rl <pictures_filetree> <backup_place>
e.g.
   cp -rl /home/john/pix /home/john/pix.20120531-backup
makes an image of my main image folders in the backup location without
using (much) extra disk space, since only the directory entries of the
files are copied, not the files themselves.

It's not bulletproof: since the files are hard-linked any utility that
changes the contents of the file in one location without breaking the
link will change it in the other location as well.


--
John Stumbles                                    http://stumbles.org.uk
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Thursday 31 May 2012 17:09:25 John Stumbles wrote:

> On 31/05/12 16:21, Elle Stone wrote:
>
> > To be doubly safe, make a backup of your main image folders before
> > using exiftool to change the orientation tag.
>
> On a unix-ey filesystem with hard links doing
>    cp -rl <pictures_filetree> <backup_place>
> e.g.
>    cp -rl /home/john/pix /home/john/pix.20120531-backup
> makes an image of my main image folders in the backup location without
> using (much) extra disk space, since only the directory entries of the
> files are copied, not the files themselves.
>
> It's not bulletproof: since the files are hard-linked any utility that
> changes the contents of the file in one location without breaking the
> link will change it in the other location as well.
>

Also, to make the risks abundantly clear: anything that damages the file, will
damage it for *all* locations, meaning that the original data is /lost/...

So, for me, hard-links *cannot* be considered as backups, you'll have to use a
real copy for that (that actually copies the data to another location).

Hard links are very useful to give another 'view' on a collection of files,
among other things, but please, please, do not even think of them as any form
of 'back-up'... And we've seen in another thread that Digikam doesn't play
nice with hard-linked files, either.

Remco

P.S. @John: this is not to attack you, but hard links are a slightly more
advanced feature, and if someone thinks that they work as a backup, they could
be in for a lot of grief...
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[John Stumbles]

On 31/05/12 17:49, Remco Viëtor wrote:

> Also, to make the risks abundantly clear: anything that damages the file, will
> damage it for *all* locations, meaning that the original data is /lost/...
>
> So, for me, hard-links *cannot* be considered as backups, you'll have to use a
> real copy for that (that actually copies the data to another location).
>
> Hard links are very useful to give another 'view' on a collection of files,
> among other things, but please, please, do not even think of them as any form
> of 'back-up'... And we've seen in another thread that Digikam doesn't play
> nice with hard-linked files, either.
>
> Remco
>
> P.S. @John: this is not to attack you, but hard links are a slightly more
> advanced feature, and if someone thinks that they work as a backup, they could
> be in for a lot of grief...

I quite agree that a hard-linked tree copy is not a proper backup. Maybe
I shouldn't even have used the word 'backup' where I did. Anyone who has
a collection of photographs that matter to them and doesn't have proper
backups is certain of grief sooner or later!

However the linked tree copy is very useful when one is doing all sorts
of things with your directory structure, and many things that modify
files (since most utilities that modify files do break hard links).

For example I've used it when I renamed all my photographs from their
original dscn_1234.jpg type names to include date+time-stamps - a tree
containing 10s of Gigabytes. It means that if your renaming command goes
irretrievably wrong you save an enormous amount of time by simply
deleting the messed-up tree and renaming the backup tree, rather than
copying back all the files from your backup system.

So, agreed: linked-tree is not a substitute for a proper backup. But it
is a useful tool.

--
John Stumbles                                    http://stumbles.org.uk
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

> hard links are a slightly more
> advanced feature, and if someone thinks that they work as a backup, they
> could
> be in for a lot of grief...

I'm not exactly a linux newbie anymore, but I don't know anything at
all about hard links and backups.

Fwiw, I just make a straightforward duplicate copy of my image files
on a separate hard drive before doing any major changes with *any*
software. I've been very glad to have that backup when digiKam has
done a few bad things now and again.

Exiftool is quite powerful and can modify and move a whole bunch of
files around really quickly. So it is only common sense to test before
deploying, and have a backup just in case you get the syntax wrong.

Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 31/05/2012 18:09, John Stumbles a écrit :

> It's not bulletproof: since the files are hard-linked any utility that
> changes the contents of the file in one location without breaking the
> link will change it in the other location as well.
>
>
so it's of no use here :-(

anyway I never, never work on the original files!

thanks
jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 31/05/2012 17:21, Elle Stone a écrit :

> Test, test, and retest in a test directory on a small sample of images

command line tools are invaluable in that they report errors.

The ùessage below says there is somewhere an error. However, most kde
tool *know* the image orientation, so may be the error is not the one
given here?

for example, dolphin displays by default the images with the right
orientation (that is vertical images are displayed vertical,
acknowledging the tag). Genview display the image and the tag value
correctly.

Digikam?? I don't know what digikam do. I use the 2.6RC, now. Whatever
I try to do, the image is correctly displayed (vertical images are
displayed vertically), but the exif tag is never changed (kept right,
top when is should be top, left.

do digikam try to use the very same exif command line as below??

any idea of solution?
thanks
jdd

exiftool -n -r -overwrite_original -if '$Orientation ne 1'
-Orientation=1 .
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.33.12.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.35.14.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.35.36.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.37.33.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.40.00.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.41.47.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.42.02.jpg
Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
18.53.37.jpg
     1 directories scanned
    33 files failed condition
     0 image files updated
     8 files weren't updated due to errors

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

Hmm, my apologies, now I'm not sure what you really want to do.
digiKam doesn't use exiftool at all. digiKam has had a problem with
orientation tag for a while now. It's been reported as a bug by
several people. My solution was to use exiftool to set the orientation
flag to normal and also rotate the image by hand so it really was
normal. That way there was no way that digiKam could get confused.

Here's what the exiftool documentation says about bad makernotes:

http://www.sno.phy.queensu.ca/~phil/exiftool/faq.html  See faq 15,
which says in part:
15. "I get MakerNote warnings or errors when reading or writing information"

    "Problems like this may be caused by image editing software which
doesn't properly update offsets in the MakerNotes when rewriting an
image. These offsets are used as pointers to reference tag values and
structures within the metadata, and errors like this may lead to
missing or incorrect values for some makernote tags. In many cases,
ExifTool will detect this type of problem and issue a warning like
this:  . . .  If this warning occurs, you can use the -F option to
attempt to fix the problem. If no value is specified with -F, the
suggested fix is applied (ie. in this example a value of "-340" is
suggested, so here -F would be equivalent to -F-340). See the -F
option documentation for details."

Anyway, if I've misled you, I apologize. And obviously if you shoot
raw, you can't rotate the embedded raw file preview, at least I don't
think you can. I don't let digiKam handle my raw files, only the
extracted jpeg previews. So probably you should ignore everything I've
said.

Elle, crawling back under a rock.




On 5/31/12, jdd <[hidden email]> wrote:

> Le 31/05/2012 17:21, Elle Stone a écrit :
>
>> Test, test, and retest in a test directory on a small sample of images
>
> command line tools are invaluable in that they report errors.
>
> The ùessage below says there is somewhere an error. However, most kde
> tool *know* the image orientation, so may be the error is not the one
> given here?
>
> for example, dolphin displays by default the images with the right
> orientation (that is vertical images are displayed vertical,
> acknowledging the tag). Genview display the image and the tag value
> correctly.
>
> Digikam?? I don't know what digikam do. I use the 2.6RC, now. Whatever
> I try to do, the image is correctly displayed (vertical images are
> displayed vertically), but the exif tag is never changed (kept right,
> top when is should be top, left.
>
> do digikam try to use the very same exif command line as below??
>
> any idea of solution?
> thanks
> jdd
>
> exiftool -n -r -overwrite_original -if '$Orientation ne 1'
> -Orientation=1 .
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.33.12.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.35.14.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.35.36.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.37.33.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.40.00.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.41.47.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.42.02.jpg
> Error: [minor] Bad MakerNotes offset for tag 0x0 - ./2012-05-29
> 18.53.37.jpg
>      1 directories scanned
>     33 files failed condition
>      0 image files updated
>      8 files weren't updated due to errors
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
Elle Stone
http://ninedegreesbelow.com
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 31/05/2012 20:43, Elle Stone a écrit :
> Hmm, my apologies, now I'm not sure what you really want to do.

I simply want my online gallery (http://dodin.org/piwigo/index.php) to
display images on a visible way :-)

> digiKam doesn't use exiftool at all.

are you shure?

  digiKam has had a problem with
> orientation tag for a while now.

yes I know, but don't understand why (there may be very valuable answers)

  It's been reported as a bug by
> several people. My solution was to use exiftool to set the orientation
> flag to normal and also rotate the image by hand so it really was
> normal. That way there was no way that digiKam could get confused.

that was waht I expected

>
> Here's what the exiftool documentation says about bad makernotes:

I will try this. I used the exact image from my Samsung S, with no
change whatsoever

> Anyway, if I've misled you, I apologize.

no reason to apologize, you sent me in the good direction. Just have t
refine :-)

thanks
jdd

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

On 5/31/12, jdd <[hidden email]> wrote:

>> digiKam doesn't use exiftool at all.
>
> are you shure?

Yes, very sure. digiKam uses exiv2. See:
http://dev.exiv2.org/projects/exiv2/wiki/How_does_Exiv2_compare_to_Exiftool

>   digiKam has had a problem with
>> orientation tag for a while now.
>
> yes I know, but don't understand why (there may be very valuable answers)
I don't understand why, either. You could check the bug reports, but I
don't recall anything particularly helpful in them (been a long time
since I checked).

Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hello

I'm going a bit ahead. May be I found a possible understanding of the
problem.

jpg image have both a main image and a thumbnail. Looks like both have
exifs and orientation.

an example image gives:

exiv2 -pv 12.jpg | grep Orientation

12.jpg  0x0112 Image Orientation Short 1  6
12.jpg  0x0112 Thumbnail Orientation Short 1  6

changing orientation gives:

exiv2 -M"set Exif.Image.Orientation 1" 12.jpg
exiv2 -pv 12.jpg | grep Orientation

12.jpg  0x0112 Image Orientation Short 1  1
12.jpg  0x0112 Thumbnail Orientation Short 1  6

notice only the image orientation is changed, not the thumbnail one.

I can't figure out how to change also the thumbnail orientation, may
be somebody can help? May be some applications a disturbed by the fact
that image and thumbnail orientation is not the same?

thanks
jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[John Stumbles]

On 01/06/12 09:03, jdd wrote:

> jpg image have both a main image and a thumbnail. Looks like both have
> exifs and orientation.

...

> notice only the image orientation is changed, not the thumbnail one.
>
> I can't figure out how to change also the thumbnail orientation, may be
> somebody can help? May be some applications a disturbed by the fact that
> image and thumbnail orientation is not the same?

I think I have some pictures like that - in dolphin's icon view (which I
guess uses the images' thumbnails) they look as if they need rotating,
but if I open them in gwenview (which, I guess, shows the main image)
they are correctly oriented.

If exiv2 doesn't work maybe try exiftool?

--
John Stumbles                                    http://stumbles.org.uk
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 01/06/2012 10:15, John Stumbles a écrit :

> I think I have some pictures like that - in dolphin's icon view (which
> I guess uses the images' thumbnails) they look as if they need
> rotating, but if I open them in gwenview (which, I guess, shows the
> main image) they are correctly oriented.
>
> If exiv2 doesn't work maybe try exiftool?
>

I will, but I probably simply miss an option :-)

as I try to fix a digikam problem, better try to use the same tools as
digikam do :-)

jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hello,

On Thu, 31 May 2012, Elle Stone wrote:

> ...
> My solution was to use exiftool to set the orientation flag to normal
> and also rotate the image by hand so it really was normal.
> ...

As a possible alternative, the `convert' program (from ImageMagik
package), has an auto-orient command that looks close to what you do
by hand :

-- (Copy/paste from the convert man page)

   -auto-orient
    Automagically orient (rotate) an image created by a digital camera.

    This operator reads and resets the EXIF image profile setting
    'Orientation' and then performs the appropriate 90 degree rotation on
    the image to orient the image, for correct viewing.
--



* The following is a bit off topic, just a personal comment about
some metadata edition problems (both with exiftool or exiv2).

> ...
> Here's what the exiftool documentation says about bad makernotes:
>
> http://www.sno.phy.queensu.ca/~phil/exiftool/faq.html  See faq 15,
> which says in part:
> 15. "I get MakerNote warnings or errors when reading or writing information"
>
>    "Problems like this may be caused by image editing software which
> doesn't properly update offsets in the MakerNotes when rewriting an
> image.
> ...

This is a nightmare. Phil Harvey is right when saying "may be caused by
image editing software", but not only. Problems may also be caused by
not perfectly supported makernotes.
I have both problems with one of my cameras (Nikon D3100 with v1.01
firmware).
Even with original images (e.g. out of camera JPEGs), I get warnings
  "Suspicious MakerNotes offset ..."
and after image edition, using The GIMP, I sometime get read errors
  "Bad MakerNotses offset ..."
that prevent rewriting the file with edited metadata.

So, clearly, the editing software doesn't agree with exiftool.
But exiftool doesn't agree neither with the camera firmware producing
the original EXIF section.

Who's right ? I don't know.
Who's stuck ? Me :-)

I live with that, but it requires to do editions in the proper order,
EXIF data edition - if any - first, then image edition after.
If I forget the rule and do some GIMP work first, I can't do anything
with exiftool after that.

Regards,

Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 01/06/2012 11:32, Jean-François Rabasse a écrit :

> As a possible alternative, the `convert' program (from ImageMagik

oh, thats vrey good, in fact I already use it to make online formatted
images, I will add this there!

thanks!

> This is a nightmare. Phil Harvey is right when saying "may be caused
> by image editing software", but not only.

the worst thing is that most explorer try to read exif to rotate the
shown image, so it's extremely difficult to know what is *in* the real
image

> I live with that, but it requires to do editions in the proper order,
> EXIF data edition - if any - first, then image edition after.
> If I forget the rule and do some GIMP work first, I can't do anything
> with exiftool after that.

same kind of problems...

thanks
jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

may be I don't read right the exifs in digikam... but I'm extremely
puzzled.

from original jpg files, I do this in a sh script:

mkdir thumbnail
mkdir pwg_high

for I in *.jpg ; do
        convert -auto-orient -resize 1800x1800 $I pwg_high/$I ;
        convert -resize 800x800 pwg_high/$I $I ;
        convert -resize 128x128 pwg_high/$I thumbnail/TN-$I ;
       
done


this first copy a file with the maximum size 1800 pixels, whatever
horizontal or vertical in the high quality folder.

(new) in the mean time it normalize the orientation.

then from this very image it creates the medium (current) quality
image (erasing the original one - always work on a copy!), then the
thumbnail for album view.

All this is for piwigo use.

I copied a two images example here:

http://dodin.org/temp/20120529-cara.tar.gz

As far as I understand, the three related images should have the same
orientation, no?

in dolphin, it's ok

In my 2.6.0 digikam (Date de construction : May 11 2012 (cible :
release)), the "normal" (600x800) image is rotated to the right, the
two others are seen normally, vertical.

exifs seems to be exactly the same for the three images.

the three other images are as expected.

do you have the same result? any idea??

thanks
jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 01/06/2012 16:19, jdd a écrit :

> In my 2.6.0 digikam (Date de construction : May 11 2012 (cible :
> release)), the "normal" (600x800) image is rotated to the right, the
> two others are seen normally, vertical.

showfoto opens all the images correctly. Genview all rotated :-(

jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

On Fri, 1 Jun 2012, jdd wrote:

> As far as I understand, the three related images should have the same
> orientation, no?
>
> in dolphin, it's ok
>
> In my 2.6.0 digikam (Date de construction : May 11 2012 (cible : release)),
> the "normal" (600x800) image is rotated to the right, the two others are
> seen normally, vertical.

Looking at your six images with firefox (firefox doesn't put its nose into
EXIF stuff and displays JPEGs as scan lines are found) all seems correct.

What you call « normal » image is the image with same filename as the
initial one (your $I under shell).
Maybe Digikam has already seen this image under this name, before your
processing.
DK keeps image orientation in the database (table ImageInformation,
field orientation) and possibly didn't reload infos after you've run
your script, thus keeping a wrong orientation information.

Should try to copy your image under a different fresh new name, and
rstart Digikam to let it get « new image »...
Or tell DK to « Reread metadata from images files ».

Regards,

Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 01/06/2012 18:12, Jean-François Rabasse a écrit :

> Should try to copy your image under a different fresh new name, and
> rstart Digikam to let it get « new image »...

no change (close digikam, change name, open again digikam, no change)

but I could rotate the image in digikam and get it right, with no
change in exifs (I have the options "write changes in exifs on!"

pretty hard to understand

thanks
jdd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users