How to write Photoshop paths (0x07d0)

[Archive]

[Originally posted by alexg on 2006-10-25 19:08:03-07]

Hi,

I want to transfer Photoshop paths around, form and to jpg and tiff files. exiftool can extract them (Photoshop_0x07d0 - 0x0bb6). However I'm unable to store them in another file. I think exiftool -TagsFromFile mit.jpg -Photoshop_0x07d0 -U -b -m ohne.tiff  should be correct. Any ideas? An interpretation of the tag is not neccessary.

regards
Alex

[Archive]

[Originally posted by exiftool on 2006-10-25 19:36:47-07]

To write any unknown tag (or change the definition of any existing tag), all you have
to do is add an entry to the config file.  In your case, this entry in the
%Image::ExifTool::UserDefined hash will do it:

Code:

   'Image::ExifTool::Photoshop::Main' => {
        0x07d0 => {
            Name => 'PathInfo',
            Writable => 1,
            ValueConv => '\$val',
            ValueConvInv => '$val',
        },
    },

(The value conversions are not strictly required, but will prevent binary data from being
sent to your console if you extract this tag.)  With this addition, you would use the
following command line:

Code:

exiftool -TagsFromFile mit.jpg -pathinfo ohne.tiff

See the
ExifTool_config
file included with in the ExifTool distribution for more details.

- Phil

[Archive]

[Originally posted by exiftool on 2006-10-25 19:54:04-07]

Just one more thought:  Since you probably don't want this information to be
copied by default, you may want to "Protect" this tag so it won't be copied
unless you specify it explicitly:

Code:

   'Image::ExifTool::Photoshop::Main' => {
        0x07d0 => {
            Name => 'PathInfo',
            Writable => 1,
            Protected => 1,
            ValueConv => '\$val',
            ValueConvInv => '$val',
        },
    },

- Phil

[Archive]

[Originally posted by alexg on 2006-10-30 16:29:48-08]

Great, that works like a charm.
Any idea how I can transfer all 998 possible paths (if avalilible, of course). I think adding 1000 config file entries and havong 1000 command line options is a bit overkill....

regards
Alex

[Archive]

[Originally posted by exiftool on 2006-10-30 16:48:06-08]

alexg wrote:

"Great, that works like a charm. Any idea how I can transfer
all 998 possible paths (if avalilible, of course). I think adding
1000 config file entries and havong 1000 command line options
is a bit overkill...."

I was afraid you were going to ask that.  Unfortunately for now,
adding 1000 user-defined tags is the only option.  Although you
can save all the typing on the command line by defining a shortcut
in your configuration file to represent all 1000 tags.  Then you only
have to live with an extremely long config file, which isn't all that bad.

- Phil

[Archive]

[Originally posted by alexg on 2006-11-02 20:49:41-08]

Hi,
first of all thanks for your great support so far.
I managed to get a configuration file (http://www.grans.eu/exiftoolconfig) with an alias and all 1000 pathtags included (wrote a small java programm to generate the file
However I just relized that the path names aren't transfered:
In the file you've got something like:
.... 0x3842494d 0x07d0 0x06 "Pfad 1" some 0x00 Pathdata...
If I understod correctly, 0x3842494d="8BIM" is the Photoshop marker, folled by the Path tag 0x07d0. 0x06 seems to be the length of the Path name (6 here, if the Path is called "Pfad 11" its 0x07). However exiftool skips over the path name, and doesn't insert it into the destination file. Do you have an idea how to copy that, too?
regards
Alex

[Archive]

[Originally posted by exiftool on 2006-11-02 22:39:15-08]

Ouch.  That is unfortunate.  Currently ExifTool writes all
new Photoshop tags with an empty name.

If the names are constant for each tag ID, then I could add
a feature to allow you to specify them in the config file.
But there isn't such an easy solution if you want to also copy
the names from another file. I would have to think about this
a bit more if this were the case.

- Phil

[Archive]

[Originally posted by exiftool on 2006-11-04 11:29:37-08]

I've done some more thinking about the IRB resource names, and
have come   up with a system that allows you to 1) preserve
resource names when copying Photoshop tags between files,
2) define new resource names  when writing new tags, and
3) define default resource names to be used when writing.
I think this covers all the bases.

I have just released
ExifTool 6.54
with this update.

In your case, I think you probably just want to preserve the
existing resource names, in this case all you have to do is
define a "SetResourceName" flag in the tag information hash
for the desired tag.  I have done this for you in your config
file and posted it
here

As well, I have added a couple of new features that allow the config  
file to be simplified somewhat.

I hope this helps.

- Phil

[Archive]

[Originally posted by alexg on 2006-11-15 23:26:03-08]

Hi Phil,

thanks again for your ligthnig fast responses, I actually don't have the time to be as fast
You changes basically seem to work. However in a sample image with 11 paths, number 7 gets wrong, and photoshop cannot read the image paths afterwards ("Error parsing path data")
I've uploaded the source image http://www.grans.eu/Source.jpg the target image without Ressourcenames (which works) http://www.grans.eu/TargetPath.jpg and the target image with Ressourcenames http://www.grans.eu/TargetPathName.jpg. If you look at the path number 7 (0x3842494d07d6 or 8BIM+0x07d6, offset 0x3dd0) the path name is way afterwards (offset 0x3e85-7, "Pfad 7"). All other paths are ok, I think.
I've used exiftool version 6.56.

regards
Alex

[Archive]

[Originally posted by exiftool on 2006-11-16 02:49:55-08]

Hi Alex,

Sorry for being so quick...  First of all, thanks for the sample, this
was a tricky bug that would have been very hard to track down with
this.

There was a problem in the new "SetResourceName" feature that
caused it to fail if a specific byte pattern appeared in the path data.
Fortunately your sample contained this pattern, otherwise this bug
could have lurked silently for quite some time.  I have fixed this now,
and the new code should be immune to arbitrary byte patterns in
the path data.

This update will appear in version 6.57, and I have uploaded a
6.57
pre-release in case you get a chance to test it out before the
official 6.57 release.

- Phil