Should I use PNG file format or not

Processing
1

When I take a series of images to stitch together as a panorama I edit the original raw file in DT and then export a 16 bit PNG file. I then stitch the panorama in another program (Microsoft ICE) and export from that program a 16 bit Tiff or PNG file. Finally cropping and editing is then undertaken in DT again.

I find PNG files easy to identify in my workflow as work in progress files but I am wondering if there is a penalty to pay using this file format instead of Tiff. I would appreciate informed advice on this issue if anyone knows why I should or should not use PNG in my intermediary workflow steps. Final output is a 16 bit tiff.

Thanks in advanced. I don’t trust googles AI answers. I like actual intelligence.

2

When I stitch, I just use a 16 bit tiff. I usually have a subfolder for working files that are produced during processing, but not the final output, so I can find things easily.

I never liked PNG for photography, I thought they never compressed as well as jpeg and generally just were not made for photography, but rather for more vector like graphics. This is personal opinion, not fact.

But why not just use tiff for intermediate files, they aren’t permenant and disk space is generally plentiful, especially if the files aren’t long lived.

4 Likes
3

I use TIFF (16 bit unless a tool doesn’t support it) for intermediate files, and I put them in
/tmp so I don’t wind up eating a ton of non-temporary disk space. I’d rather repeat the step creating the TIFFs than build up a bunch of cruft.

1 Like
4

When searching a folder for the images to be stitched PNG is easiest to find. But if PNG compromises my images I will discontinue the practice. Hence my question. It is not about long term disk space. I want a file equal to tiff in quality for stitching. I am not sure if PNG fits that requirement. I don’t wish to use subfolders in my workflow. Thanks for your responses so far.

5

PNG uses lossless compression, so I assume qualitywise it doesn’t matter.

When I tried to figure out if I should use tiff or png many years ago, I read a lot of “PNG is not meant for photos” and some weird “use tiff for compatibility reasons” arguments. But neither make lots of sense to me. PNG is lossless and compressed image size is about the same. So who cares what it was originally meant for.
And regarding compatibility: I never once hat a problem with PNG but I did have compatibility issues with TIFF multiple times (e.g. if using a compression method which is not supported by the print shop).

5 Likes
6

PNG is lossless. There will be no problems. But certain variants of TIFF might result in somewhat smaller files, as the compression is tuned better for photos. And PNGs tend to be a bit slow when compressing, especially if they’re big. But this is probably unimportant for your application. (My Gigapixel files at work can be annoying, though)

Ideally, we’d like to use JPEG-XL for this purpose, in its lossless-compressed 16-bit mode. But support for the format is still scarce, what with Google blocking it in Chrome, to push their own patented tech.

3 Likes
7

Both PNG and TIFF use lossless deflate compression*, so the quality is identical and size should be similar.

The difference might come down to level of support for embedded color profiles and preservation of Exif metadata in various apps.

* TIFF can also be completely uncompressed, lossless LZW compressed (not produced by dt), and also contain many other compression payloads, even lossy ones (also not produced by dt).

1 Like
8

PNGs can get extremely lightweight if you have few colors and do something like, in GIMP, Image → Mode → Indexed, but obviously that’s not interesting for photography, except the “Greyscale” mode to some extent, maybe. It does however save me tons of storage space on my cheap web hosting plan for my stupid ugly comics.

I didn’t know about them ditching support. :slightly_frowning_face: However, an article I read right now seems to say that what they support instead (AVIF) is “royalty-free”, and that the patented format is HEIC, heavily used by Apple. :thinking: (Still not cool, though.)

Out of curiosity, I checked the table from the beginning of man exiv2. It has “Read / Write” in all columns for PNG, but TIFF lacks the “Image Comments” part.

I’m not very knowledgeable on that stuff. :sweat_smile: I thought TIFF was able to retain some color information for clipped pixels the way raw files do, to some extent, but going through this thread shows me that I was probably sorely mistaken. :laughing: I was recently thinking about those formats for another reason: I might one day loop through all my backed up RawTherapee .pp3-s and use them to produce, via the RT CLI, exports of my raws in a to-be-determined format for archival, with a good “printability / used up space” ratio. While RT is pretty good at backward compatibility, some bugs made me realize that relying only on that compatibility on the longer term could lead to bad surprises.

What about appending suffixes (or prepending prefixes, for sorting reasons) to filenames? It makes it easy to find and to clean up. (But I guess that crossed your mind already.)

9

It can (technically out of gamut) if you save in floating point representation. Indeed, TIFF does support that (both 32b float, and 16b “half” float), while PNG does not. The OP question was specifically about 16b unsigned integer.

Clipped is clipped. If it was clipped in raw, there is no going back and nothing to preserve (apart from reconstruction/inpainting/guessing by some clever algorithm or AI).

2 Likes
10

@kmilos Microsoft ICE doesn’t support floating point tiff unfortunately. @alicem I hadn’t thought of using suffixes or prefixes, but maybe PNGs are fine for what I am doing. Again thanks for the helpful replies here.

11

I exhumed this topic from my browsing history to re-read it, and then went through a few quick tests for my personal “long-term archival for potential printing someday because who knows?” reasons.

Using the CLI of RawTherapee 5.12 and 16-bit colors on three fairly different pictures (a colorful one, a dull one with lots of large uniform areas, and a black-and-white one) I observed that:

  • PNGs were faster to produce in all three cases. Generally by a slim margin, but I went from 19 s to 12 s on one case (the dull image). Note that this includes the common time needed by RawTherapee to apply my profile and stuff.
  • PNGs were a little bit smaller (negligible, though, in terms of proportions) for all cases except for the black-and-white picture, which turned out to weight 84.5 MiB in TIFF vs. 116.6 MiB in PNG. Dunno if this is a coincidence. :face_with_monocle:

(RawTherapee apparently hardcoded the PNG compression level to 6 – I guess there’s a reason. :woman_shrugging:)

By the way, WOW, these are indeed huge. Will have to search the web to understand how these exports can be heavier than the raw files themselves. :rofl: This is a bit counter-intuitive. I guess I still have a lot to learn. And I may need yet other external drives…

The worst part is that I really need to squint on those to see the difference with 92-quality JPGs on my screen at 100 % zoom. :sweat_smile: But I suppose large prints are less forgiving than my tired eyes.

2 Likes
12

A raw image has only one channel per pixel, probably only 14 bits. After demosaicing, we have three colour channels per pixel, probably 16 bits per channel. So the quantity of data has more than tripled.

In addition, the raw file may be compressed, with an algorithm designed for compressing photos. PNG algorithms were not designed for photos, but graphics (PNG = Portable Network Graphics).

Some programs such as “pngcrush” will use trial-and-error to compress PNG files even further, but this is typically only a few percent.

4 Likes
13

Yes, you’ll have a hard time seeing differences between jpeg and png on screen, that’s what the jpeg algorithm was designed for. Differences become visible when you want to do further (agressive) edits on the image…

2 Likes
14

Thanks.

By the way, I saw in RT CLI’s help blurb (-h option) (it’s not in the online documentation yet, it seems) that it supports 32-bit colors, but I guess that it’s overkill for nearly all usages, especially non-professionally? (And it must be even more ridiculously large, obviously.)

Regarding PNG and TIFF, I almost considered designing a script to produce both (possibly using ImageMagick’s convert to produce the second format from the first, rather than cranking up the whole RT machinery again) and automatically get rid of the heaviest one on a per-picture basis, but the thought of having an heterogeneous collection for a marginal gain convinced me otherwise. xD

15

Just like HiRes audio, high bit-depth in images is mostly* pointless snakeoil, except for intermediate files that will be processed further.

* The caveat is if you export to a wide gamut space such as P3, where 8-bit might cause banding when displayed. It might also be useful for printing, but I don’t know much about that.

16

JXL would be better than PNG in my opinion.

1 Like
17

By the way, I saw in RT CLI’s help blurb (-h option) (it’s not in the online documentation yet, it seems) that it supports 32-bit colors, but I guess that it’s overkill for nearly all usages, especially non-professionally?

Beware that “32-bit colors” may mean either “4 channels each of 8 bits”, or “some number of channels each of 32 bits” (which probably means floating point numbers of 32 bits per channel).

If you are saving an image that you want to process further, I suggest always using as many bits as you used to edit them. If your editor used a floating-point 32-bit per channel, then save in that format.

But if you want no more edits, and are saving the image to view on the screen or upload to the web, then a lossy 8-bit/channel format such as JPEG will look fine.

(possibly using ImageMagick’s convert …)

ImageMagick convert is deprecated. Instead, use magick.

3 Likes
18

Since I realised that jpg caused a loss of sharpness in fine granular details, I am cautious about saying that jpg is sufficient. It is a lossy compression format.

1 Like
19

Oh, I forgot that JPEG XL supports lossless compression. That could be an interesting way to store stuff indeed. Lossless means that in case of compatibility issues you can still convert a few of them into temporary files for whatever you’re attempting to do at any given moment. That deserves investigation.

No idea which parameters convert used by default, but it accepted to produce a .jxl out-of-the-box without complaining. :laughing: … Or perhaps not. Both file and identify seem to say that it just re-encoded them as slightly better-compressed PNGs, ignoring the extension I gave. :unamused: Let’s sudo apt install libjxl-tools.

Gosh, I tried using the highest “effort” and quality settings (--quality 100 --effort 9 --brotli_effort 11) and it takes ages to perform the conversion. :sweat_smile: Several minutes and still not done. And it does not seem to use more than a CPU at a time… OK, seven minutes, still no picture converted. Aborting. :sweat_smile: Retrying with just the quality settings… Not much better, but at least it ended at some point. I guess that version is a bit old, too.

Read 4293x6332 image, 122258006 bytes, 64.9 MP/s
Encoding [Container | Modular, lossless, effort: 7 | 648-byte Exif | 2378-byte XMP], 
Compressed to 56781351 bytes including container (16.711 bpp).
4293 x 6332, 0.29 MP/s [0.29, 0.29], 1 reps, 12 threads.

It divided the weight of the black-and-white pic by a factor of about two, but was not as miraculous as that for the other samples. And currently I have to run GIMP to view them. :rofl: Not extremely motivating so far, but worth the attempt.

Also, that version of cjxl’s help says nothing about converting from .jxl back into something else. :thinking:

Sidenote: Using identify on my TIFFs yielded a warning, which I did not get for PNGs:

Wrong data type 9 for “ISOSpeedRatings”; tag ignored.

The CLI’s help explicitly has “16f” for floating-point numbers, and says “per channel”, so I think the 32 is for integers:

  -b<8|16|16f|32>  Specify bit depth per channel.
                   8   = 8-bit integer.  Applies to JPEG, PNG and TIFF. Default for JPEG and PNG.
                   16  = 16-bit integer. Applies to TIFF and PNG. Default for TIFF.
                   16f = 16-bit float.   Applies to TIFF.
                   32  = 32-bit float.   Applies to TIFF.

Interestingly, the “default for…” mentions do not always match what the old RawPedia page says. :face_with_monocle:

That makes sense. Not sure what RT uses internally, though.

I’m still using the default version coming from Ubuntu’s repository’s, and it does not yield deprecation warnings yet nor provides the magick executable (at the cost, probably, of having fewer features, but it is OK for the basic stuff that I generally do). But yeah I heard about the warnings from a colleague running MacOS (and I was like “nooooo my scripts will have to be adapted”).

For online publication, I re-run the CLI and use JPG_SUBSAMPLING=2 + JPG_QUALITY=88 with a bounding box of 1750×1750 px and it looks OK-ish (my family never told me “What the hell, this is all blurry and ugly”, and I even set some of those as randomized wallpapers for my parents’ computer :crazy_face:). But for the long term, the thing is that there’s no way to guess what I’ll want to do. :laughing:

Sorry for hijacking this thread, but this is an interesting topic, and my initial question basically matches the thread’s title. :sweat_smile:

1 Like
20

Well, I should check my glasses: it says “float” for 32 in my own quote. :sweat_smile: Weird naming inconsistency?