Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

Custom XMP Panels in Adobe CS-5 and Xinet Venture

Posted by Robert Sullivan on Wed, Jul 14, 2010 @ 04:38 PM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

You may have seen some of the videos we have about importing custommetadata panels from Adobe, into the Venture database. In Adobe CS-3a custom panel was fairly easy to create because it was a single textfile. That got a little more complicated with CS-4 when Adobe changedto a Flex file format that requires several files in combination tocorrectly create a custom data panel.

Now CS-5 is slightly different again and the panels from CS-4 do notjust show up in CS-5. More modification is required to stay current.

Flathead-U has a few videos showing how to import these customizedpanels into Venture and that's great, but it's been pointed out to me ina not so subtle way, that a lot of people don't understand how it all works.

Here is a brief explanation of how it works, in my own layman's terms.I'm sure you'll all let me know what I have right and what I have wrong,( as if..! )

So lets take a piece of one sample data field.

<xmp_property name="SulTextHack" category="external" label="Sul Text:" type="text"/>

The "xmp_property name" must be xmp compatible, meaning there are no spaces inthe field name and no special characters. In the example, "SulTextHack" is thexmp name of the field, and this must match (case sensitive) between Adobe Appsand the Venture database. If they don't match, they will NOT map to one another.Meaning they will be two different fields from one program to the other.

Only when the XMP name of the field is mapped correctly will you have thebidirectional edit ability. Meaning you can make changes to the data fieldvalue from either program and have it show that change in the other program.The trick here is that both programs are writing 'into' the XMP space ofthe file. The data is pushed into the file it's-self. So the data value isin the Venture database but it's also imbedded in the file.It's like the old Spaghetti TV commercial where they say:

"Eh, it's in there"

The category= determines if it's editable, "external" or read only, "display"from within the Adobe programs. So you can configure a custom field from theVenture database and have it show up in Adobe, as read only. Imagine that.

In Adobe, we can display the name of this field in a more human readable waywith the label=label="Sul Text"  is the display name that I'll see in the custom panel fromwithin Photoshop. In Venture this is the equivalent of the local.js variable.

In fact, Venture will automatically transfer the 'label' from the Adobe panelinto the 'local.js' file when we load this custom info panel. Oh, wait...you have to actually select the button that you want to 'automatically' createand use the local.js file.

The last bit of this line is the type=. In my example it's a text field.We can just as easily create a boolean field, an integer or a multi valuepull-down field. Date fields can be tricky because of the differences in thedisplay of the date year range between Adobe and Venture.

Think about the ramifications here...This little bit of understanding can make a huge impact on you workflowand become a big time saver. Adding metadata in CS Suite that you can see inVenture. Add instructions in Venture and read them in Photoshop! You can writeinto the XMP space of the file from either program.

"Eh, it's in there"

-Sully

 

1 Comments Click here to read/write comments

Staying Current on Support

Posted by Robert Sullivan on Tue, Oct 13, 2009 @ 10:28 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

I ride dirt bikes and recently incurred a 700 dollar repair bill on my sons bike.
What? What was the cause of this? It's a two stroke motocross and the engine had
seized up, which is not all that unusual, but we had done a new top-end not all that
long ago. So why had it blown again so early?

The 'real mechanic' I brought it to explained that pump gas has changed drastically
from what the engine was designed to run on. But the bike is only four years old..!
Pump gas these days is going Greener with at lease 10% ethanol or more, and is so
oxygenated that it burns hotter, expanding the rings tighter around the piston...
you get the idea. Ring-ding-a-ding, goes to bwop-bwooooop... silence.

As back yard mechanics working on dirt bike engines we hadn't done anything wrong with
our top-end. The gas we run had changed and we didn't ever realize the consequences.

I had an issue last week that drove home the importance of staying current
with system wide support. My customer was having difficulty with XMP metadata
that was not showing up in Venture. This was for XMP fields that were working
correctly not that long ago. Venture syncs were also not showing the field values
either. The first instinctive question is "what changed?" And the answer is
"we're not doing anything differently." Like me with my dirt bike.

Xinet engineering had me activate fpod vlog per a specific tech note which will
create a special output file. Copy on a questionable file again and watch for it to
show up in the log. Verify that the XMP data is not showing in the browser and then
run the syncxmp command in debug mode to capture what the sync is actually doing,
or having issues with. Verify if the data still doesn't show up and send the logs and
sample file in to them for analysis.
They came back with a new syncxmp binary file to slip in, and this was the resolution
to the problem.

I inquired with Xinet engineering about the 'why' and 'how' questions having to do with
the metadata not showing up in Venture. Xinet replied that from their perspective,
the issue had to do with a non-compatible file: specifically,  the jpeg image that I
had sent, which caused syncxmp to fail with these errors:

syncxmp(87535) malloc: *** error for object 0x512060: Non-aligned pointer being freed (2)
syncxmp(87535) malloc: *** error for object 0x512390: double free

Now this error is gobbly-gouk to me. I would have thought a pointer being freed was
a good thing, but I'm not a code writing engineer for several reasons, which is why I
have a very defined escalation path.

The way they "fixed" this was to test my sample file against a newer build of syncxmp,
from the new Suite 16 code, which incorporates some newer XMP libraries provided by Adobe.
In short, the newer Adobe libraries resolved the issue.

So as far as my customer was concerned, they were "not doing anything differently"
But apparently Adobe was. The problem came from the fact that Adobe doesn't stand
still. Ever! They continue to evolve and improve their XMP libraries and those
changes were not recognized by the Xinet version my customer was running.
This is the intrinsic value of having support. We were able to update to a newer
binary to stay current with the ever changing world.

So even though you may not be doing anything different... Change Happens!
My dirt bike solution is to run race gas. The world keeps changing around us without our
consent or input and will not wait for us to adapt or catch up. The leading edge is really
not all that far ahead. But by falling behind, the distance becomes huge and costly.
So stay current with good support.
And if you ride dirt bikes, check your gas.

-Sully

1 Comments Click here to read/write comments

All Posts