# Differences on image file extension for cover art
**URL:** https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392
**Category:** General Discussion
**Created:** [April 13, 2024, 3:00pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392 "2024-04-13T15:00:10Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 3:00pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/1 "2024-04-13T15:00:10Z")
Hello everyone,
I've read some topics on the subject of picture quality for cover art embedding, and while they provided some info, I couldn't find what I was looking for.
There are many image file extensions out there, both know and less known, and for cover art usually, the bigger the better (bigger dpi, bigger resolution, etc). This of course leads to a bigger file size.
Is there a difference in file formats that, for the (approximate) same values, can cause a major difference in file size?
As an example, the link for the iTunes cover art for [2Pac's Greatest Hits](https://music.apple.com/us/album/greatest-hits/1440763429) album is [here](https://is1-ssl.mzstatic.com/image/thumb/Music115/v4/aa/07/db/aa07db20-0b14-d09c-ead7-5b9e3680cb76/00602527051840.rgb.jpg/600x600bb.jpg) (600 x 600px).
Through experimentation, I found out that I can change the resolution in the URL, and the resulting image is resized to that resolution (if available). I've also found that changing the file extension in the URL, the image is converted to that format. From the previous link, if I change the final ".jpg" to ".png" I get this [link](https://is1-ssl.mzstatic.com/image/thumb/Music115/v4/aa/07/db/aa07db20-0b14-d09c-ead7-5b9e3680cb76/00602527051840.rgb.jpg/600x600bb.png), with the resulting image in .png format, but looks the same. Downloading both pics to my hard drive and getting their properties in Windows, side by side, show pretty much the same values (600x577, 96 dpi, 24bit color); zooming them both to 5000x and comparing them doesn't show much difference regarding the pixel distribution.
However, the .jpg is ~81kb, and the .png is ~509kb.
There must be something I'm missing (compression?, some property not shown?) that justifies this size difference.
Can anyone give me some pointers, or know of a good tool to get more image details so I can find what makes one image so much bigger than the other, while having -apparently- the same quality?
Thanks in advance.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 13, 2024, 3:18pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/2 "2024-04-13T15:18:41Z")
PNG is a losless compressed raster image format.
JPG is a lossy compressed raster image format.
If both files look the same then the question would be: has the png been converted from the jpg? Then, of course, the quality will not be better.
Both file formats are valid formats to embed in ID3 tags.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [April 13, 2024, 3:20pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/3 "2024-04-13T15:20:20Z")
One of the biggest differences (beside the compression) is that PNG supports transparent backgrounds.
This may not be needed for Cover Art pictures.
You can find many more differences here in this article:
> **[JPG vs. PNG: Which is Better?](https://www.techsmith.com/blog/jpg-vs-png)**
>
> Confused about which image type to use for your website or marketing project? Find out more details and see what the pros and cons of both file types are in this blog post.
For Cover Art embedded in music files, it also dependes on how big you choose the resolution of our pictures. For a 200x200 thumbnail it doesn't matter that much if you choose a JPG or a PNG format.
But if you embedd a 5000x5000 pixel file, that will increase the (lossless compressed) PNG file size clearly noticeable.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 3:58pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/4 "2024-04-13T15:58:59Z")
> [@ohrenkino](#):
>
> If both files look the same then the question would be: has the png been converted from the jpg?
Exactly. How to tell if a conversion really happened from one format to another? Something must have happened to justify the new file size; more than just changing the file extension.
Do you know of some tool for checking the converted .png and verify that there was indeed a conversion?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 13, 2024, 4:05pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/5 "2024-04-13T16:05:19Z")
> [@rboss](#):
>
> Do you know of some tool for checking the converted .png and verify that there was indeed a conversion?
I don't understand.
As jpg is a different approach to save pixel information than the method for pngs is, of course there was a conversion.
As an experiment you could change only the file extension and if you open that modified file then probably the program will either refuse it altogether or produce an error that it is no valid format.
If you are interested in graphics formats, then create a plain pixel file e.g. bmp or tiff and convert it to jpg and also to png and compare them.
The bigger the original picture the more obvious the differences should be.
But a conversion from an already lossy format to a principally lossless format will never restore the lost information.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [April 13, 2024, 4:07pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/6 "2024-04-13T16:07:20Z")
> [@ohrenkino](#):
>
> As an experiment you could change only the file extension and if you open that modified file then probably the program will either refuse it altogether or produce an error that it is no valid format.
Exactly. [IrfanView](https://www.irfanview.com/) for example tells you:
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [April 13, 2024, 4:10pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/7 "2024-04-13T16:10:08Z")
> [@ohrenkino](#):
>
> But a conversion from an already lossy format to a principally lossless format will never restore the lost information.
That would be the same if you convert a mp3 music file (lossy) to a lossless FLAC.
The music content will not be "better" in FLAC then in the source mp3.
There is no "magic quality enhancement" in the convert process. Neither for music nor for picture files.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 5:23pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/8 "2024-04-13T17:23:20Z")
> [@ohrenkino](#):
>
> I don't understand.
Different approach then:
Let's call the .jpg downloaded from the url "file A", and the .png downloaded from the url "file B".
File A: .jpg / 96 dpi / 24bit color / ~81kb
File B: .png / 96 dpi / 24 bit color / ~509kb
In plain MS Paint, I opened file A, made no changes, and saved as a .png (file C)
Adding the info of the new file to the list:
File A: .jpg / 96 dpi / 24 bit color / ~81kb
File B: .png / 96 dpi / 24 bit color / ~509kb
File C: .png / 96 dpi / 32 bit color / ~653kb
Files B and C are similar, but B has the color depth in 24bit and C in 32bit; naturally C is larger in size than B.
What I'm trying to understand is: if A and B both have the same properties (apparently), and side by side at a high zoom rate don't seem all that different to the naked eye (apparently), then what makes one be 6x bigger in size than the other.
Logic says there should be some value in B that would be different / bigger than the same value in A to justify the final bigger size. As @LyricsLover mentioned, compression is probably a factor, but again, to the naked eye I can't make out a sizeable difference at high zoom, and there is no numeric value in the file properties for compression.
I did find a CLI program called [EXIFtool](https://exiftool.org/index.html) which does load (much) more info from A, B and C; I'll need to get familiar with it, and maybe I'll find a compression ratio or something in the files' info.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 13, 2024, 5:28pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/9 "2024-04-13T17:28:54Z")
Ithink that most of your questions are answered in the text that @LyricsLover has already linked.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 6:18pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/10 "2024-04-13T18:18:41Z")
It does help.
But when comparing a ~80kb image with an ~500kb one at a high zoom level, I was expecting the quality difference to be something like this (this is edited to exemplify my point of view)
but instead I'm getting this
(this is also edited, but the left side came from file A and the right side from B.
I was expecting a compressed, small sized image to be blurred\pixelated\of lesser quality when compared with a lossless image, when viewed at high zoom. Especially so when the compressed image is many times smaller (in kb) than the lossless one.
But if I hadn't (purposefully) slightly offset both halves to make the division obvious, it would be hard to tell them apart.
I was also expecting a compressed image to have different dpi or color depth than the original (as did B and C), but A and B have those properties with identical values; then the compression algorithm for A must cut out (many) details to substantially trim down the final size, without sacrificing quality, but still maintaining dpi and color depth.
Then something else must be discarded; as to _what_ exactly, I'll have to dig deeper into image formats to find out.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 6:31pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/11 "2024-04-13T18:31:22Z")
My end goal with this topic is this: if you had a music database that provided cover art in different formats (as iTunes apparently does), would you like them to be available as options in a WS script?
If so, which ones? What criteria would you use to say .gif is better than .bmp, or .svg is no different than .webp (for example)?
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [April 13, 2024, 7:05pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/12 "2024-04-13T19:05:20Z")
> [@rboss](#):
>
> If so, which ones? What criteria would you use to say .gif is better than .bmp, or .svg is no different than .webp (for example)?
If you are talking about pictures for music files in general and pictures to be embedded into music files in particular, then only two formats are relevant to comply with the ID3 standards: PNG and JPG
The ID3 standard says:
> Image format is the MIME type and subtype [MIME] for the image. In the event that the MIME media type name is omitted, "image/" will be implied. The "image/png" [PNG] or "image/jpeg" [JFIF] picture format should be used when interoperability is wanted.
My personal answer would be: Provide the biggest possible picture in PNG, if available.
If not available, provide the biggest possible JPG picture.
Every smaller resolution in PNG or JPG can be converted individually as needed.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 7:58pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/13 "2024-04-13T19:58:08Z")
I had not thought to consult the ID3 standard. This was really helpful.
I started this topic thinking that, since the only (apparent) difference between A and B was the file size, I could discard .png.
So, .jpg and .png both make the list. What about other formats?
I've already ruled out .jpeg because it's virtually the same as .jpg (and so would be redundant), and I'm trying to screen other formats based on their similarities (or lack thereof).
Or, just add all possible formats to a list, and let each person choose for themselves.
Thoughts?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 13, 2024, 8:07pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/14 "2024-04-13T20:07:08Z")
AFAIK jpegs sometimes describe jpgs in progressive format - which som players cannot display.
For best compatibility I would stick to png and jpg.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 13, 2024, 8:52pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/15 "2024-04-13T20:52:48Z")
I've changed 2Pac's album cover link to several image extensions and gotten 15 compatible hits so far.
I'm trying to put myself in Apple's shoes to understand the 'why' behind the support for so many formats.
But this exchange has been really helpful. Thank you @LyricsLover and @ohrenkino.
---
### Author:  [@AreDigg](https://community.mp3tag.de/u/AreDigg)
#### Post date: [April 14, 2024, 2:21am UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/16 "2024-04-14T02:21:38Z")
JPEG format is a five stage compression process where there are different options to how much image information you remove.
1. Colorspace conversion
2. Chroma subsampling
3. 8x8 frequency domain transformation
4. Quantization
5. Huffman coding
At step 2 lets you decide the ratio of chroma data (color) vs luminance (intensity) and step 4 how much high frequency data is to be removed. Usually however the software does not let you decide the sub sampling (typical 4-2-2 or 4-2-0) and some do give you the choice of ratio of frequency quantisation (typically in a value from 0 to 100 or percent).
The reverse process does not need to know the parameters so it is not easy to tell how much it was compressed from the source. But it is a very efficient method even when only slightly applied.
JPG is only an abbreviation of JPEG. The format is exactly the same. Like for audio and video there is some overlap when the discussion is about image format and container format. JPEG are usually stored in JFIF, but it is possible to use TIFF, EXIF, JIF and others.
Because graphic designers and their software loves TIFF, covers nowadays are originally in some lossless compression format using CMYK colors using TIFF. But because print of covers are becoming rare I think that the entire process will be entirely in RGB. They are then distributed in other formats more suitable for screens, like JPG or PNG.
Also because many artists do their own distribution they may decide to do the covers by themselves.
When you download covers from Apple servers they are converted to the format/compression and size/transform you ask for from their original as received by the distributor (record company usually) on the server side.
I don’t think there is too much use in the discussion of which format you should use. It all depends on your use case. It is analogous to if you should use MP3, AAC, WAV, etc for your music.
---
### Author:  [@Doug\_Mackie](https://community.mp3tag.de/u/Doug_Mackie)
#### Post date: [April 14, 2024, 10:15pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/17 "2024-04-14T22:15:53Z")
> [@AreDigg](#):
>
> I don’t think there is too much use in the discussion of which format you should use. It all depends on your use case.
I strongly agree. For example, if one of your players does not support PNG (and older car players may not), then much of the JPEG vs PNG discussion here is moot for your purposes. You can then focus on determining the image size and amount of JPEG compression that you find to be acceptable.
And, as @LyricsLover pointed out, overall file size can matter as well. Audio files with very large images may load more slowly than you would like when browsing from your car or smart phone. And those large files will consume more music storage space in your portable devices.
To me baseline JPEG files of 1000 x 1000 pixels look just fine and do not cause visible delays when browsing in my hardware players (car and Android phone).
Even if you don't use such a player yourself, you might want to loan or give a USB stick of your music to a friend , a relative, or a coworker. It's safe to assume that his or her player will support the baseline JPEG format.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [April 14, 2024, 10:41pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/18 "2024-04-14T22:41:47Z")
> [@LyricsLover](#):
>
> My personal answer would be: Provide the biggest possible picture in PNG, if available.
> [@Doug\_Mackie](#):
>
> To me baseline JPEG files of 1000 x 1000 pixels look just fine
Here are two different -but perfectly valid- opinions that illustrate my current conundrum. I'm not trying to determine what is\are the best format(s); that is more a matter of personal preference or particular need.
In terms of scripting workload, having a list of 2, 5, 10 or 15 formats is negligible.
But having a list of just 2 options might be considered too restrictive (_but would still be better than just one_); likewise, having a list of 15 options may become confusing.
That's why I'm studying up on image formats; to screen out the "redundant" ones.
---
### Author:  [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [April 15, 2024, 12:56am UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/19 "2024-04-15T00:56:56Z")
> [@rboss](#):
>
> I'm not trying to determine what is\are the best format(s); that is more a matter of personal preference or particular need.
It isn't so much about a preference for one format over another. It really boils down to what each user needs based on their choice of player(s). While some picture formats are "better" than others as far as lossless versus lossy goes, if the player can't use a particular format it really isn't better.
> [@AreDigg](#):
>
> I don’t think there is too much use in the discussion of which format you should use. It all depends on your use case. It is analogous to if you should use MP3, AAC, WAV, etc for your music.
This is a great comparable to consider what a user may prefer (or need).
Baseline jpg offers the widest range of compatibility but is lossy. The lossless png format is probably the next closest and potentially offers better resolution.
Others formats may work in some players and media managers but are outside of the id3 spec. I would caution against offering too many other format choices.
---
### Author:  [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [April 16, 2024, 1:21pm UTC](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392/20 "2024-04-16T13:21:17Z")
> [@MotleyG](#):
>
> This is a great comparable to consider what a user may prefer (or need).
Just to weigh in my personal experience: I've decided to settle on high resolution (1400px+) high quality (90+) baseline jpgs because these are the sweet spot of size, performance and compatibility for me.
I can't distinguish them from the original PNG unless I zoom in until I see individual pixels and they load much quicker, take up less space and are supported by literally every piece of software I used over the last 2 decades.
[Next page](https://community.mp3tag.de/t/differences-on-image-file-extension-for-cover-art/64392.md?page=2)