Topaz Studio 2 (and others) as plugin to L4

Answered

Comments

11 comments

  • Avatar
    Elena Blum

    Hi Colin,

    Please try reinstalling the Topaz Studio and Nik. Check whether it becomes available to you under Edit > Plugins.

    If the plugins do not appear there, please try the following: 

    1. Download the folder with plugin files here, unzip the folder and save it somewhere where you can easily find it.
    2. In Luminar 3, click Edit > Plugins > Other > Open Plugin > point Luminar to the .plugin file in the folder you just copied in step 1.
    3. Repeat the process with each .plugin file.

    In case the issue remains, please contact us at www.skylum.com/support and we'll be happy to help.

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    Cracked it. What L4 does is create a new layer with the plugin edits baked in. The problem is there is no way of knowing that has happened. As far as the Library is concerned it just shows that I have a raw file (raf in my case) that contains the plugin edits. It does not tell me that the original file (with any Luminar edits) is below it on a separate layer. Re the image that is the layer with the plugin edits - surely that cannot be a raw file can it? It is presumably a tiff or jpeg?

    The layer idea is a good idea, akin to stacking images, but it is not clear what is going on in my view.

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    This is not the complete answer as the confusion is due to the way Luminar saves the plugin edited file. Would be helpful o understand that aspect as per the question raised in previous post.

    0
    Comment actions Permalink
  • Avatar
    Dayo Akanji

    @...

    I don't use L4 but what you describe sounds like how Luminar has always dealt with external plugins for as far back as I can recollect (L2018) and if is indeed still the same, I sincerely hope they never change it as it is, IMO, the one single thing Skylum has gotten right in Luminar.

    In L2018, Flex and L3 (presumably L4), what happens is that when you click to edit in an external plugin, the currently selected layer is exported as a HiRes tiff file in a temporary location on your machine. This temp tiff file is then opened in the external plugin for you to edit. When you are done with these edits, the temp file is overwritten with the new edits and added to your "Luminar file" as a new layer and the temp file is deleted.

    This to me is a rare stroke of genius as it allows for seamless integration with external plugins. I most certainly don't want an intermediate Luminar version file sitting around when I want to use the Nik Collection as part of my Luminar edit flow and I also don't want an intermediate Nik Collection file sitting around either. What I want is exactly what Luminar does ... round trip to the external plugin and give me a layer to continue my edits without spare files sitting around.

    Compare this seamless workflow using various tools from DxO in Luminar 3: https://drive.google.com/file/d/1EoXssDTjh1pK34SyMb8EUqn8-sPE9I2j/view

    With using the same in DxO's own PhotoLab: https://drive.google.com/file/d/1m2xzYcnseuxTAW7O2qcxjYSjqkL5YBVA/view

    (Speed up video as details not important)

    With Luminar, everything is fully integrated and seamless but not quite so with PhotoLab, and I am left with several files to delete at the end.

    In L2018 and Flex, I can save this as an LMNR file with all the layers intact and the big tiff files are packaged together in a neat bundle. If you simply export as a rendered image, everything is flattened and the support files discarded. With the LMNR file, you can go back and delete a layer and the associated tiff file is deleted cleanly.

    With L3 and presumably L4, the HiRes Tiff files are saved in a subfolder of your Luminar catalogue and associated with the original file in the database. If you go back to delete a layer, the associated tiff file is often not deleted and just sits in your catalogue folder as an "orphaned file" just eating space (Up to 140mb each for the Nikon D850). That's the only downside in the implementation but this only came about from dropping the LMNR format.

    I wrote a program to sort these out on L3 as I use these external plugins a lot and often change my mind with them resulting in orphaned files bloating my catalogue.

    It's called PatchUp! AI for Luminar (Still only used personally and not distributed)

    1. About Screen

     

    2. View after selecting "Level 3 Optimisation"

    3. View after evaluating catalogue for "Level 3 Optimisation"

    4. View after running Level 3 Optimisation

    I will get around to releasing it for public consumption at some stage and potentially add L4 support. Will be donationware although no one ever donates to developers of such software.

    Anyway, I hope Skylum keeps their current setup and perhaps run a garbage collector now and then to clear out orphaned files.

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    So when I look at the Library how do I know that an edit has been undertaken via a plugin given that is just shows a raw file and thumbnail? Also if I go into the image and change layers the thumbnail in the Library just reflects the layer I have selected so I could have either image reflected in the Library thumbnail (both which show as raw). Far better the way all other apps handle plugins and where a raw is converted to tiff, sent to the plugin and the plugin returns the edited tiff to sit beside the original raw.  I do not see Luminar's approach as seamless integration. On the face of it Luminar is trying to mimic the workflow in Apple Photos but with Apple Photos you only ever see the latest edited image and you cannot make a previous image the default thumbnail.

    Yes I can see some upside to the process but at the moment it is confusing because you can chose either layer to be the default for creating the Library thumbnail. Needs tweaking so that the thumbnail title reflects the facts.

    0
    Comment actions Permalink
  • Avatar
    Dayo Akanji

    As said, I don't know exactly how L4 works on this but the L2018 up to L3 way is perfect from where I stand (I think L4 is most likely the same).

    As for this: "Far better the way all other apps handle plugins and where a raw is converted to tiff, sent to the plugin and the plugin returns the edited tiff to sit beside the original raw." I am totally against such and hope Skylum does not default to this.

    If I want this, I will export a tiff from Luminar, open in the external tool and save from that. When I click on the plugins export in Luminar, I expect it to work exactly as they have done without random spare files floating about the place. Just round trip to the plugin and give me a layer.

    In the videos I posted, the PhotoLab one works the way you outlined but to me, all I see is that I end up with five files at the end of the process and have to delete three that I never wanted in the first place. I also have to remember to select the right one for the next plugin I want to use.

    I don't get this issue with Luminar's approach.

    0
    Comment actions Permalink
  • Avatar
    Dayo Akanji

    PS. In L3, you should be able to get it work the way you want by using "File -> Open in" but the list is limited to a preset list of tools.

    I presume there is an equivalent in L4 and if they allow users to add to this list, then both approaches would be available.

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    So you are singing the virtues but do not know how L4 works. You do not like what is the industry standard so you are supporting something that does not even show the user whether the file is an edited file by Luminar or one of its plugins. What is the point of this plugin layer anyway - it does not retain the plugins edits so it does not compare to smart objects. The layer is no more than an edited image anyway so why is it so different to a tiff in a stack, or an edited image in a Photos stack? If I recall you are one who wants the return of the project files and I am not onside with that. Much prefer the current way and would also like the option to have sidecar files.

    We are not on the same page Dayo, which is fair enough.  In any event we are where we are and I have asked a simple question re the layers and identifying them via the Library. The workflow does not fully work and needs tweaking so the user knows what is being represented by the Library thumbnail. In addition, the Library  should imo always default to the latest edit in the same way that Photos does.

    Over and out :-)

    0
    Comment actions Permalink
  • Avatar
    Dayo Akanji

    Nothing wrong in artistic differences Colin.

    I don't indeed know how L4 works and stated that from the beginning. I just wanted to state that If it works as L3 did, then I hope Skylum maintains this. Operative word is "If".

    As for something to somehow ID such items in the catalogue, although I have no issues with the L3 approach which I presume is the same in L4, I have no issue with that at all. There you go ... some agreement!

    I can't see how providing project files should bother anyone that would not use it since it wouldn't change the current setup and would just be an export option. All the items needed to create LMNR files are present in L3 and L4 and it only requires a relatively small tweak to the export options to allow this.

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    Nothing wrong with project files so long as they are optional (we agree again). My fear is Skylum's tendency to oversimplify things and take away used choice/preferences.

    0
    Comment actions Permalink
  • Avatar
    Dayo Akanji

    The fear runs deep in everyone that has been on this jolly ride for a few iterations of Luminar!

    I have actually done a proof of concept of this with L3 and will be looking at adding it to my export handler tool at some point.

    Steps involved are to watch a certain folder, harvest some files such as state files, package these and edit some entries to say it is a Flex LMNR file and it works just fine (L3 and L4 open just fine).

    Works for L3 as edit options and thus associated state file entries are the same with Flex and so can be packaged as a "Flex" LMNR file. Not so straightforward and probably impossible to do as such a hack starting with L4 outside of Skylum.

    0
    Comment actions Permalink

Please sign in to leave a comment.