11
\$\begingroup\$

If I edit an image file using some application like GIMP, Photoshop or MS Paint, while saving I will be asked to select the required file-format. There are different formats available, the common ones are JPEG, PNG and BMP, GIF and TIFF. With some programs, there are even more formats like JP2.

So which option should I select? What are the merits and demerits of using a particular file format?

\$\endgroup\$
3
  • \$\begingroup\$ I hope that my edit does not violate anythig that was said in "Is it gaming the system to edit a question you've also answered?" - If it does, feel free to roll it back. Intention of edit: It is a good question that had a title too specific (IMHO), especially since HEIF and other formats are starting to become widespread. \$\endgroup\$
    – flolilo
    Mar 16, 2019 at 14:52
  • \$\begingroup\$ @flolilolilo I don't think that is a problem here.. I am a little concerned that this will get less organic search traffic and that we will have to do more manual closing of duplicates, but, eh. \$\endgroup\$
    – mattdm
    Mar 16, 2019 at 20:59
  • \$\begingroup\$ @mattdm Sorry, I did not mean to introduce further labour here! I was just thinking that "should I use JPEG, BMP or PNG" left open the door for...well, all other codecs. If it is just me, then there is no need to keep it this way. \$\endgroup\$
    – flolilo
    Mar 16, 2019 at 21:03

4 Answers 4

13
\$\begingroup\$

JPEG

JPEG is lossy, which means it compresses the image (in part) by discarding data. The data it discards is (normally) chosen to minimize the affect on the quality of the image, but it (virtually) always loses at least a little quality -- and depending on the quality level you choose, it can lose quite a bit. For most photographs it should be considered a display-only format -- once you've converted something to JPEG, you don't want to do any more editing on it. If you need to make changes, you re-start from some other format, make the changes, and do another JPEG conversion.

JPEG 2000, JPEG XR

There are newer versions of the JPEG specification. They define new forms of image compression that can generally give a better trade off between file size and image quality--your choice of the same quality with a smaller file, or better quality with roughly the same file size. They also support higher color resolution (e.g., 16 bits per channel and floating point formats to support high dynamic range). From a technical perspective, they're extremely attractive. The big disadvantage is that not nearly as many programs know how to read, display, manipulate, or write them.

HEIF

Like TIFF, HEIF is really a container format, which can contain images encoded with various methods (primarily h.265, but also h.264 and JPEG). It provides a better ratio of quality to file size than the original JPEG. Like TIFF (or GIF) you can package a whole sequence of pictures into a single file. Although there was considerable fanfare when HEIF was introduced in 2014, with many proclamations about how it was going to finally be the format that killed JPEG, most of the excitement seems to have fizzled without its displacing JPEG to any significant degree.

BPG

BPG is a format designed by the ever-prolific programmer Fabrice Bellard. It's similar to HEIF in basically being a container for an image encoded with h.265. The wrapper is a bit different, however, so the two aren't compatible with each other. From a photographic viewpoint, however, BPG has a fairly significant advantage: it directly supports embedding EXIF data into the image file.

Lossless JPEG

Although what we normally think of as JPEG is lossy, the JPEG specifications define file formats that use lossless compression as well. Since the compression is lossless, they don't usually produce nearly as small of files as normal JPEG compression can, but they actually do really well for lossless compression--much better than general-purpose compression like LZW or Huffman encoding normally even hope for on photographs. Like JPEG 2000 and JPEG XR, these work well, but suffer from lack of support.

GIF

GIF uses only lossless compression, but is limited to 8-bit (256) colors, which is quite limiting for photographs.

PNG

PNG was designed as a replacement for GIF, and mostly succeeds. It supports 24-bit color (8 bits each for red, green, and blue) and uses lossless compression. It has the color resolution necessary for photographs, but the compression it uses tends to be quite ineffective for most photographs, so files end up pretty large. The other big disadvantage of PNG is that it doesn't define a way to store EXIF (or similar) data, so if you use it to store photographs, you have to store the metadata separately. That can be fine for your own use, but means it'll generally be lost if you use it on a web page, or anything like that.

TIFF

TIFF is really a container format that allows you to insert various kinds of data into the container. While it's used primarily for images, it's really almost like a file system, so you could theoretically use it for almost any kind of data. This has a couple of consequences. One is that even if a program supports TIFF files, it may not support all TIFF files -- e.g., many don't support LZW-compressed images. In fact, few programs support all possible TIFF files. Another consequence is that TIFF tends to have a fair amount of overhead, and writing code to support TIFF (at all well) is a pain (which is why so many programs support it only incompletely).

BMP

BMP is basically just a Windows device independent bitmap written out to disk. It has only extremely limited support for compression (and most BMPs aren't compressed at all). Programs written for Windows can read/write BMP really easily, but there's not much else to recommend it (in particular, BMP files tend to be quite large for the amount of data being stored). BMP lacks any way to store EXIF (or similar) metadata. BMP is kind of like PNG, but more specific to Windows.

Conclusion

JPEG is useful as an output format (e.g., to display things on web pages it's good because it's compact, and virtually everybody can read it).

TIFF is frequently used as an intermediate format to (for example) store a file that might later be edited.

The 256-color limitation makes GIF pretty close to useless for photographs. BMP and PNG are basically harmless to the photograph itself, but can't store metadata, and the compression they use is rarely very effective for photographs (though storage prices are now low enough that quite a few people may not care much about that).

\$\endgroup\$
5
  • 4
    \$\begingroup\$ PNG actually supports 32bits, as it also supports 8 bits of alpha channel. Not that important for storing complete photographs, but if for example generating an image to be used on a web page, then the 8bit alpha channel could be really important. \$\endgroup\$
    – Pete
    Jun 11, 2011 at 10:05
  • \$\begingroup\$ Why is PNG not useful for photographs? \$\endgroup\$ Mar 15, 2019 at 19:36
  • 1
    \$\begingroup\$ @ClicketyRicket: I've edited to add a bit more information that I hope explains the situation better. \$\endgroup\$ Mar 15, 2019 at 20:31
  • \$\begingroup\$ @JerryCoffin Do you think you could add something about JPEG XR, and maybe HEIF? \$\endgroup\$
    – mattdm
    Mar 16, 2019 at 14:57
  • \$\begingroup\$ @mattdm: Seems reasonable. \$\endgroup\$ Mar 16, 2019 at 23:16
6
\$\begingroup\$

In general, I would say you probably want to save to a format that supports metadata unless you have a compelling reason to do otherwise. In that regard, jpeg and tiff are the two most common formats for photography outside of RAW+XMP or DNG.

I have used PNG in some of my online portfolios, as I've taken to rounding the corners of my scaled-down images for nicer exhibition and to do something to set my work apart from everyone elses. The down side of this is that PNG does not support metadata. This has limited me in a lot of respects, as most of the better online photo sites support automatic metadata extraction and display (i.e. Flickr).

To be more explicit...when exhibiting downscaled versions of your art online, such as on Flickr, DeviantArt, 1x, RedBubble, etc...it is probably best to use JPEG as your final output format. These files are good quality but very compact, and do support metadata. For long-term storage of originals, I would recommend RAW+XMP, DNG, or TIFF, as all of those formats do lossless compression and also keep metadata. TIFF might be the best choice for you if you are using Gimp. I have used RAW+XMP myself, as I like having my original raw files...but I have also considered converting everything to DNG to simplify file management.

\$\endgroup\$
6
\$\begingroup\$

Prepare for an immense post - yes, this got out of hand...

Obligatory xkcd:

xkcd #927 "Standards"

Unfortunately, there is no simple 'best' format. Some are very well supported, some offer extreme versatility, some offer lossless compression,...

The first part of this answer ("Features" & "Brief overview of the formats") will talk about technicalities, while the second part ("(Other) Things to consider") is more directed at the practical aspects of the choice of format.


Features:

Please note that it is almost impossible to include every hack to every format - e.g. GIFs can be saved without compression by ignoring the LZW table. Why do I not mention this below? Because 99% of all GIFs I ever encountered used LZW, because LZW today is a no-brainer in computation power, and because this post tries to clarify the situation for popular situations, not for ILM's R&D department. Photographers will use their files for archival, publishing and print, so these are the things I consider here.

Information cross-checked between the respective Wikipedia articles, specifications, Wiki's comparison, and exiftool's metadata-support-list.

               |  Bits per  |                          |     Supported by 
 Codec | Lossy |  Channel   |   Metadata    | Channels |       Programs       | Good for (IMHO)
-------------------------------------------------------------------------------------------------
  BMP  |   n   |    <= 8    |      -        |   RGBA   | Most propr. & free   | Archival
  BPG  |   y   |   <= 14    |   EXIF+XMP    |   RGBA   |                      | 
  EXR  |   o   |   <= 32    |     y(?)      |  RGBAD   |                      | VFX workflow
  FLIF |   o*  |   <= 16    |   EXIF+XMP    |   RGBA   |                      | To be seen
  GIF  |   n   |   <= 8*    |      XMP      |   RGB    | Most propr. & free   | GIFs ;-)
  HEIF |   o*  |   <= 16    |   EXIF+XMP    | RGB(A/D) |                      | To be seen
  JPEG |   y*  |    <= 8    | EXIF+IPTC+XMP |   RGB    | ~ all propr. & free  | Online; Easy access
  JP2K |   o   |   <= 32    | EXIF+IPTC+XMP |   RGBA   |                      | 
  JXR  |   o   |   <= 32    | EXIF+IPTC+XMP |   RGBA   |                      | 
  PNG  |   n   |   <= 16    | EXIF+IPTC+XMP*|   RGBA   | Most propr. & free   | CAD-drawings; Online
  TGA  |   n   |    <= 8    |     y(?)      |   RGBA   |                      | 
  TIFF |   o   |   <= 32    |   EXIF+XMP    |   RGBA   | Most propr. & free   | Archival; Editing
  WebP |   o   |    <= 8    |   EXIF+XMP    |   RGBA   |                      | 

Legend: o... Optional; n... not available; y... available; D... Depth; *...Look below at according text.


Brief overview of the formats:

BMP

 Feature      | 
-----------------------------------------------------------------
 Introduced   | 1990
 Open + Free  | Both per Microsoft's Open Specification Promise
 Colorspace   | R:G:B[:A] (4:4:4[:4])
 b/c/p        | 1:0:0[:0], 5:6:5, 8:8:8[:8]
 Compression  | None [RLE in 5:6:4] (so: lossless)
 Maximum Size | 4 GiB
 Metadata     | [ICC]
 OS support   | Virtually all OSs with a graphical interface

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Bitmap' files are encoded in lines and are usually not compressed, so a single bit flip will only destroy one line of the image As long as it does not flip the header, which will make decoding harder - try it for yourself with a HEX editor!. Since it does not offer (good) compression, file sizes are huge, as it has to save the full information for each pixel. Because of its rigidity, it may be good for long-term archival.


BPG

 Feature      | 
---------------------------------------------------------------------
 Introduced   | 2014
 Open + Free  | Yes (but HEVC patents might be problematic)
 Colorspace   | R:G:B[:A] (4:4:4[:4]); Y:Cb:CR[:A] (4:2:0[:4] - 4:4:4[:4]);
              | Y:Cg:Co[:A] (4:2:0[:4] - 4:4:4[:4]); C:M:Y:K (4:4:4:4)
 b/c/p        | 8 - 14
 Compression  | HEVC (lossy / lossless)
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [XMP]
 OS support   | Linux, Mac, Windows (at least through browser decoding)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Better Portable Graphics' (BPG) uses HEVC, which you may know from the h.265 video codec. It was meant to be the successor to JPEG, but never got popular enough. With the rise of HEIF, which is quite similar in some ways but more popular, it is plausible that HEIF will be preferred. HEVC is far superior in terms of compression compared to JPEG's DCT - however, it does not compare well in all but the lower bit rates, as it tends to be blurry.


EXR

 Feature      | 
---------------------------------------------------------------------
 Introduced   | 1999
 Open + Free  | Yes
 Colorspace   | R:G:B[:A][:D] (4:4:4[:4][:4])
 b/c/p        | <= 32
 Compression  | [RLE]; [ZIP]; [PIZ]; ... [lossless (usual) / lossy]
 Maximum Size | > 4 GiB
 Metadata     | [Yes (XMP-style)]
 OS support   | Linux, Mac, Windows (through library)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

OpenEXR was designed by Industrial Lights and Magic (ILM) as an intermediate format for VFX workflows. It can hold multiple channels at very high bit depths, multiple images, and metadata in one file. It offers different compression algorithms - or no compression at all. EXR can be compared with TIFF - EXR offers more options, while TIFF is far mroe popular.


FLIF

 Feature      | 
---------------------------------------------------------------------
 Introduced   | 2015
 Open + Free  | Yes
 Colorspace   | R:G:B[:A] (4:4:4[:4]) (CMYK and YCbCr in ToDo-List)
 b/c/p        | <= 16
 Compression  | MANIAC (variant of CABAC, used in AVC/HEVC) (lossless / lossy (1st generation))
 Maximum Size | > 4 GiB
 Metadata     | [EXIF]; [ICC]; [XMP]
 OS support   | Linux, Mac, Windows (through provided viewer)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Free Lossless Image Format' (FLIF) uses a derivate of HEVC compression that is lossless. FLIF claims to have extreme compression ratios in comparison to all other formats of the time - while my own tests led me to believe this, it really needs computing power to be usable (Several minutes of encoding time for a single 24 MP picture with a hyperthreaded 4,3 GHz hexacore is not that good :D). However, as it is a young codec, improvements might come forth. It offers support for animations, alpha channels, progressive decoding, and even lossy encoding (with no more generation loss after the first encoding). Only time will show if it will succeed, and to be honest, I quite hope so, as it seems to offer a single solution for multiple problems.


GIF

 Feature      | 
---------------------------------------------------------------------
 Introduced   | 1987
 Open + Free  | Yes
 Colorspace   | R:G:B[:A] (4:4:4[:4])
 b/c/p        | 2 (palette of 256 colors in total)
 Compression  | LZW (lossless)
 Maximum Size | < 4 GiB
 Metadata     | [XMP]
 OS support   | Virtually all OSs with a graphical interface

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

While 'Graphics Interchange Format' (GIF) offers 8 bits per channel per pixel, it will reduce them to a color palette of 256 colors (which can include a "background color"). It is mostly used for animations - the only thing that PNG cannot do better, as PNG in itself does not offer animation support.


HEIF

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 2015
 Open + Free  | No (patents)
 Colorspace   | ? Y:Cb:Cr[:A/:D] (4:2:0[:4]) ?
 b/c/p        | <= 16
 Compression  | HEVC (lossy)
 Maximum Size | < 4 GiB
 Metadata     | [EXIF]; [XMP]
 OS support   | Linux, Mac, Windows

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'High Efficiency Image Format' (HEIF) uses HEVC for compression, too. In addition to the color channels, it can also hold either an alpha channel or a depth map (used for later software depth-of-field effects). Also, rudimentary editing can happen losslessly. Accoding to specs, it also has a lossless compression mode. Since all major OSs support it, it seems like the most likely contender for a succession of JPEG (if there ever is one).


JPEG

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 1991
 Open + Free  | Sort of (free library, but patent might apply)
 Colorspace   | Y:Cb:Cr (4:2:0 (typical) - 4:4:4)
 b/c/p        | 8
 Compression  | DCT (lossy)
 Maximum Size | < 2 GiB
 Metadata     | [EXIF]; [ICC]; [IPTC]; [XMP]
 OS support   | Virtually all OSs with a graphical interface

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Joint Photographic Experts Group' (JPEG) is arguably the most used image format around today. It uses the discrete cosine transformation (DCT), which is of the lossy kind.There is a lossless specification, but it is not used too often. Certain programs can perform certain rudimentary actions (e.g. rotation) losslessly, though this also requires the image width and height to be divisible by 8 (the block size of JPEG) - e.g. 800x640 will work, 804x643 will not. JPEG has no option to save images in RGB - it transforms the picture into the YCbCr colorspace and often reduces the pixel information from 4:4:4 (every pixel has all channels) to 4:2:0 (every channel has luminance, but only every 4th pixel gets a Cb/Cr-value). As with most colorspace conversions, this can lead to perceivable differences especially in extreme colors. JPEG is quick to encode and not too bad in high quality settings, but to me, the things mentioned above would not make me weep if it ever vanished - it served us well, but the used image formats could be a bit more...recent. After all, computers evolved well since 1991.


JP2k

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 2000 (duh...)
 Open + Free  | No (patents)
 Colorspace   | ? Y:Cb:Cr[:A] (4:4:4[:4]) ?
 b/c/p        | 8 - 32
 Compression  | Wavelet (lossy / lossless)
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [IPTC]; [XMP]
 OS support   | Linux, Mac, Windows (at least through viewer programs)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'JPEG 2000' (JP2k or JP2) is the official successor to JPEG. It uses wavelets instead of the DCT, which offer less blocky artefacts and is overall more versatile than JPEG. Despite all this, it never really caught up with JPEG.


JXR

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 2009
 Open + Free  | Yes (Microsoft Open Specification Promise)
 Colorspace   | Y:Cb:Cr[:A] (4:2:0[:4] - 4:4:4[:4]); Y:Cg:Co[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
              | C:M:Y:K [4:4:4:4]
 b/c/p        | 8 - 32 (16 for CMYK)
 Compression  | DCT (lossy / lossless)
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [IPTC]; [XMP]
 OS support   | Linux, Mac, Windows (at least through viewer programs)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'JPEG extended range' (JPEG XR, JXR) is another try to succeed JPEG. Its YCgCo colorspace is superior to YCbCr because it is entirely reversible. While some software supports it, it too never got close to the fame of other formats.


PNG

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 1996
 Open + Free  | Yes
 Colorspace   | R:G:B[:A] (4:4:4[:4])
 b/c/p        | 8 - 16
 Compression  | DEFLATE (lossless)
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [IPTC]; [XMP]
 OS support   | Virtually all OSs with a graphical interface

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Portable Network Graphics' (PNG) was introduced as a successor to GIF. While it is lossless by design, PNG files can be optimized with several tools, some of which will compress the file in a lossy way. PNG uses the DEFLATE compression, so it is quite efficient for graphics (like CAD drawings, screenshots,...), but less efficient for photographs. While it offers support for metadata, some programs have trouble reading them. Thanks for the heads-up, @mattdm!


TGA

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 1984
 Open + Free  | ? Yes
 Colorspace   | R:G:B[:A] (4:4:4[:4])
 b/c/p        | <= 8
 Compression  | RLE (lossless)
 Maximum Size | ? < 2 GiB
 Metadata     | Rudimentary
 OS support   | ? Virtually all OSs with a graphical interface

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Truevision TGA' / 'TARGA' (TGA) is a fie format that I only included because everyone seems to know it. It was introduced in 1984. It supports lossless compression (RLE) which will work okay for graphics, but not-so-well for photographs.


TIFF

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 1986
 Open + Free  | ? Yes
 Colorspace   | R:G:B[:A] (4:4:4[:4]); Y:Cb:Cr[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
              | C:M:Y:K (? 4:4:4:4 ?); L:a:b[:A] (? 4:4:4:[A] ?)
 b/c/p        | 8 - 32
 Compression  | [LZW (lossless)]; [ZIP (lossless)]; [JPEG (lossy)]
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [XMP]
 OS support   | Virtually all OSs with a GUI support >= 1 of the compression types

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'Tagged Image File Format' (TIF or TIF) has been around for a long time, too. It offers layer support (i.e. multiple RGBA-images stacked). TIFFs are often used as intermediate files because the are widely supported and quite flexible in terms of their capabilities.


WebP

 Feature      | 
----------------------------------------------------------------------
 Introduced   | 2010
 Open + Free  | Yes
 Colorspace   | R:G:B:A (4:4:4[:4]) lossless; Y:Cb:Cr[:A] (4:2:0[:4]) lossy
 b/c/p        | 8
 Compression  | VP8 (lossless / lossy)
 Maximum Size | ?
 Metadata     | [EXIF]; [ICC]; [XMP]
 OS support   | Linux, Mac, Windows (at least through browser decoding)

Legend: b/c/p... bits per channel (e.g. R,G,B) per pixel. things in [ ] are optional; ?...educated guess / no clue.

'WebP' uses VP8 (an open source rival format to AVC). As with BPG, it never made the leap into consumer devices, though it seems that it is used by many internet services.


(Other) Things to consider:

Re-encoding (generation loss)

Re-encoding a lossless file will not alter anything - re-encoding a lossy file will almost certainly lead to artefacts. JPEG can handle this pretty well if you save the file in the same quality setting that it was saved at before.

This video shows generation loss pretty well - the first frame shows the original file, while all others show re-compression at different quality settings. (Note that FLIF is in lossy mode, so the first frame will look different.)

Artefacts will not necessarily be a death sentence - e.g. for quick web publishing or preview on mobile devices, it might not be too bad.

Longevity of codec

When writing this answer, I was thinking to myself "who would use TARGA nowadays, anyway?" and it made me think: I would not ever hesitate to drive a car made in the 80's. I would not hesitate to look at pictures shot in the 80's. I would use any cameras made in that time. But I would not use a codec that old. Why?

In the end, there is no sure way to say whether one codec or the other will survive a certain time span. If HEIF were to replace JPEG on all consumer devices tomorrow, how long would it take for programs to cease JPEG support? How many generations of computers - and more importantly: OSs - will there be before you can no longer open them?

On the other hand, relatively simple codecs like TARGA only demand for relatively simple programs to read them, while modern codecs and their decoders have multiple dependencies. So while simplicity is bad for compression, it might be good for archival in an apocalyptic scenario. Thanks @lijat for pointing this out!

In my opinion, this needs several angles to consider: Which codec is popular enough so that support will not drop immediately? Which codec is supported by the open source community (because noone will maintain proprietary formats from a bankrupt company)? Also, it seems that at least every decade or so, one should see if there is a need to jump to a new, better supported codec (See "Re-encoding (generation loss)") - you would not, for example, want your TARGA-collection to be unreadable tomorrow, right?

That, by the way, is especially worrying when thinking about RAW files.

Program support (Longevity #2)

The most popular, best codec will not be good enough if you cannot use it. And while I would not use inferior codecs just because a particular program does not support it, it might be bad to use a codec that just one program properly supports.

What features do I need?

Personally, I still encode most of my files in JPEG - I can read them on any device and I can barely (if at all) see the artefacts. 8bit is good enough for most devices and alpha channels are not really needed when just viewing pictures.

For all files that are not "edit once"-style, I either keep my RAWs or at least 16bit TIFFs so that they are still useable in the future.

PSD? DNG?

"Photoshop Document" (PSD) is Photoshop's TIFF-styled format. Technically, it is quite similar to TIF. There is PSB, too, which is the same thing just for file sizes over 4 GiB. There is nothing wrong with using it, but personally, I prefer TIFF as far as possible.

"Digital Negative" (DNG) is an attempt to create an open RAW standard. While I love the idea and it works quite well, note that some RAW editors have trouble with them - e.g. Capture One typically forgets the camera's white balance, thus setting the slider to 5000K, no matter what the actual value is. Other programs in the past have shown them as solid white or pink images or give them a magenta hue. If file size is of no concern to you, then you can include the original RAW in your DNG - if you ever need it again, you can simply extract it again. My 2 cents? Try it out with your favourite software - and if it works well, use it.

Other formats?

Since this already got out of hand, I did not want to address even more image formats. However, this does not mean that those not listed are not worth considering.

\$\endgroup\$
2
  • \$\begingroup\$ Trivia: I just realised that "Our DSP is not optimized for codecs other than JPEG" is a lazy excuse today, as most cameras offer some sort of advanced codec (AVC/HEVC) for their video capabilities. \$\endgroup\$
    – flolilo
    Mar 16, 2019 at 14:27
  • 1
    \$\begingroup\$ As you wrote about format suport I think it is worth mentioning that the simpler a format is the easier it is to keep suported. That is a big pluss for things like uncompressed targa which are simple enough for a programing student to write a decoder in an afternoon (meaning that even if all supporting software was lost it could be easily recreated on the cheap). \$\endgroup\$
    – lijat
    Mar 16, 2019 at 15:35
3
\$\begingroup\$

I save my edited images as TIFF with LZW compression. I use the Gimp to edit and I have scripts based on ImageMagick that convert the TIFFs to JPGs of various sizes and quality levels for web use, printing, etc. I expect PNG would also work; I chose between them choice several years ago and I've forgotten why I picked TIFF. (Maybe it was the metadata issue other responders have mentioned, or perhaps ufraw's PNG output was too slow.)

When I want to preserve layers for future editing, I save as .xcf.gz (Gimp's native format with gzip compression). Of course, if you use programs besides Gimp, that may not be helpful.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.