P: Support cataloging PSB files

please insert this function back. i need to verify a lot white background photos on a white thumbnail background

I agree completely. I have needed to revert back to Bridge v8 for custom background selection for all my prepress work for this very reason that interface customization options have decreased, not expanded. 

Bridge CC (v9) does not allow you to view images on pure black or white background (RGB 0, 0, 0 or 255, 255, 255). I work for a large retailer's ecom department and our site, like most websites, are still using white backgrounds. Being able to see our images on white before they go live is the quickest, easiest way to evaluate the consistency of background values in our ecom images. Even if a website is using a different background color, it is highly advantageous to be able to customize the Image Backdrop (as it was called in Bridge v8). I was hoping the interface customization options would expand, not decrease, in the Bridge v9 release. Adobe, please make Bridge more like Photoshop, and allow the user to change the image backdrop so creative professionals can tailor your tools to support our wide variety of creative assignments.

BAD:




BETTER:

The "Transparency Grid" is not the answer to my initial post.

See the attached photo for the missing options in 2019 which are affecting my "surround" color when previewing the images.

It used to be independent of the interface shade options.

Now, in 2019, it is wholly dependent on the interface shading, so that one cannot choose a light interface, and still get a dark gray or a black surround during preview.

Right, and that's frustrating since I keep investing $5000 in hardware ever few years. I'm sitting here with a massive computer that laughs at LR/PS requests. I know it's malicious, but it feels like these apps are 10% efficient....  It's been a while, but I do remember seeing GPU demosaicing research using CUDA. Related, I can pull in 40 NEF files from my D850 to PS and it takes an hour to output a result. PTGUI takes <5 minutes using my GPU.

I think there are more users like you in recent years. I think increasing the pixel limits, however, could be significantly harder engineering than allowing for PSBs, since the performance of the Camera Raw engine is directly proportional to the number of pixels.

NICE writeup man! I'd like to advocate going well beyond those dimensions. I have hundreds of 1000-4000 MP files which I sell as acrylic prints 96"+ wide online as a business. I just semi-completed a recent shot that is 26GB.

As a professional using this professional software, I'd really like Adobe to weigh in here.

To recapitulate past discussions in this topic: The amount of engineering effort for LR to support PSB is modest at most. Supporting PSB in LR is not practically constrained by the SQLite database, nor by the larger file size of typical PSBs, nor by the cost of building previews.

The PSD and PSB formats are nearly identical, the only difference being that PSB uses 64-bit file offsets where PSD uses 32 bits. For my PSB Quick Look plugin, I modified ImageMagick's PSD module to read PSBs and only had to change less than a dozen or so lines.

The SQLite database used for catalogs includes references to files, not the files themselves, so inserting a reference to a PSB has the same cost as to a PSD.

The file size of PSBs can get very large, much larger than the 2 GB limit for PSDs and the 4 GB for TIFFs. In practice, many, if not most, users hit that limit by introducing additional layers, not by having very large pixel dimensions. For example, a single layer of a 50 megapixel 16-bit image takes 300 MB, so a 2 GB PSD allows just 5 layers (plus the compatibility layer).  Some people do hit the file size limit with panoramas, e.g. a 4 x 2 panorama stitched from 50 MP images would be about 400 MP, and a single 16-bit layer would take 2.4 GB.

The cost of building LR previews for PSD/PSBs is proportional to the pixel dimensions, not the number of layers. LR reads the single hidden compatibility layer of PSDs, which is the flattened composite of all the layers. Thus, the cost of building previews for PSBs is the same as for PSDs of the same pixel dimensions. For example, building a preview of a 20 GB PSB that's 330 MP / 16-bit / 10 layers would take the same amount of time and uses the same amount of storage as a preview of 2 GB PSD that's 330 MP / 16-bit / 1 layer.

LR already imposes maximum size limits on all photo types, 65,000 pixels on a side and no more than 512 megapixels, and it could easily impose those same limits on PSBs.  512 megapixels is an order of magnitude larger than the output from nearly all professional cameras, allowing most users a comfortable margin for building panoramas.

Sean, you are correct that LR references the image file, but it does host the previews and when generating previews from files the size Carson is using, the underlying DB simply cannot handle the preview file size.

You can see this issue "live" when LR is building previews from large image files (85MB)—the free space in the drive where the preview cache is stored drops dramatically in real time, especially if the preview building has 1,000 or more images.  We're talking 100GB plus.

I can't imagine what happens when the image files is 2-4GB—20 to 40 times the size of a raw file from a 50MP camera.

Absolutely agree.  At the very least, creating a Smart Preview would allow us to actually 'see' our PSB files in our databases.  Perhaps right-clicking the thumbnail would then allow users to edit the original referenced PSB file in Photoshop and update the  Smart Preview in Lightroom.