P: Revert Slideshow Module to previous method of generating previews

[Tim C Bailey]

This concerns the slideshow module in Lightroom Classic. Previously, when new folders were added to my catalogue, and I wished to view them as a slideshow, for the first time there was a delay while the slideshow previews were prepared, but for any subsequent viewings, the delay was minimal.

Following the latest version of LrC a few days ago, every time I wish to view a folder, there is a lengthy preparation time. The only way to avoid this is to use fn F to view a manual slideshow using the arrow key to move forward. I want to let the show progress automatically with a standard display time.

Your Help Team have told me that this is now standard in the latest version of LrC. This really is not acceptable in a supposedly professional application, and a very backward move. I use LrC daily, and need to view my photos frequently. I cannot wait 2 minutes or more before each folder starts to play. Please address this issue as soon as possible.

[Lhotka]

Ok, it's been several months with no fix, and no comment on this very basic regression/bug.  So any suggestions on alternative slideshow software?  The app I'm evaluating to replace LR doesn't have a slideshow module, so I'll need something else for that.

[Lackner_t]

@Rikk Hi Rikk, did you already get some response from the developers?

[Rikk Flohr: Photography]

I pinged them again and they responded with more information. 

The current behavior is as designed. The preview generation now happens every time, though it should be quick if all previews are already present. A DNG contains a rendered preview that is leveraged in the Slideshow creation.  That is what makes it faster.  

We are looking to add some sort of option for users to be able to control this better in the future

[Lackner_t]

Thank's a lot for your efforts. I hope that it will be changed in future.

[Lhotka]

@Rikk then the design is the bug. 

Forcing people to convert their files to DNG isn't reasonable.   As much as I wish there was an industry-standard RAW file format, there isn't - DNG was never widely adopted outside Adobe (especially by the camera manufacturers).  Preserving the original RAW files is a massive storage hit, and of course, it's not at all relevant for JPEG's or TIFFs as those aren't raw to begin with.

The simple fix here is to revert the code back to the version that uses the same standard and 1:1 previews as the rest of lightroom.  That's the right overall design.

Unless, and I *really* hope it's not the plan to move to DNG previews only across the entire program?  That'd be incredibly user hostile.

[Lhotka]

Found it - FlipFlip.  I have to export all the files out of lightroom as JPG's, which takes about as long as preparing the slideshow.  But at least then, if I play it more than once, the second time is instant.

[Tim C Bailey]

Yet another update for LRC provided today, but nothing changes with the slideshow issue. If I use fn F I can get an immediate full screen image and then use the right arrow to scroll through a slide show manually. Why can't LRC do that without generating any previews, just providing a fixed delay between each image? Come on Adobe - do something now!

[Lhotka]

Well, they fixed the game-ending performance bug so that's progress, but I've given up on the slide show module and just use the external program now.  It's net-faster than waiting for previews every time.

[Lackner_t]

It´s anoying that they don´t fix the problem. What external program are you using?

Thomas

[rome2807]

It seems there are two compounding issues: 1) the fact LRC is no longer caching previews rendered for slide shows and 2) a performance issue specific to rendering TIFFs (and JPEGs based on other user's comments) for slideshows.

To illustrate (2):

- four 26 mpix files (two layer 16-bit TIFFs): 27s for rendering previews

- four 26 mpix files (two layer 16-bit PSDs or PSBs): near instantaneous display

For larger numbers of TIFFs, especially after using LRC for a while, the preview rendering process stalls (beach ball (Mac); not just LR but the entire computer becomes unresponsive; even a forced quit of the LRC process is a challenge under these conditions). So there seems a be a non-linear impact for larger numbers of images to be rendered (task synchronisation, queue management etc. ?).

For reference: iMac 19,1 (8-core i9 3.6 GHz / 64GB / Vega 48 8GB / SSD / Big Sur 12.2.3). LRC 10.2

It looks as if the disproportionately long (dare I say unbearable?) rendering for TIFFs in a slideshow context has not been considered when this design decision was made. Even after (if?) the originally behaviour has been restored, TIFF rendering in slideshows (not Library or Develop modules) is unacceptably slow and need to be fixed too.

[Lhotka]

@Roland Meier I believe that both PSD and PSB have an embedded preview, so that would explain it (it's why DNG's are faster too).  From what I can tell actual image files all have horrible performance.

@Thomas_L I found a program called FlipFlip that works well.  You have to export all the files from lightroom (which takes about as long as rendering one set of previews), but after that, it starts instantly.  The only glitch is that it doesn't handle multiple resolutions all that well, so rendering for your target projector is best.  It's not a substitute for a working slideshow module, but VASTLY more functional than the current iteration.

Given that it took Adobe several months to fix a workflow-breaking performance bug related to custom profiles, I have little hope that this is even in the queue for a fix, let alone this year.  It seems as if all their focus and development staff is on the cloud applications.

Count me as very disappointed in their software design, development and testing teams.  There's major misses all around, and we're not seeing any movement to fix the root causes.

[Lackner_t]

Thank's a lot for the hint. I'll try FlipFip. Another workaround is converting the jpeg files into DNG format. It works but takes time an storage. I really don't understand why a professional SW developer creates such an annoying bug.

[rome2807]

Hi Thomas and Mountaingoat,

thank you for the feedback. I think the theory re embedded previews in PSD/PSB is right.

The reason for me using TIFF is two-fold - many external editors don't support PSD directly. So either Edit (in Photoshop as PSD); invoke editor(plugin); save as PSD or Edit (in external editor as TIFF) and suffer the performance impact. Second, saving large documents in Photoshop as (uncompressed TIFF) is much faster that its native format (PSD, PSB). This shouldn't be the case but suspect PSD/PSB are always compressed - saving compressed TIFFs take equal time.

So using TIFFs used to ensure fast saves and unconstrained interoperability. But they come with unbearable rendering times for larger files, no longer masked through cached previews in the slideshow. For my workflow, I flipped back to PSDs as the 'lesser evil'.