23 Replies Latest reply on Sep 2, 2012 2:50 PM by areohbee

    Exclusive use of a postProcessRenderedPhotos()?

    wepurol

      Hello

       

      I have a specific postProcessRenderedPhotos() on an export filter which only makes sense for a specific export service.

       

      Is it possible to have a uniquely tied export filter for an export service? It is possible to hide the export filter in the “Post-Process Actions:” list from the user or is it possible to make sure the required export filter is always enabled?

       

      Thanks

      Daniel

        • 1. Re: Exclusive use of a postProcessRenderedPhotos()?
          DawMatt Level 3

          Hi,

           

          I've just double checked the SDK Guide. I don't believe there is a way to do this.

           

          There is a way for a post process action to require another one, and I was hoping there may have been an ability to tie it to an export or publish service as well. No such luck.

           

          To work around this I'd suggest you try the following:

          - Have some identifier available in your plugin (specific key in the passed property table? or something similar) that allows the post process action to know when it is being run within the correct context

           

          - when not being run by the correct plugin, act as a pass through (effectively do nothing)

           

          - use an overlapping UI for the post process action. When run in the correct export service show the normal UI. When being run for any other export service show a UI that educates them about this and lets them know the post process action will not change the output. Would also suggest updating the synopsis for the section so this message gets through even when the section is minimised.

           

          Matt

          1 person found this helpful
          • 2. Re: Exclusive use of a postProcessRenderedPhotos()?
            wepurol Level 1

            I hoped to find something like a ‘requiresFilter’ for a LrExportServiceProvider but had no luck.

             

            Thanks for your described workaround. The property ‘LR_exportFiltersFromThisPlugin’ might be useful to detect if an export filter was chosen by the user. I have not yet tested this as another post in the forum here mentions problems with this property for earlier versions of the SDK.

             

            Daniel

            1 person found this helpful
            • 3. Re: Exclusive use of a postProcessRenderedPhotos()?
              wepurol Level 1

              The idea to detect if a specific export filter is set with LrExportServiceProvider seems to work for me:

               

              local exportParams = exportContext.propertyTable

               

              if exportParams.LR_exportFiltersFromThisPlugin.myExportFilterId ~= nil then

                   myLogger:tracef( "ENABLED!" )

              else

                   myLogger:tracef( "DISABLED!" )

              end

               

               

              With the property table from my export service I can check in the export filter if the filter runs in the context of my export service:

               

              local exportParams = exportContext.propertyTable

               

              if exportParams.myPropertyInMyExportService ~= nil then

                      myLogger:tracef( "RUNS IN MY EXPORT SERVICE!" )

              else

                      myLogger:tracef( "NOPE!" )

              end   

               

              Is there a way to pre-enable a specific export filter that it is enabled by default and the user does not have to enable it himself on the export dialog?

              1 person found this helpful
              • 4. Re: Exclusive use of a postProcessRenderedPhotos()?
                areohbee Level 5

                Sorry if I missed some critical point, but why not just build the functionality into the plugin that it applies to, instead of having it be an export filter?

                • 5. Re: Exclusive use of a postProcessRenderedPhotos()?
                  DawMatt Level 3

                  If the functionality can be embedded in the export service it would be

                  simpler. I hadn't asked that specific question. Some functionality (e.g.

                  filtering out images from the rendering pipeline) can only be done as a

                  post process action so I assumed this was just one of those cases. I might

                  be wrong.

                   

                  Thanks,

                  Matt

                  • 6. Re: Exclusive use of a postProcessRenderedPhotos()?
                    areohbee Level 5

                    Matt Dawson wrote:

                     

                    Some functionality (e.g. filtering out images from the rendering pipeline) can only be done as a

                    post process action...

                     

                    I'm not aware of any such functionality (filtering out images from the rendering pipeline may have been a bad example, since it certainly can be done from export service proper).

                    • 7. Re: Exclusive use of a postProcessRenderedPhotos()?
                      wepurol Level 1

                      I agree on Matts reason to have such a task done by an export filter if possible. There is a lot of well-engineered functionality (f.e. filename handling) that can be re-used if we stick to the export dialog. In my opinion user experience is better when using native Lightroom dialogs as much as possible. And finally I hope to have less support in the future when Lightroom changes and might break custom plugin implementations.

                      • 8. Re: Exclusive use of a postProcessRenderedPhotos()?
                        areohbee Level 5

                        So you are writing a custom plugin implementing an export filter that can only be used with somebody else's export service?

                         

                        (I thought you were writing the export service plugin too)

                         

                        FWIW, I wasn't suggesting having UI anywhere else but native Lightroom dialogs (export dialog and/or publish service settings dialog).

                         

                        Rob

                        • 9. Re: Exclusive use of a postProcessRenderedPhotos()?
                          wepurol Level 1

                          I intend to write both, the export service and export filter, combined in one plugin. Lets see how far I can get... I dont want to start a new plugin with a bunch of workarounds :-)

                          • 10. Re: Exclusive use of a postProcessRenderedPhotos()?
                            areohbee Level 5

                            I dunno whether it's you or me who's missing a critical point here, but one of us definitely is - maybe both .

                             

                            If you are writing the export service plugin, I can think of *NO* good reason not to implement *ALL* functionality as part of the export service proper.

                             

                            The *WHOLE* point of an export filter, is to provide export functionality to *OTHER* plugins (or native Lr export services) - right???

                             

                            Using an export filter, will make it *MORE* complicated for your users, *LESS* familiar (most people don't use export filters), require them to *ADD* the export filter before they can *SEE* the options...

                             

                            eh?

                             

                            Rob

                            • 11. Re: Exclusive use of a postProcessRenderedPhotos()?
                              wepurol Level 1

                              Is it correct that postProcessRenderedPhotos() is always part of LrFilterContext (post-process actions steps) and cannot be defnined / called directly from a export service so the user does not see this in the post-process actions steps?

                               

                              As far as is know when doing all work in the export service I can only hookup in processRenderedPhotos() of LrExportContext which is, at least this is what I think at the moment, is too late for the task that I want to achieve.

                               

                              I don't like that export filter thing either, but so far I havent found any better solution. Do you have an idea for a better solution? I can see 'PreviewExporterLrPlugin' is based on a export filter as well.

                               

                              Thanks, Daniel

                              • 12. Re: Exclusive use of a postProcessRenderedPhotos()?
                                areohbee Level 5

                                |> "Is it correct that postProcessRenderedPhotos() is always part of LrFilterContext (post-process actions steps) and cannot be defnined / called directly from a export service so the user does not see this in the post-process actions steps?"

                                 

                                User will always see active post-process actions - no way around that, that I know of. And user always has to add them explicitly/manually, although you can include presets that have them already added for the user to use.

                                 

                                 

                                |> "As far as is know when doing all work in the export service I can only hookup in processRenderedPhotos() of LrExportContext which is, at least this is what I think at the moment, is too late for the task that I want to achieve."

                                 

                                When processRenderedPhotos is called, nothing has happened yet, except Lightroom has created the LrExportContext, and LrExportSession objects. It's not too late for anything. You can do whatever you want...

                                 

                                 

                                 

                                |> "I don't like that export filter thing either, but so far I havent found any better solution. Do you have an idea for a better solution?"

                                 

                                In general, just do what you gotta do - do whatever you would do as an export filter as part of the export service. Without knowing more about the details it's hard to say more...

                                 

                                 

                                 

                                |> "I can see 'PreviewExporterLrPlugin' is based on a export filter as well."

                                 

                                PreviewExporter's export filter inserts an extracted preview in place of what would otherwise be a Lightroom rendering - it can be used with *any* export service.

                                 

                                 

                                 

                                Reminder: Matt Dawson had mentioned that there may be some capabilities in export filter not havable in export service - I'm not aware of any.

                                 

                                 

                                 

                                Cheers,

                                Rob.

                                • 13. Re: Exclusive use of a postProcessRenderedPhotos()?
                                  wepurol Level 1

                                  User will always see active post-process actions - no way around that, that I know of. And user always has to add them explicitly/manually, although you can include presets that have them already added for the user to use.

                                  Thanks for confirming this and the hint with the preset to at least pre-enable the export filter for the user.

                                  When processRenderedPhotos is called, nothing has happened yet, except Lightroom has created the LrExportContext, and LrExportSession objects. It's not too late for anything. You can do whatever you want...

                                  I see - guess it is me which is missing the critical point here I was the opinion, the rendered photos are already on the disk in this stage.

                                   

                                  I think we collected quite a bunch of information regarding the topic. Although there does not seem to be a perfect solution, the question is answered for me. Thanks!

                                  • 14. Re: Exclusive use of a postProcessRenderedPhotos()?
                                    areohbee Level 5

                                    wepurol wrote:

                                    When processRenderedPhotos is called, nothing has happened yet, except Lightroom has created the LrExportContext, and LrExportSession objects. It's not too late for anything. You can do whatever you want...

                                    I see - guess it is me which is missing the critical point here I was the opinion, the rendered photos are already on the disk in this stage.

                                     

                                    A reasonable thing to think, given the name of the function (...Rendered - past tense).

                                     

                                    But, the rendering has not even started - it get's started when you start it, either explicitly via startRendering method, or implicitly via renditions iterator. And, Lr rendering is *always* done in a separate thread, even though it sounds like you may be able to do it synchronously - that's another confusing thing you may run into, if you haven't already .

                                     

                                    rendition:waitForRender() is where you wait for the aforementioned asynchronous task to finish the next rendition.

                                     

                                    Before the rendering is started you can do what you want, e.g.

                                    * Never start it, instead do your own thing, then create your own export session from your own thing, (maybe borrow some of the original export parameters...) and start that instead, so export filters can be honored, and it looks like a regular export, except it's not even the same export that was originally started... - sky's the limit! ...

                                     

                                    You can do exports initiated from menu commands, or have exports which don't do any exporting..........

                                     

                                     

                                    wepurol wrote:

                                     

                                    Although there does not seem to be a perfect solution...

                                     

                                    There may very well be a perfect solution, but you just haven't thought of it yet .

                                     

                                     

                                     

                                    wepurol wrote:

                                     

                                    ...the question is answered for me. Thanks!

                                     

                                    The question is answered when I say it is - TOTALLY joking . You're welcome...

                                     

                                     

                                    Have fun,

                                    Rob

                                    • 15. Re: Exclusive use of a postProcessRenderedPhotos()?
                                      DawMatt Level 3

                                      Rob Cole wrote:

                                       

                                      wepurol wrote:

                                      When processRenderedPhotos is called, nothing has happened yet, except Lightroom has created the LrExportContext, and LrExportSession objects. It's not too late for anything. You can do whatever you want...

                                      I see - guess it is me which is missing the critical point here I was the opinion, the rendered photos are already on the disk in this stage.

                                       

                                      A reasonable thing to think, given the name of the function (...Rendered - past tense).

                                       

                                      But, the rendering has not even started - it get's started when you start it, either explicitly via startRendering method, or implicitly via renditions iterator.

                                       

                                      Rob, are you 100% certain this is true in all cases?

                                       

                                      The shouldRenderPhoto post process action is designed for pulling photos out of the queue so they won't be processed/rendered. The way post process actions are fired ensures this will happen before the processRenderedPhotos function does its thing.  As you mention in one of the posts using the shouldRender to influence this can be a bit tricky.

                                       

                                      My concern about the approach listed above is it might not prove true on all systems (could be a timing issue influenced by number of cores etc), and might not prove true for all exports. Particularly if post process actions are added to the export by the user as these are supposed to fire ahead of the processRenderedPhoto method and could kick off the rendering before you wanted it to. You might not have as much control as you think you do.

                                       

                                      All I can suggest is that you test this out, including an export with a variety of post process actions included, to confirm that this behaves as expected. I'd also suggest you test on both Mac and Windows as there are quirks in how some Lightroom operations run across platforms. You are effectively relying upon how we believe Lightroom is working internally, rather than the documented SDK behaviour, so it is worth double checking in the contexts where you are planning to rely upon the behaviour.

                                       

                                      Matt

                                      • 16. Re: Exclusive use of a postProcessRenderedPhotos()?
                                        areohbee Level 5

                                        Matt Dawson wrote:

                                         

                                        I might be wrong.

                                         

                                        The only example you've given so far is definitely wrong.

                                         

                                         

                                        Fact:

                                        -------

                                        * In export service's processRenderedPhotos function, exportSession:removePhoto( photo ) can be called at any time before startRendering or renditions iterator has been called, regardless of which export filters are  in the chain.

                                         

                                        Why?

                                        * Because export context's startRendering or renditions iterator is what starts rendering, not any methods of filter context.

                                         

                                         

                                        Fact:

                                        ------

                                        * configureProgress can be called at any time before export service's startRendering or renditions iterator has been called.

                                         

                                        Why?

                                        * Because export context's startRendering or renditions iterator is what starts rendering, not any methods of filter context.

                                         

                                         

                                        Note: You can tell when the rendering task has started, because it *always* displays a progress indicator when it's rendering.

                                         

                                         

                                        Lightroom won't start rendering before export service says to, regardless of how many cores you have, or which operating system...

                                         

                                         

                                        @wepurol - Do whatever you want: If you want to make it an export filter, then make it an export filter. Just realize you may be doing it based on a misunderstanding... I do however encourage you to reconsider whether Matt's previous response is considered "Correct", since I consider it "Incorrect". It ain't no thang to me, but it may mislead other readers.

                                         

                                         

                                        While it's true that the export filter's shouldRenderPhotos functions are called before the export service's processRenderedPhotos function, I still content that if you are writing the export service, then there is only cons and no pros to using an export filter, with one exception:

                                         

                                        If you will be making the rule for the user that your export filter must be in a certain position within the chain if more than one export filter is being used. But I presume you are not making such a rule - are you?

                                         

                                         

                                        My motto: Implement in export service if possible, export filter if necessary. Are you 100% certain it is necessary for it to be an export filter?

                                         

                                        Cheers,

                                        Rob

                                        • 17. Re: Exclusive use of a postProcessRenderedPhotos()?
                                          areohbee Level 5

                                          Matt Dawson wrote:

                                           

                                          The shouldRenderPhoto post process action is designed for pulling photos out of the queue so they won't be processed/rendered. The way post process actions are fired ensures this will happen before the processRenderedPhotos function does its thing.

                                           

                                          The shouldRenderPhotos method is designed so export filters can get rid of photos that are to be "filtered". They run before export service's processRenderedPhotos method, but rendering has still not begun when processRenderedPhotos is called - ever, on any system, regardless of cores, or OS, or timing... Not only is this not contradicted in the documentation it is implied by the documentation, and confirmed by experience.

                                           

                                          processRenderedPhotos "thing"s:

                                          1. Optional: iterate photosToExport() before rendering has begun, to review what's to be rendered, as "filtered" by export filters, and further "filter" by way of removePhotos method, if desired...

                                          2. Start rendering, and wait for renditions to be passed from lr rendering engine, to export service, through whatever export filters are in the chain. Note: sourceRendition:skipRender does not remove the rendition from the pipeline, it merely skips rendering of the upstream filter, or Lr rendering engine if no upstream filter, and records the fact in the corresponding rendition.

                                           

                                           

                                           

                                          Matt Dawson wrote:

                                           

                                          As you mention in one of the posts using the shouldRender (correction by RDC: skipRender) to influence this can be a bit tricky.

                                           

                                          This was the trickiness:

                                           

                                          * You can't skip rendering of a photo that has already started (or finished) rendering, until then: you can.

                                           

                                          In preview-exporter, I wanted to skip the rendering of *all* photos, via export filter.

                                           

                                          The original coding (which proved problematic), would wait for a rendering if preview unavailable. The problem then is that I may not be able to skip the rendering of other renditions after waiting for one. The solution was not to wait for any - instead, if preview unavailable, spin another independent export task to render it. This way, all source renditions are skipped, and if photo needed to be rendered, it is rendered independently under preview-exporter control, and passed forward in the chain as rendition to satisfy. Note: it is the source-rendition that's being skipped, *not* the rendition-to-satisfy, so downstream export filters or export service won't see a skipped rendition.

                                           

                                           

                                           

                                           

                                          Matt Dawson wrote:

                                           

                                          My concern about the approach listed above is it might not prove true on all systems (could be a timing issue influenced by number of cores etc), and might not prove true for all exports. Particularly if post process actions are added to the export by the user as these are supposed to fire ahead of the processRenderedPhoto method and could kick off the rendering before you wanted it to.

                                           

                                          It sounds to me like you don't really understand the whole export service / filter thing very well. I think the problems you are concerned about will never be realized. Export filters can not kick off rendering, and Lightroom won't initiate rendering prematurely (without explicit or implicit initiation by export service). Of course, all things are subject to change, but that's how it is now.

                                           

                                           

                                           

                                          Matt Dawson wrote:

                                           

                                          You might not have as much control as you think you do.

                                           

                                          Obviously, you have to work within the constraints of the existing design/implementation, but within those constraints there is some latitude. Having bumped up against such constraints numerous times in dozens of export services and several export filter implementations, I have a pretty good feel for how it all works.

                                           

                                           

                                           

                                          Rob

                                          • 18. Re: Exclusive use of a postProcessRenderedPhotos()?
                                            DawMatt Level 3

                                            Hi Rob,

                                             

                                            Thanks for taking the time to research the issue and provide a well

                                            documented answer to the concerns raised.

                                             

                                            This appears to be one of those situations where you can end up with

                                            different conclusions depending upon which part of the documentation you

                                            read first. The Export Service portion of the API reference and the SDK

                                            Guide don't spell out that information found in the export session and

                                            export context portions of the API Reference. It does seem much clearer

                                            when you dive down to that layer of the doco.

                                             

                                            Thanks for pointing this out. Given this doco I can't think of any

                                            situation where you would need to implement a Post Process Action rather

                                            than embed the functionality in an Export Service.

                                             

                                            I'll also nudge someone to see if this part of the doco can be updated to

                                            be more consistent. Having these concrete examples of inconsistencies makes

                                            this much more likely to happen.

                                             

                                            Thanks, Matt

                                            (Apologies for the brevity - sent from my Android)

                                            • 19. Re: Exclusive use of a postProcessRenderedPhotos()?
                                              areohbee Level 5

                                              Hi Matt,

                                               

                                              I have no idea what wepurol is up to. But at one extreme end of the spectrum of possibilities, this is possible:

                                               

                                              * Remove all photos from export session.

                                              * Build a new export session, which includes rearranged export filters, eliminated export filters, added export filters, ...

                                              * Photos in new export session could be different than originally selected by user, or could be dummys...

                                              * Start that export instead, or

                                              * There could be no export done at all, but instead: new photos (or text files, or ... ) are generated from scratch... - from the outside, it can look just like a vanilla-flavored export, even though the export service never starts rendering.

                                               

                                              None of this particular scenario may make any sense in this case - wepurol has been a bit secretive about his idea - it was intended just as a brainstorming thing to get the creative juices flowing...

                                               

                                              Nothing in the above-mentioned scenario is contra-indicated by the design / documentation, in my opinion.

                                               

                                              Rob

                                              • 20. Re: Exclusive use of a postProcessRenderedPhotos()?
                                                wepurol Level 1

                                                Hi Rob,

                                                 

                                                thanks for you additional explanations.

                                                 

                                                Do this mean, when I want to use 'exportRendition:skipRender()' I always have to include at least one export filter, as there is no way to actually skip a rendition in the export services processRenderedPhotos() function?

                                                 

                                                Example which illustrates how skipRender() fails as explained by Rob:

                                                 

                                                -- Start render loop

                                                for _, renditionToSatisfy in exportContext:renditions{ } do

                                                 

                                                    -- Try to skip built-in render, which results in assertion:        

                                                    -- 'AgExportRendition:skip(): must not be called after exportSession has started rendering'

                                                    renditionToSatisfy:skipRender()

                                                 

                                                    -- Wait until photo is rendered

                                                    local success, pathOrMessage = renditionToSatisfy:waitForRender()

                                                   

                                                    local photo = renditionToSatisfy.photo

                                                    local fileName = photo:getFormattedMetadata( 'fileName' )

                                                    myLogger:tracef( "Rendered file %s", fileName)

                                                 

                                                 

                                                end

                                                 

                                                I think filtering / removing with custom rendering loop based on exportSession:photosToExport() is not an option, as there is no way to access rendition details.

                                                 

                                                Consider following example where it is not possible to access "destination path" in the custom render loop:

                                                 

                                                -- Built-In render loop

                                                for _, renditionToSatisfy in exportContext:renditions{ } do

                                                 

                                                    local destinationPath = renditionToSatisfy.destinationPath

                                                    myLogger:tracef( "Rendered file %s", destinationPath)

                                                 

                                                    -- Wait until photo is rendered

                                                    local success, pathOrMessage = renditionToSatisfy:waitForRender()

                                                 

                                                end

                                                 

                                                -- Custom render loop

                                                    for photo in exportSession:photosToExport() do

                                                   

                                                    -- Get desitanation path. How? No access to renditions

                                                    local destinationPath = renditionToSatisfy.destinationPath

                                                    myLogger:tracef( "Rendered file %s", destinationPath)

                                                   

                                                    -- Do external rendering

                                                    -- ...

                                                       

                                                    end

                                                 

                                                By the way, the example above illustrates another problem: Rendering will be limited to one single thread, which is bad.

                                                 

                                                 

                                                Rob Cole wrote:

                                                 

                                                 

                                                * Build a new export session, which includes rearranged export filters, eliminated export filters, added export filters, ...

                                                 

                                                I would assume a new export session would start with the LR built-in rendering again, so I dont see any reason why I should do this for this issue.

                                                 

                                                If above points are true, I think I cannot go with a simple export service only as suggested by Rob in earlier posts of this thread.

                                                • 21. Re: Exclusive use of a postProcessRenderedPhotos()?
                                                  areohbee Level 5

                                                  wepurol wrote:

                                                   

                                                  Hi Rob,

                                                   

                                                  thanks for you additional explanations.

                                                  Hi wepurol - you're welcome.

                                                   

                                                  I have the feeling you're already convinced that an export filter is the way to go. Whether or not that is the case, there is something to be said for persuing any solution that you can see clearly. Note: The more specific the info you can give about what you are trying to accomplish and the issues you are facing, the better I or others will be able to help.

                                                   

                                                   

                                                   

                                                  wepurol wrote:

                                                   

                                                  Do this mean, when I want to use 'exportRendition:skipRender()' I always have to include at least one export filter, as there is no way to actually skip a rendition in the export services processRenderedPhotos() function?

                                                   

                                                  I don't know what the use case would be for skipping a rendition in an export service's processRenderedPhotos function. Better to get it out of the photos-to-export list before entering the renditions wait loop, if at all possible. Reminder: you *can't* skip rendering any photo that has already begun rendering, whether in export filter or export service. - that's the trickiness I was referring to in previous post. Beware of the skip-render function... My experience is that photos are rendered in the order they appear in photos-to-export, but that is not guaranteed by the documentation.

                                                   

                                                   

                                                  wepurol wrote:

                                                   

                                                  I think filtering / removing with custom rendering loop based on exportSession:photosToExport() is not an option, as there is no way to access rendition details.

                                                   

                                                  There is no rendition yet, but all the same information is available in one form or another. Is destinationPath the detail you aren't certain about?

                                                   

                                                   

                                                   

                                                  wepurol wrote:

                                                   

                                                  By the way, the example above illustrates another problem: Rendering will be limited to one single thread, which is bad.

                                                   

                                                  Not sure what you are driving at. There will be one rendering thread per export session (that's true even if you have an export filter, which runs in a separate thread). If you want more rendering threads, create more export sessions...

                                                   

                                                   

                                                   

                                                   

                                                  wepurol wrote:

                                                   

                                                  Hi Rob,

                                                   

                                                  Rob Cole wrote:

                                                   

                                                   

                                                  * Build a new export session, which includes rearranged export filters, eliminated export filters, added export filters, ...

                                                   

                                                  I would assume a new export session would start with the LR built-in rendering again, so I dont see any reason why I should do this for this issue.

                                                  As I said, these ideas were for example/brainstorming purposes. Since I don't really understand what you are trying to accomplish, or what issues you are facing, I can't really comment much further at this time.

                                                   

                                                   

                                                   

                                                  wepurol wrote:

                                                   

                                                  If above points are true, I think I cannot go with a simple export service only as suggested by Rob in earlier posts of this thread.

                                                   

                                                  I *think* you can do it all from an export service, but again: if you can see your way clear to accomplishing it with an export filter, then go for it.

                                                   

                                                   

                                                  I assume you have dumped the property table in the export context to see all the info there. If not, it's a must to do so.

                                                   

                                                   

                                                  Rob

                                                  • 22. Re: Exclusive use of a postProcessRenderedPhotos()?
                                                    wepurol Level 1

                                                    I have the feeling you're already convinced that an export filter is the way to go.

                                                    I'm already convinced to use the export dialog. If possible, I would like to the job with an export service only withouth an additional export filter.

                                                    The more specific the info you can give about what you are trying to accomplish and the issues you are facing, the better I or others will be able to help

                                                    A native application should process the original RAW files and render either a full resolution image or an preview-like image (this is up to the users setting). As the result of this is similar to the result as when Lightroom would render the images, most of the export dialog sections make sense and should be usable by the user.

                                                     

                                                    Is destinationPath the detail you aren't certain about?

                                                    Yes. I would like to re-use Lightrooms file namig logic aswell (including automatic renaming when file is already existing). Not yet sure if i'll need exportRendition.publishedPhotoId.

                                                     

                                                    but all the same information is available in one form or another

                                                    Really? Where can I get exportRendition.destinationPath?

                                                     

                                                    I assume you have dumped the property table in the export context to see all the info there. If not, it's a must to do so.

                                                    Ah... thanks for pointing me in this direction. Just did it. Can still not find a way to get access to the complete destiantion path of every rendition.

                                                    • 23. Re: Exclusive use of a postProcessRenderedPhotos()?
                                                      areohbee Level 5

                                                      wepurol,

                                                       

                                                      Thanks for clarifying. I think you may be right that the most straight-forward solution is to include an export filter.

                                                       

                                                      Indeed, you can't skip-render from the export service's renditions loop, only a filter, and that is the only way I can see to get the destination-path before rendering is initiated, short of a klugy-workaround, which I presume you'd prefer to avoid.

                                                       

                                                      If you want to avoid getting the user involved with the export filter, you can create a new export session using the same export settings, 'cept with the  export filter added to it, and start that export session instead. This approach has the advantage that you can ensure your export filter is first in line regardless of other export filters the user may be having, which is a must to ensure Lr rendering is skipped, and your rendering is not.

                                                       

                                                      This topic has inspired a feature request on the Adobe feedback site, please consider voting for it:

                                                       

                                                      http://feedback.photoshop.com/photoshop_family/topics/lightroom_sdk_a_way_to_get_export_de stination_path_before_rendering

                                                       

                                                      Cheers,

                                                      Rob