Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17200 > unrolled thread

prob with exec, exiftool and one photo

Back to article view | Back to comp.lang.php

Contents

  prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-13 17:14 +0100
    Re: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-13 17:15 +0100
    Re: prob with exec, exiftool and one photo "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-12-13 17:28 +0100
      Re: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-13 18:23 +0100
        Re: prob with exec, exiftool and one photo "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-12-14 00:19 +0100
    Re: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-13 18:03 +0100
      Re: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-13 18:28 +0100
    Re: prob with exec, exiftool and one photo "J.O. Aho" <user@example.net> - 2016-12-13 23:42 +0100
      Re: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-14 07:02 +0100
        Re: prob with exec, exiftool and one photo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 17:37 +0100
          Re: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-14 18:13 +0100
    [BADLY SOLVED]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-14 08:11 +0100
      Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 17:43 +0100
        Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-14 18:24 +0100
          Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 19:57 +0100
        Re: [BADLY SOLVED]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-14 19:01 +0100
          Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 19:39 +0100
            Re: [BADLY SOLVED]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-17 09:11 +0100
              Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:33 -0500
          Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-15 06:19 +0100
      Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Eli the Bearded <*@eli.users.panix.com> - 2016-12-14 22:19 +0000
        Re: [BADLY SOLVED]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-15 06:30 +0100
        [UNSOLVABLE]: prob with exec, exiftool and one photo Une Bévue <unbewusst@fai.invalid> - 2016-12-17 08:08 +0100
          Re: [UNSOLVABLE]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-17 09:26 +0100
            Re: [UNSOLVABLE]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-17 10:45 +0100
              Re: [UNSOLVABLE]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-17 11:41 +0100
                Re: [UNSOLVABLE]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-17 17:39 +0100
                  Re: [UNSOLVABLE]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-18 10:27 +0100
                    Re: [UNSOLVABLE]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-21 11:36 +0100
                      Re: [UNSOLVABLE]: prob with exec, exiftool and one photo "R.Wieser" <address@not.available> - 2016-12-21 16:58 +0100
                        Re: [UNSOLVABLE]: prob with exec, exiftool and one photo Une Bévue <unbewusst.sein@fai.invalid> - 2016-12-22 07:08 +0100

Page 2 of 2 — ← Prev page 1 [2]

#17217 — Re: [BADLY SOLVED]: prob with exec, exiftool and one photo

In comp.lang.php, Une Bévue  <unbewusst.sein@fai.invalid> wrote:
> from command line, using :
> exiftool  -s 
> '/Users/yt/Sites/tests/Flipping_image/photos/20161202_085945.jpg'
> 
> i saw a faulty encoding line :
> Comment                         : File written by Adobe Photoshop� 5.0
> looks here_______________________________________________________^_____

Not-so-much faulty as software that doesn't understand character set
encodings. JPEG comments are a 32,767 octet block of whatever randomness
you want to put in there. There is no way to indicate what encoding or
set of characters are represented. Adobe is probably just using
something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
like Windows-1250 or Windows-1252.

The JPEG file format dates back to the bad old days of "ASCII is good
enough for everyone (but we'll grudgingly allow EBCIDIC, too)".

http://www.unicode.org/history/publicationdates.html
	1.0.0 	1991 	October

http://fileformats.archiveteam.org/wiki/JFIF
	JFIF 1.00 (undated)
	JFIF 1.01 (1991-12-10) may have changed the subsampling
	     position to centered. 

(JFIF is JPEG File Interchange Format; that was the first standardized
way to store JPEG compressed data; now JPEG could be JFIF or Exif, which
is a modified JFIF.)

Elijah
------
(would recommend ignoring pointedly-rude pointedears)

[toc] | [prev] | [next] | [standalone]

#17219 — Re: [BADLY SOLVED]: prob with exec, exiftool and one photo

Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> Adobe is probably just using
> something stupid like ISO-8859-1 or (worse) the Microsoft "equivilents"
> like Windows-1250 or Windows-1252.

I do agree with that, because when using exiftool by command line on 
terminal I get a question mark in a square instead of ®.
Generally it is due to ISO-8859-1 coded character in US_ASCII / UTF-8.
By terminal (macOS Sierra) works well with UTF-8 even with 🍺...

[toc] | [prev] | [next] | [standalone]

#17221 — [UNSOLVABLE]: prob with exec, exiftool and one photo

Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> Not-so-much faulty as software that doesn't understand character set
> encodings.

In fact, after reading the photo content it appears that the only wrong 
"character" is Ⓡ (C2 AE in UTF-8) encoded in MacRoman as "A8" in this 
file who's encoding is UTF-8.

No way to change that any :
-charset exif=MacRoman, doesn't work.

[toc] | [prev] | [next] | [standalone]

#17223 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Une,

I don't think its unsolvable, but maybe it takes a bit more work.

Going back to your first post:

   $EXIFTOOL = '/usr/local/bin/exiftool';
   $cmd = "$EXIFTOOL " . $data['PATH'];
   exec($cmd, $Infos, $ExitStatus);
   foreach($Infos as $line) {
     $fields = explode(' : ', $line, 2 );
     if(count($fields) == 2) {
       $data[rtrim($fields[0])] = $fields[1];
     }
   }
   $data['ExitStatus'] = $ExitStatus;

Have you ever display the contents of the $Infos array (print_r) ?   Did it
contain anything ?    If it does, have you displayed the contents of each
$line ?

If $Infos doesn't contain anything you might do a google for information
about that "exec" command in combination with character encodings.

But if you just want the data you could try to output the exif data into a
file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
contains the data.   If it does you could see what happens when you try to
parse that file (even if it does not work you're likely to get a usable
error).

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewusst@fai.invalid> schreef in berichtnieuws
o32o8o$ec2$1@shakotay.alphanet.ch...
> Le 14/12/2016 à 23:19, Eli the Bearded a écrit :
> > Not-so-much faulty as software that doesn't understand character set
> > encodings.
>
> In fact, after reading the photo content it appears that the only wrong
> "character" is ? (C2 AE in UTF-8) encoded in MacRoman as "A8" in this
> file who's encoding is UTF-8.
>
> No way to change that any :
> -charset exif=MacRoman, doesn't work.
>
>

[toc] | [prev] | [next] | [standalone]

#17224 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Le 17/12/2016 à 09:26, R.Wieser a écrit :
> Have you ever display the contents of the $Infos array (print_r) ?   Did it
> contain anything ?    If it does, have you displayed the contents of each
> $line ?

As I said : no output at all !

> If $Infos doesn't contain anything you might do a google for information
> about that "exec" command in combination with character encodings.

Yes, right, but, from carfull hex reding of the datascontained in this 
photo, the encoding of the exif part (and like) is in UTF-8 only one 
character is in MacRoman.

> But if you just want the data you could try to output the exif data into a
> file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the file
> contains the data.   If it does you could see what happens when you try to
> parse that file (even if it does not work you're likely to get a usable
> error).

Obviously, this should work reading the "temp.dat" in byte mode (as of a 
binary file) then, rewriting "A8" (ie. MacRoman) to "C2 AE" (UTF-8).

Rather heavy for one char isnt'it?

I'll try that this afternoon...

[toc] | [prev] | [next] | [standalone]

#17225 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Une,

> > Have you ever display the contents of the $Infos array (print_r) ?
> > Did it contain anything ?    If it does, have you displayed the contents
> > of each $line ?
>
> As I said : no output at all !

Yeah, but as far as I can tell you have just been looking at the $data array
result, not at any of the intermediate variables.    Correct me if I'm
wrong.

> Obviously, this should work reading the "temp.dat" in byte mode

You do not understand: If that file gets filled with data it stands to
reason that the $Infos variable also gets filled.   If the file gets filled
but the variable not then there would be something rather odd on, possibly
with the "exec" command (on the other hand, that "exec" command may be
exactly doing what its told to do, and we simply are not aware of what it
has been told :-) ).

In other words: I'm not working towards a solution, I'm working towards
figuring out where the problem actually occurs, and what causes it.  Which
those two in hand you're much more likely to find a/the solution.

Also, with that temp file you have a possibility to check what's *really*
been outputted.    Maybe you'll even find that there is a ctrl-z in there
(EOF), causing the capturing of standard output (from the exiftool) to
terminate early.  Who knows.

> Rather heavy for one char isnt'it?

If its really only for that one character, and you already have a method to
deal with it than I could agree with you.    But as you have no idea what
actually causes the problem of the character resulting in an emptyresult you
might be bumping into other characters causing the same effect too.    And
ofcourse, if we may take Murphy's Law as a guideline, at the most
in-opportune moment imaginable. :-)

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o331fg$vqi$1@shakotay.alphanet.ch...
> Le 17/12/2016 à 09:26, R.Wieser a écrit :
> > Have you ever display the contents of the $Infos array (print_r) ?   Did
it
> > contain anything ?    If it does, have you displayed the contents of
each
> > $line ?
>
> As I said : no output at all !
>
> > If $Infos doesn't contain anything you might do a google for information
> > about that "exec" command in combination with character encodings.
>
> Yes, right, but, from carfull hex reding of the datascontained in this
> photo, the encoding of the exif part (and like) is in UTF-8 only one
> character is in MacRoman.
>
> > But if you just want the data you could try to output the exif data into
a
> > file ("'/usr/local/bin/exiftool' > temp.dat"), and than check if the
file
> > contains the data.   If it does you could see what happens when you try
to
> > parse that file (even if it does not work you're likely to get a usable
> > error).
>
> Obviously, this should work reading the "temp.dat" in byte mode (as of a
> binary file) then, rewriting "A8" (ie. MacRoman) to "C2 AE" (UTF-8).
>
> Rather heavy for one char isnt'it?
>
> I'll try that this afternoon...
>

[toc] | [prev] | [next] | [standalone]

#17227 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Le 17/12/2016 à 11:41, R.Wieser a écrit :
> Une,
>
>>> Have you ever display the contents of the $Infos array (print_r) ?
>>> Did it contain anything ?    If it does, have you displayed the contents
>>> of each $line ?
>> As I said : no output at all !
> Yeah, but as far as I can tell you have just been looking at the $data array
> result, not at any of the intermediate variables.    Correct me if I'm
> wrong.

No no, because $Infos is supposed to be an array, I've put in data output :

$data['count_infos'] = count($Infos);

giving 0

also I've tried :

shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);

no "/path/to/some.file" created.

another way, with system :

$result = system($cmd, $ExitStatus);

and with intermediate file :

$result = system("$cmd > /path/to/some.file", $ExitStatus);

again no "/path/to/some.file" created.

in both cases $result = ''
and $ExitStatus = 1

doing the same on terminal using :
$ exiftool 20161202_085945.jpg > 20161202_085945.txt
$ cat 20161202_085945.txt
ExifTool Version Number         : 10.20
File Name                       : 20161202_085945.jpg
Directory                       : .

[...]

Comment                         : File written by Adobe Photoshop� 5.0

[...]

Circle Of Confusion             : 0.004 mm
Field Of View                   : 60.3 deg
Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
Hyperfocal Distance             : 1.47 m


>> Obviously, this should work reading the "temp.dat" in byte mode
> You do not understand: If that file gets filled with data it stands to
> reason that the $Infos variable also gets filled.

right, however, see above...

> If the file gets filled
> but the variable not then there would be something rather odd on, possibly
> with the "exec" command (on the other hand, that "exec" command may be
> exactly doing what its told to do, and we simply are not aware of what it
> has been told :-) ).
>
> In other words: I'm not working towards a solution, I'm working towards
> figuring out where the problem actually occurs, and what causes it.  Which
> those two in hand you're much more likely to find a/the solution.

right

> Also, with that temp file you have a possibility to check what's *really*
> been outputted.    Maybe you'll even find that there is a ctrl-z in there
> (EOF), causing the capturing of standard output (from the exiftool) to
> terminate early.  Who knows.

here I don't understand really your speaking because, i did this 
experiment using command line on Terminal where I see � instead of ®.
even I examined the photo file itself using on hex Editor (reading the 
file as a binary one and listing all the bytes in hex format).

>> Rather heavy for one char isnt'it?
> If its really only for that one character, and you already have a method to
> deal with it than I could agree with you.    But as you have no idea what
> actually causes the problem of the character resulting in an emptyresult you
> might be bumping into other characters causing the same effect too.    And
> ofcourse, if we may take Murphy's Law as a guideline, at the most
> in-opportune moment imaginable. :-)

you're right again, Murphy's Law must be my guideline here.

> Regards,
> Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17228 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Une,

> No no, because $Infos is supposed to be an array,

I know.    Thats why I suggested that "print_p" command.  It can display the
contents of an array.   Like so: "print_p($Infos)".

... though I just noticed that I'm using "print_r" myself instead ....

> $data['count_infos'] = count($Infos);
>
> giving 0

Well, you're right in that that is a good indication nothing is in there.

> also I've tried :
>
> shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);
>
> no "/path/to/some.file" created.

Have you tried that with any of the images which normally do give usefull
output ?    They certainly should give some output.  If they also don't than
maybe the method we're trying to use is incorrect.

...  I've just tested what would happen when I would use that command myself
(using a ZWAMP installation, PHP 5.3.3), and have no problems with either
capturing a programs output, or redirecting it to a file.

I also made the program output all characters from 0x01 thru 0xFF, and had
no problem with capturing that output either.

So, I can't recreate your problem and I'm also outof ideas to try.   Sorry.

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o33pop$ccm$1@shakotay.alphanet.ch...
> Le 17/12/2016 à 11:41, R.Wieser a écrit :
> > Une,
> >
> >>> Have you ever display the contents of the $Infos array (print_r) ?
> >>> Did it contain anything ?    If it does, have you displayed the
contents
> >>> of each $line ?
> >> As I said : no output at all !
> > Yeah, but as far as I can tell you have just been looking at the $data
array
> > result, not at any of the intermediate variables.    Correct me if I'm
> > wrong.
>
> No no, because $Infos is supposed to be an array, I've put in data output
:
>
> $data['count_infos'] = count($Infos);
>
> giving 0
>
> also I've tried :
>
> shell("$cmd > /path/to/some.file", $Infos, $ExitStatus);
>
> no "/path/to/some.file" created.
>
> another way, with system :
>
> $result = system($cmd, $ExitStatus);
>
> and with intermediate file :
>
> $result = system("$cmd > /path/to/some.file", $ExitStatus);
>
> again no "/path/to/some.file" created.
>
> in both cases $result = ''
> and $ExitStatus = 1
>
> doing the same on terminal using :
> $ exiftool 20161202_085945.jpg > 20161202_085945.txt
> $ cat 20161202_085945.txt
> ExifTool Version Number         : 10.20
> File Name                       : 20161202_085945.jpg
> Directory                       : .
>
> [...]
>
> Comment                         : File written by Adobe Photoshop? 5.0
>
> [...]
>
> Circle Of Confusion             : 0.004 mm
> Field Of View                   : 60.3 deg
> Focal Length                    : 3.7 mm (35 mm equivalent: 31.0 mm)
> Hyperfocal Distance             : 1.47 m
>
>
> >> Obviously, this should work reading the "temp.dat" in byte mode
> > You do not understand: If that file gets filled with data it stands to
> > reason that the $Infos variable also gets filled.
>
> right, however, see above...
>
> > If the file gets filled
> > but the variable not then there would be something rather odd on,
possibly
> > with the "exec" command (on the other hand, that "exec" command may be
> > exactly doing what its told to do, and we simply are not aware of what
it
> > has been told :-) ).
> >
> > In other words: I'm not working towards a solution, I'm working towards
> > figuring out where the problem actually occurs, and what causes it.
Which
> > those two in hand you're much more likely to find a/the solution.
>
> right
>
> > Also, with that temp file you have a possibility to check what's
*really*
> > been outputted.    Maybe you'll even find that there is a ctrl-z in
there
> > (EOF), causing the capturing of standard output (from the exiftool) to
> > terminate early.  Who knows.
>
> here I don't understand really your speaking because, i did this
> experiment using command line on Terminal where I see ? instead of ®.
> even I examined the photo file itself using on hex Editor (reading the
> file as a binary one and listing all the bytes in hex format).
>
> >> Rather heavy for one char isnt'it?
> > If its really only for that one character, and you already have a method
to
> > deal with it than I could agree with you.    But as you have no idea
what
> > actually causes the problem of the character resulting in an emptyresult
you
> > might be bumping into other characters causing the same effect too.
And
> > ofcourse, if we may take Murphy's Law as a guideline, at the most
> > in-opportune moment imaginable. :-)
>
> you're right again, Murphy's Law must be my guideline here.
>
> > Regards,
> > Rudy Wieser
>

[toc] | [prev] | [next] | [standalone]

#17229 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Le 18/12/2016 à 10:27, R.Wieser a écrit :
> Have you tried that with any of the images which normally do give usefull
> output ?

Obviously, yes, that gaves me the correct number of lines.

[toc] | [prev] | [next] | [standalone]

#17230 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Une,

> Obviously,

:-) For you that might be.  For large swats of people its not.   And even
for the smarter 'uns it simply might have simply slipped their mind.

> yes, that gaves me the correct number of lines.

Good.   I asked to make sure that the problem was indeed only present with
that one image.  You might be amazed how many people forget that kind of
stuff, and only after days of effort suddenly find the problem is not at all
unique to to what they thought it was.

But as I already said, I'm out of ideas.

Regards,
Rudy Wieser


-- Origional message:
Une Bévue <unbewusst.sein@fai.invalid> schreef in berichtnieuws
o3dlum$uro$1@shakotay.alphanet.ch...
> Le 18/12/2016 à 10:27, R.Wieser a écrit :
> > Have you tried that with any of the images which normally do give
usefull
> > output ?
>
> Obviously, yes, that gaves me the correct number of lines.
>

[toc] | [prev] | [next] | [standalone]

#17231 — Re: [UNSOLVABLE]: prob with exec, exiftool and one photo

Le 21/12/2016 à 16:58, R.Wieser a écrit :
> But as I already said, I'm out of ideas.

me 2

best,

Yvon

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web