Image’s compression concerns

[leoskats]

Hello guys. Can I ask you a question? Lossless compression (TIFF, PNG) does affect only the image’a size and not the quality, right? So an edited and exported Image, as a PNG or TIFF (with 16 bits color depth), has the same quality with all the information of the original image?! I ask this because I want to maintain my images in perfect quality in my storage but simultaneously to upload images in web in perfect quality. Is it safer and better to go with PNG (24 bit) or TIFF?

 

ps: I don’t mind about the large files, I got storage. I need an advice about the formats and if the image quality between those two formats differs! Thanks a lot guys in advance

[walt.farrell]

We've told you before that lossless compression affects only the size of the file, not the image quality. You don't need to keep asking; the answer won't change

In general, whether it's better to use PNG or TiFF will depend on how you intend to use the images. For some uses, even JPEG may be better.

By the way, be careful with terminology. A PNG with 24-bit color depth is only 8 bits per color channel, not 16. You'd need a PNG with 48-bit to get 16 bits per color.

You're confusing the file format with the name of the export preset in Affinity Photo, again.

If you have an RGB (16-bit) file in Affinity and export using the preset named PNG-24 you'll get a PNG file with 48-bit color depth (16 bits per color channel) if you use the default export settings.

[leoskats]

Oh okay! Yes I confuse them but okay I think now I understood. Between TIFF and PNG when both image files support 16 bits per channel then it’s better to go with png for web reasons and storage. The lossless compression is the same in terms of photo quality in both images... also when a file is smaller, do I lose something or not? 

[mac_heibu]

NO YOU DON’T LOSE QUALITY! in other words: YOU DON’T LOSE QUALITY!

Imagine this:

You have a file with 100000 bytes, each representing a color.

What file do you think is larger:

This one:

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

… and so on …

Or this compressed one:

100000 x 1

And which file has better quality the first one or the second one after having „decompressed“ it again?

Did I already say YOU DON’T LOSE QUALITY?

[Alfred]

40 minutes ago, leoskats said:

when a file is smaller, do I lose something or not?

As previously discussed, a compressed file comes at the expense of longer processing time when loading or saving the file, but the difference is trivial on a modern computer.

[leoskats]

Oh okay really thanks! Because there is a misleading between PNG and TIFF and I read articles like this and I’m like what image format is better or not? Sorry for my questions, i’m amateur! 

[SrPx]

Leo, that article, tho I skimmed per chunks, is correct for the most part... but a bit misleading in how this person considers lossless compression.. Through all the article he is warning about the dangers of using EVEN LOSSLESS compression, and we all know there's no issue in doing so. But he kept until the end to explain the reasons why he personally don't like compressed. Look, even if he had a practical valid point in this specific detail (again, I find the article is correct, I just don't agree in one important point) , the solution is storing tiff UNCOMPRESSED! Geez !.  Those files are HUGE.... Perhaps he counts with amazing quantities of space storage, but even if he has some years lasting devices, the maintenance of that, as disks break (there's quite some debate about SSD lifespan, but that's another matter, as I wouldn't ever use SSD for big storage solutions) , fall, get wrecked, you get a power shortage that force a peak and might loose a disk, etc... hardware is not only about one time purchase, is about general maintenance costs.  I use files with 100s of layers, print resolution, sometimes fully layered CMYK files... you need certain level of lossless compression or you run out of available space pretty fast.

His main dislike of lossless compression is....that a compression algorithm can later on be not understood by A or B program... Well, that'd be a point for the specific case of an acrhive thought to last many decades without any maintenance, I guess. Also, may come for the hjgh level of incompatibility seen in speciall TIFF compression. For some reason, you often get some software not able to read a certain tiff compression, sometimes even being the exact same type of compression (zip, LZW, etc). Indeed, I agree i the case of TIFFs till certain extent, as I typically would even just store the tiff uncompressed, then use 7zip or whatever (7zip is relatively modern, if we go back to the 90s, lol...) , as I tested to compress a lot more, and I knew having problems opening it again was less likely to happen in any case. So, for a while I'd save (i still do sometimes) my print files as tiff, then I'd zip 'em. So they open a bit faster, they are safer, and use less disk space. They tend to compress very well by zip. There are other better compression formats, but that has the advantage of being very universal, and opened by default by most OSes.

PNG has compression by default. I think he is transferring all the issues in compressed TIFFs to PNGs. And that's wrong, imo. I extremely doubt you'll have any sort of problem  opening a PNG in 20 years from now ! neither later on, really.  I mean, you can yet even open a PCX, format from Zsoft Paintbrush ! And that's been not really used like in 30 years...or many more. The PNG compression, or any compression at all, does not harm any quality aspect of your work. For archiving for museums and stuff, maybe his approach is kind of correct, but even so, that's a flawed point, as the same way, tiff format could be deprecated at some point ! I wouldn't be surprised, even. Won't happen any time soon, as is used in every scientific place out there, yet, and is a life saver for print companies when there's no way to open a native file of certain designer in a print shop where they use another.  (ie, typical situation in a crazy rush when the designer sends a native file in CC native format when the cheap shop only handles Corel... 9 times out of 10 they'll ask for a tiff, EPS or similar, then....)

My advice, but just a personal take at it that has always worked great for a very varied set of cases, for a very long time :  I use PNG for anything where I don't want any sort of variation, I want files to keep kind of small, and mostly, I want anyone to be able to open it without needing to have certain software to see the file correctly. if I want the file to keep DPI info (resolution), cmyk, the color profile,  and a bunch of other things, then IMO one of the best ways is PDF (you can go with tiffs, but I'd recommend PDF, I use some sort of PDF/X, but the specific file version and even format is often dictated by  the print company !).  Gif only for some fast animated thing, and showing fast sprite animated pixel art to some individuals. For nothing else, as is much better covered by PNGs, and gifs (like PNG-8) do force 256 colors only. Ok just for pixel art, and even so, if well exported. Depending on the case, EPS for vectors, but even there I prefer too PDF. 

That said, for your "work" files... I'd rather just use native files, fully layered and with all in very editable form. The formats mentioned above are mostly for exports and if you have that archiving paranoia, and want to fill very safe. But then you need to save the exports in a layers (and maybe also selections/alpha channels) supporting formats (this leaves out PNG, GIF, etc).  That is, in your project folder, you should be saving several versions (typically after certain significant amount of work done) of same project, in native format. be it A . Photo, Designer, or whatever you use at each moment. I do so, but I also do export in full res in PDF format. Editable and flattened. Both. That's me, though.

With PNG, you are storing the pixels, though, is just that if you want those pixels to be printed at a specific DPI and size in inches, mm or whatever, you might need to open that in a package, set a physical size and dpi, then save in a format better suited for that. This info (dpi and physical size in cm/inches, etc) is actual metadata, that comes in the files'  header. In the case of PNG's (in phYS chunk)  metadata, it can port this info, but that has some issues, and also, a lot of software do simply not export the info in the PNG metadata , so, is a bit useless that a format has sth not used by the majority of apps. JPG can also port this info. But...it has the huge issue of adding artifcats, is a lossy format. Never to be used for continued editing, and certainly, only just fine for very specific exports. IE: the web.  That said, a huge amoung of printed magazines, some very important ones, do use JPGs for their images, as is a very fast way to keep a fantastic ratio between quality/cmyk, dpi, size support and other matters/ and size, most of all. As those magazines and newspapers have a big issue with that. Also, the paper already is a huge part on the quality loss, anyway. I wouldn't use JPG for MY final files, other than showing on the web. And indeed, would depend on the case, even so.

So, I'd go for : native, PDF, PNG, mostly.  With an specific use of each one. Keeping a PNG export of each important stage has served me in some rare cases of disaster (ie, overwriting totally a file...)

[leoskats]

17 hours ago, SrPx said:

So, I'd go for : native, PDF, PNG, mostly.  With an specific use of each one. Keeping a PNG export of each important stage has served me in some rare cases of disaster (ie, overwriting totally a file...)

Hello! Firstly I want to say a big thank you for your effort and your big explanation! Yes I totally AGREE with you that this article challenges even lossless compression and with no point. If you do have a lossless compression then you successfully have all the information of the image but in a logical image’s size. I don’t see why to go through with a TIFF uncompressed when you can have the very same image’s result with PNG in terms of quality. We all know that TIFF in web supported only by safari and not by social networks as Instagram. PNG is even more web friendly and Instagram supports it too... I found such articles too much and I’m confused when I read them 

[SrPx]

 

Summary/conclusion here :

About TIFF....  I'd agree with the article poster on preferring to save the TIFF uncompressed (because tiff compressed often creates compatibility issues among apps). But I would add my  two bits there: after saving the uncompressed tiff, I'd compress the tiff as a zip file with a compression utility for general files. like Winzip, Winrar, 7-zip (free and my favorite), using always zip format, as is just what decompress super easy in every O. System.  Or even just your own operating system (mostly for zip files) decompressing them. And/or the infinite third party tools for this available in Win, Linux or Mac. ) . 

TIFF is often a very good format for print companies (in the comic industry is still used heavily. And in non comic related, print shops for small business and etc), for many reasons: Like, it solves the problem when the native format from the client (your client) is not compatible with the print shop software, so could tell the client to just export again (imo, any company working for printing, has some way to import and export a TIFF) as TIFF , or PDF, which almost sure, will be opened fine in that print shop. Another reason for which TIFF can come handy often, is as certain specific metadata, like DPI, CMYK, physical size any color profile embedded, and etc, those chunks are usually read from the tiff header, without probs in case of a tiff file. I mean,  typical design software packages support this metadata info.......IF support of the features (CMYK, setting a custom DPI, inches/mm, etc) is already implemented there, so  that the app can deal with it internally.... 

A lot of printing companies prefer tiff (it used to be TIFF for raster,  EPS for vectors, typically, and now is often just PDF for both raster and vectors.) over anything else, but lately PDF is used everywhere. I'd recommend using mostly PDF (but exporting with the right settings, this is very key), tho is a very personal opinion. For the web..... yeah, no tiff... Just JPGs and PNG, depending on the type of graphic content.

[Alfred]

41 minutes ago, SrPx said:

compress the tiff as a zip file with a compression utility for general files. like Winzip, Winrar, 7-zip (free and my favorite)

7-Zip can compress to either 7z or zip format. The 7z format often yields much smaller archives than the standard zip format, but not all compression utilities can read them.

https://wikihow.com/Open-7z-Files

[SrPx]

Yep, I did know that ...but omitted it on purpose. The average joe/jane, specially person wanting you to work in a project, rarely is able to deal with even a file compressor, let alone with one that the OS can't decompress itself, or that is not understood by popular decompression utilites....

Same reason I don't use any more extreme PNG compressors... some apps wouldn't read'em after that. Also, because saving some bytes was more of a need of the past... what you save from zipping or making it a 7z, or, using png crunch, superPNG, etc, over a PNG, ain't worth it anymore, with today's bandwidths, and CPU, disk, etc...The risk of the other person or whole audience having issues with just opening the thing... No thanks, faced a few of those cases...not anymore....   

That said, with long term projects, with friends, or indies of the geeky nature.. I've ended up using 7z format, but even there, would use it only if the sapce /bandwidth saving would really really compensate for the longer compression and decompression times (plus more CPU etc usage). So, I've noticed which 7-zip settings for doing a standard *.zip are best for maximum compatibility, yet decent size. Works pretty well for me, since  years....

 

[leoskats]

Okay yes I understood. Also another point is that lossless compression is lossless compression. Every image format that supports lossless compression is the equal with another image format with lossless compression. The quality is the same in every lossless image format. Now what you will choose is something very special and based on your needs each time.

[leoskats]

Guys hello again! So why a 16 bit color depth file that exported as a TIFF has bigger size than one that been exported as a PNG? Does PNG or TIFF differs in quality pixels or it's just for web and print respectively? Thanks.

[mac_heibu]

They differ, because they follow different strategies, have different format capabilities (transparency, color systems, path support, …), because they are differently build, serve different purposes. If you are really interested in this: There are file specification to be found in the web: PNG TIF For more simple information ask wikipedia.

[SrPx]

typically tiff has not a great compression algorithm associated. What I've typically selected as an option has been lzw or zip. But zipping externally an uncompressed tiff would actually leave it smaller for storage (and even more more specialized but slower compression formats).  Again, they are lossless, mate. No quality lost "in the pixels" . The differences are in how each one stores alpha channels, transparency, etc.  But you don't get an algo blurrying the image or anything like that like with a jpg.

Oh! You said 16-bit.....you mean editing in 16-bit mode in AP or PS.... Well, also, consider then if the software whatever you are using supports really saving all that info into PNG. As png has many ways to be saved... as paletted PNG for the web (ie, PNG-8, PNG-24 (8-bit per channel), PNG 32 if includes the alpha channel, etc). Not all software can save as PNG a file that you have been working in 16-bit mode,  and keep the info without converting to the very usual png-24 / 32. If the app -and I dunno about A. Photo 'cause guess what; I don't have it yet  - wait...I have yet the trial, as was testing brushes/painting/color selector the other day, to decide on purchasing or not, let me check... Nope, or at least the current trial,  seems only exports as PNG-24 and PNG-8. So, that's one of the reasons why you see the size difference. It should export as PNG 48 bits, or 64 if including the alpha information. Exporting as PNG-24 is actually downgrading the image to 8-bit per channel, logically.

Visually you might not notice it (but in printing, photo labs, and even regular 8-bit displays in some cases, there you could notice the difference). usual graphic cards work in 8.bit, and so do most monitors. Professional cards and monitors, and it's needed that both would comply with that, should need to support 10-bit,. to see stuff a bit better than in 8.bit mode. But apart from that, I 've noticed that even with crappy hardware, it seems that in 16-bit you get much better gradients and transitions, even better tones, even while the display and card supports only 8-bit. I never understood that, but I checked that it happens, many times. 16-bit tiffs are used often in 3D for better height maps generation (grayscale image that is used to generate a 3D landscape, or any volume/relief). But from A. Photo you can export a tiff that you have worked in 16-bti and keep all the info. I suppose a PSD and other formats might keep all the info, as well.

Anyway, don't over obsess with formats, just know what each does what.....Now I realize that Walt had explained it to you at the beginning, and your first post already mentioned 16-bit mode, so, per channel (so, you'd be after a PNG-48 or 64 for a proper export, and wee don't have that in AP. Probably clever, as anyway, PNG lacks in many matters compared to tiff for certain type of workflows), and he explained the difference to you, and how a PNG-24 bits means having 8-bit per channel (so, exporting a PNG-24 is a downgrade in you have been editing in 16-bit) If you work so much in 16-bit, then maybe save in TIFF, then compress the files (those are mostly to be stored, not every day use), or entire folders, as 7z or zip. (zip safer, imo, for compatibility). Maybe just use each format to its best strengths 

Edit: Nope. Just checked now a recent thread:  https://forum.affinity.serif.com/index.php?/topic/60179-png-24-exports-with-48-bit-instead/           

You can save PNG -48 in AP, seems  it says "PNG-24" and even so, you'd be saving a 48 bits per pixel PNG, having worked in a 16-bit mode, and not loosing any info/quality.

 

EDIT 2 : Also, i n the PNG export dialog, click on advanced options, and choose in pixel format :  RGB 16 bit (while I'm there, imo Lanczos algo , or at least bicubic better than bilinear, if reduction occurs)

 

[walt.farrell]

13 minutes ago, SrPx said:

you'd be after a PNG-48 or 64 for a proper export, and wee don't have that in AP

Affinity Photo does support PNG with a 48-bit color depth. That's what you'll get if you start with a 16-bit image and export to PNG using the PNG-24 preset[*], for example. I don't know about PNG-64, though.

* A confusingly-named preset, since it really exports using the document's color depth, rather than specifically exporting using 8-bits per channel. So, if you have an RGB-8 document you get the PNG-24 file format, but if you have an RGB-16 document you'd get the PNG-48 file format.

[SrPx]

seems we cross-posted, I had already fixed that 

[walt.farrell]

Yep.

 

[SrPx]

13 minutes ago, walt.farrell said:

That's what you'll get if you start with a 16-bit image and export to PNG using the PNG-24 preset[*], for example. I don't know about PNG-64, though.

it doesn't seem so... a 16-bit image gets well exported to PNG 48 bit, but no alpha. It exports, both if selected on PNG export at pixel format "same as document" or "16 bit" you get no PNG 64, but a 48bit PNG with no alpha.

[walt.farrell]

6 minutes ago, SrPx said:

it doesn't seem so... a 16-bit image gets well exported to PNG 48 bit, but no alpha. It exports, both if selected on PNG export at pixel format "same as document" or "16 bit" you get no PNG 64, but a 48bit PNG with no alpha.

I just took a 16-bit TIFF file, with Transparent Background enabled in the Document menu, and with actual transparent areas in the image (this is important), exported using the PNG-24 preset, and got a PNG file that IrfanView says has 64 bits per pixel. And the transparent area has survived.

[SrPx]

my bad... my image  was not transparent---no need of starting from a transparent tiff...

tested it, is a 64 bits png  (rmb on file , properties, details.)

[leoskats]

Thank you guys for your valuable help! I find the image formats a very confusing topic that’s why I ask and ask! Yes I understood that AP supports PNG-48: the point is that quality and i mean only pixels and information of the image do not change between TIFF and PNG - the result is the same. I don’t talk about the size or the compression method that each form follows, but only for the visuality!  Have a nice day!

[SrPx]

Last note: Always consider that is not an issue with Affinity, but always be aware that picture viewers,  laptops/cell phones screens or software, or browsers are not capable, often, to display properly an image with an embedded color profile, or a CMYK tiff or jpg, or can't display a 48 bits PNG...it can lead you to think you made sth wrong. Just be aware, as many devices and software can only display sRGB color space, no profiles, no CMYK, and even no 16-bit per channel images. In those cases, be sharp enough to realize, or double check, that is not your source, but the fault of the viewer software or browser or etc.