Lightroom: Support cataloging PNG files in Lightroom

I think there is a *lot* of interest in loading PNG into Lightroom. I think people don't salute the flag you've raised here because:

* They aren't comfortable with plugins and/or
* They don't understand what you are offering, or
* They didn't read your post(s)...

I think you should do it, Jim! :-)

If there is a straightforward way to handle pngs in a Lightroom plugin, some of us would love to use it. There is an "any file" plugin for Lightroom which I was excited by, because it should allow one to catalog the _images_ that one has, and not just the _photos_. Unfortunately (due to the limitations of Lightroom, not the plug-in author's ingenuity), it required creating little jpg files all across my disk, and I found that so annoying that I abandoned it.

If you can create something usable, some of us would purchase it, and collectively we might send you enough money for you and your significant other to have a nice night out!

There's already a plug-in called AnyFile that adds any type of file to a catalogue.

That might be enough, it depends on your needs. If you just want to catalogue things, that's fine, but if you don't want to store a JPEG copy of each image or if you want to use them in the Develop module, something more is needed. Mine translates images on the fly at the filesystem level, so LR believes it's reading a TIFF.

Anyway, if cataloging is enough then that's grand, problem solved :)

|> Mine translates images on the fly at the filesystem level, so LR believes it's reading a TIFF.

Wow - that's pretty amazing - I'd like to know how you accomplish that - sounds like a perfect solution for PNG too.

I don't *think* Adobe is planning to support PNG in Lr4 - based on various comments here and there plus gut feeling...

"I am putting together some web pages in LR's web module. When importing sources in PSD format, 1 layer with transparency, LR treats the transparent edge as opaque - it makes it white"

I think all LR imports from the PSD is the flattened rendered image the PS generated when you have "maximize compatibility" on. So isn't this a PS issue?

Part of the reason that it's good to have two products from one company working together is to avoid the "it's the other guy's fault" finger pointing. I really don't see why LR can't read the layer that's in the PSD, but if Photoshop needs to change the flattened image to something else, that's fine with me. I would just like to be able to get to the end result somehow, and right now PNG doesn't work, PSD doesn't work...

"I really don't see why LR can't read the layer that's in the PSD..."

Because Lightroom would have to contain the entire rendering engine from PS, which is huge because of all the things Layers can contain and do.

There has got to be some way to compromise to get transparency - nothing else, no layer effects or smart objects or anything else. Pixels with transparency not white background. So layers would have to be merged and/or rasterized for this to work. Or change PS's notion of a flattened image to allow for a second type of flat - a single layer not merged with the background.

If you're dealing with transparent graphics, that's a job for Dreamweaver, not Lightroom which is a streamlined design for photographs.

You might want to learn more about TIFF and the PNG formats. Most of what you just claimed is wrong.

a) TIFF is more exensible than PNG, by far
b) TIFF is unencumbered as far as anyone knows
c) Last I checked, PNG wasn't standardized anymore than TIFF
d) TIFF supports that and a lot more, in a more optimal and flexible way

All PNG has going for it is simplicity because it is not as extensible.

a) If by extensible you mean "add an extension of your choosing" -- then yes I guess they're the same. But if you ever hope to have your extension included in the standard, then good luck! The TIFF standard hasn't been updated since 1992. In fact, if you go read the standard (p.9), it says that you can get information about TIFF extensions by checking CompuServe!

b) Wrong - TIFF most commonly utilizes LZW compression which was patented until 2003 when the patent expired. Unisys was suing people left and right back in the day (mainly for implementing GIF) which thus spawned PNG as an alternative unencumbered format.

c) PNG is ISO/IEC standard 15948:2004, also IETF RFC 2083.

There is no ISO/ANSI/IETF standard for what we commonly use as TIFF in image manipulation programs. There are some standards for atypical TIFF files (ex: FAX images), but I assume that's not what your average person means when they think of a TIFF. Also, Adobe holds the copyright to the TIFF standard and has not updated the standard since 1992.

The result is lots of oddball extensions and incompatibility between applications since these extensions are not documented really anywhere! They're certainly not being championed by the maintainers of the format. To give some perspective, TIFF baseline supporting applications, for example, are not even required to understand the most common compression used in TIFF images! That's why TIFF quickly got the nickname "Thousands of Incompatible File Formats."

d) Please point to the spot in the (latest) TIFF 6.0 specification where it includes those things. Since Adobe is the registrar of extensions, where is its list of common extensions and what they mean? Where is the documentation on, for example, how to include an ICC color profile? For PNG it's simple, just go to libpng.org. Limited metadata is built-in, Alpha is built in, ICC color spaces are built-in, 16bpp color is built in.

-----------

That said, it's really irrelevant; these days your average Joe doesn't care about lossless compression, and for those that do TIFF has become the defacto standard. Big name apps generally support most of the TIFF quirks. In Adobe's absence of leadership, the libtiff community and others have stepped in and done the legwork of figuring out and documenting what exactly a common TIFF is (i.e. which extensions are common and what they mean), and 3rd party software now just uses that. Ultimately that makes TIFF "more or less" work, and the graphics community continues using it because that's what they've always done.

It's a shame, too, because PNG is a much better format on so many levels (see above) and it's actively maintained by a community that actually cares about it. We are seeing PNG come up in the web world though (browsers, Android -- heck even the IP phone on my desk supports PNG); so maybe this story isn't over yet.

In my case I had thousands of negatives/slides to scan; I look towards PNG not TIFF - because I know that my PNG will be read correctly everywhere that supports the format. The TIFF will be larger and probably work when I open it in some app down the road, but is that the level of compatibility I should aspire to when archiving old photographs?

You really, really should learn more about a topic before trying to argue it.

a) Incorrect. TIFF has been updated through tech notes 3 times (I know, because I wrote one of them). And people are actively requesting, receiving, and using custom tags.

b) Incorrect. When TIFF was created, that patent was not known. And that patent expired several years ago. It was unencumbered when created, and is now as far as anyone can tell.

c) Sort of correct, but off base. TIFF itself is not an ISO standard, but is a basis for many ISO standards. Again, TIFF has been updated, even if the master document has not.
And there really isn't that much incompatibility. The worst I know of are some video apps that don't understand transparency versus arbitrary alpha channels.

d) Incorrect. TIFF 6.0 included all you claimed except ICC profiles - they didn't exist at the time it was written. The technotes cover JPEG compression, ICC profiles, extensions for LAB, floating point, and predictors for floating point (which PNG does not have). The BIGTIFF extension isn't an official technote yet, waiting on more implementations to test against.

Um, not paying attention to LibTIFF are you? I've been working with them to extend TIFF for about 12 years now.

PNG is simple. It has that going for it. It doesn't support many color modes, or bit depths, or compression schemes, or metadata standards, or multi-page extensions, or pyramidal (not interlaced) storage, or exabyte sized files, etc.

TIFF does support a lot more, which can make it more complex. But TIFF is still more widely supported, and can do a lot more than PNG.

Oh, and archivists prefer TIFF.

Chris Cox may want to follow his own advice.

For example, how good is TIFF at supporting 64 bit color depths? (Oh, not at all). And the _published_ version of TIFF would appear to be limited to 32 bit file sizes, so it doesn't (contrary to Chris' claim) support "exabyte sized files", etc.

But he also totally fails to see the point: the issue is not "one file format to rule them all", but one of "what's the best file format for my particular set of priorities". And until everyone's smartphones and tablets and out-of-the-box computers natively support displaying all TIFF files, and LibTIFF (or whatever Chris likes) is used universally, it is a suboptimal choice for many purposes.

[ Note: "suboptimal" doesn't mean "unusable". ]

Or is it a png emulating a tiff?