@Rover wrote:
Had a hard time deciding whether this was to be posted as a bug or as a product enhancement.
But since Studio's lack of manipulation of a photo's XMP info can cause some bad side-effects, and since Topaz's future lies around a stand-alone app (Studio), I decided that is can only be held as a BUG, although not a direct code bug in a current version. More something that must be implemented to maintain correct interworkings with other apps. (Here Lightroom)Problem..
So you have an original photo, that at some point in its life was managed only by Lightroom (although maybe edited in Photoshop or others). It could have dust removed, been cropped, other otherwise manipulated in Lightroom/Photoshop.
You now decide to take it out of normal workflow, and make it into "Art".
Take it out of flow by either manually copy or "export original" to a different project location.Theoretically, one might think, you now have a completely independent image-file, and you now run Studio (as a stand-alone app) on it.
You manipulate the artistic representation, crop, fix, total transformation. Not much relation between the original photo, and this new piece of Art. You save your final version. All is well. The image views well in Photoshop, Explorer, and any other viewing you might use.THEN, for whatever reason you include that project directory in Lightroom (Synchronize directory, import). Maybe to take advantage of Lightroom's MUCH, MUCH better export abilities. Such things as quality controls, imposing filesize limitations of file for uploads, ...
Now the problems start.
Because Studio does not manipulate the EXIF/IPTC/XMP information, all embedded XML information moves over to the new image unchanged, the resulting "art work" is still stamped as pure Lightroom. Part of which is the XMP info.
The "xmp:CreatorTool" is still listed as Lightroom, and more importantly, all Lightroom's identifying information (DocumentID, InstanceID, ...) is still there. This makes Lightroom see it as still it's own image, and connects that new image DIRECTLY to all earlier transformations done on the ORIGINAL photo. By IDs.
See example XMP information down below.You will see side-effects such a an art-photo that looks perfect in Photoshop, Explorer, viewers, Studio, magically getting cropped in half when Lightroom applies all it's earlier list of (non-destructive) manipulations on top of a photo that SHOULD BE entirely unrelated. Cropping, dust removal, ..., ... To Lightroom they are all simply a list of manipulations located in it's database, related to a photo-file by it's verifiable IDs. Which when Studio does not fix (or at last clear out) the identifying XMP IDs, suddenly connect a bunch of irrelevant manipulations to this new art-work. The new artistic image gets the same manipulations applied in Lightroom as the original (now unrelated) photo did.
But now on a photo where such things as coordinates for cropping, dust-removals (Lightroom clones from one location to another), and others are decidedly WRONG..Now.. If the manipulations as a clear as when I first saw this issue (an image clearly cropped in half), then you know immediately. But other manipulations are not so clear to recognize by first sight.
If you now export this image using Lightroom (for example to get an upload file of a certain size), then you will be exporting the wrong image! It will NOT look like it did in Studio. Image may be NSFW.
Clik here to view.Haven't tested it, but I am guessing that the old and new images might even be falsely connected now. Such that if you later make Modifications to just one of the images, it will affect BOTH of the images, including your art-work. Because both images from a Lightroom perspective are the same. They have the same IDs.
One COULD of course call Topaz Studio from within Lightroom directly. In that workflow, Lightroom makes first a copy of the original file, and on it's own resets the XMP information (assigns a new Instance ID), BEFORE calling Studio.
Which will automatically disconnect your original file from the new "Art" saved from Studio.The reason for at times NOT doing that, is that it defeats the whole purpose of Studio "Project" files and can create a lot of dummy intermediary files you do not want to see in Lightroom over maybe several days.
Also, If Topaz Studio want to play as a stand-alone app, not 100% as a "call from a host" application, it has to learn to handle (at least) the XMP information stamped in the images on it's own. Making a "mark" of its own as an "Creator" app, instead of leaving the original "Creator"'s marks behind. Image may be NSFW.
Clik here to view.
(Self-confidence man, Self-confidence.. Make your mark. Image may be NSFW.
Clik here to view. )BTW.. I have verified, that if I simply clear out the XMP info in an image created by Topaz Studio before (re-)importing it into Lightroom, then it seems to work out fine. With no identifying marks available Lightroom no longer makes the connection, and assigns a new image ID on the way in.
Example XMP info:
<xmp:CreatorTool>Adobe Photoshop Lightroom Classic 7.0 (Windows)</xmp:CreatorTool> <xmp:ModifyDate>2017-11-23T17:11:42-07:00</xmp:ModifyDate> <xmp:CreateDate>2015-06-29T14:37:07</xmp:CreateDate> <xmp:MetadataDate>2017-11-29T07:01-07:00</xmp:MetadataDate> <aux:SerialNumber>3076283</aux:SerialNumber> <aux:LensInfo>240/10 700/10 28/10 28/10</aux:LensInfo> <aux:Lens>24.0-70.0 mm f/2.8</aux:Lens> <aux:LensID>147</aux:LensID> <aux:ImageNumber>6657</aux:ImageNumber> <aux:ApproximateFocusDistance>501/100</aux:ApproximateFocusDistance> ..... </photoshop:History> <xmpMM:DocumentID>xmp.did:2a4bf7d6-b23e-fd47-af17-319cc48f38fa</xmpMM:DocumentID> <xmpMM:OriginalDocumentID>F00A407A956AFCF69696BB0C28A48088</xmpMM:OriginalDocumentID> <xmpMM:InstanceID>xmp.iid:93d6b3b9-d0c5-794f-ad99-b766f864b3b6</xmpMM:InstanceID> <xmpMM:History> <rdf:Seq> <rdf:li rdf:parseType="Resource"> <stEvt:action>derived</stEvt:action> <stEvt:parameters>converted from image/x-nikon-nef to image/dng, saved to new location</stEvt:parameters> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:2a4bf7d6-b23e-fd47-af17-319cc48f38fa</stEvt:instanceID> <stEvt:when>2017-11-23T15:25:33-07:00</stEvt:when> <stEvt:softwareAgent>Adobe Photoshop Lightroom Classic 7.0 (Windows)</stEvt:softwareAgent> <stEvt:changed>/</stEvt:changed> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:b123b2db-f04e-3c47-a6c5-fed56367694f</stEvt:instanceID> <stEvt:when>2017-11-23T15:25:38-07:00</stEvt:when> <stEvt:softwareAgent>Adobe Photoshop Lightroom Classic 7.0 (Windows)</stEvt:softwareAgent> <stEvt:changed>/metadata</stEvt:changed> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>converted</stEvt:action> <stEvt:parameters>from image/dng to image/tiff</stEvt:parameters> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:4f948573-118b-9745-b837-9a41767bd9a4</stEvt:instanceID> <stEvt:when>2017-11-23T17:11:42-07:00</stEvt:when> <stEvt:softwareAgent>Adobe Photoshop CC (Windows)</stEvt:softwareAgent> <stEvt:changed>/</stEvt:changed> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:ba2c4ede-4dbd-ac43-9f34-5c89604bb5ef</stEvt:instanceID> <stEvt:when>2017-11-28T21:13:47-07:00</stEvt:when> <stEvt:softwareAgent>Adobe Photoshop Lightroom Classic 7.0 (Windows)</stEvt:softwareAgent> <stEvt:changed>/metadata</stEvt:changed> </rdf:li> <rdf:li rdf:parseType="Resource"> <stEvt:action>saved</stEvt:action> <stEvt:instanceID>xmp.iid:93d6b3b9-d0c5-794f-ad99-b766f864b3b6</stEvt:instanceID> <stEvt:when>2017-11-29T07:01-07:00</stEvt:when> <stEvt:softwareAgent>Adobe Photoshop Lightroom Classic 7.0 (Windows)</stEvt:softwareAgent> <stEvt:changed>/metadata</stEvt:changed> </rdf:li> </rdf:Seq> </xmpMM:History> <xmpMM:DerivedFrom rdf:parseType="Resource"> <stRef:instanceID>xmp.iid:b123b2db-f04e-3c47-a6c5-fed56367694f</stRef:instanceID> <stRef:documentID>xmp.did:2a4bf7d6-b23e-fd47-af17-319cc48f38fa</stRef:documentID> <stRef:originalDocumentID>F00A407A956AFCF69696BB0C28A48088</stRef:originalDocumentID> </xmpMM:DerivedFrom>
Posts: 3
Participants: 3