# Request: Column for cover image dimensions

**URL:** https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243
**Category:** General Discussion
**Created:** [March 29, 2018, 4:06pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243 "2018-03-29T16:06:22Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 4:06pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/1 "2018-03-29T16:06:22Z")

</div>

I'd like to request the ability to show the dimensions of the cover image in a column.

Currently, if an MP3 file has a cover image embedded, Mp3tag will show the mime-type, resolution, size, and cover type in the left-hand sidebar next to the image itself.

I'd like to have a new information field for the cover resolution.

Mp3tag already has information fields for "cover\_mimetype", "cover\_size", and "cover\_type". So why not also have "cover\_resolution"? 🙂

This would be very useful when scanning a folder with lots of MP3s that have a range of different-resolution album covers.

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [March 29, 2018, 5:01pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/2 "2018-03-29T17:01:16Z")

</div>

With "resolution" you ask for something like "500x500"?  
Or x=500 and y=500?  
Or what exactly would you like to see as "cover\_resolution"?

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 29, 2018, 5:11pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/3 "2018-03-29T17:11:12Z")

</div>

The embedded picture cannot be manipulated by MP3tag, you would have to export it for that purpose.

Then: this topic itself is rather old, there is even an attempt for a workaround from 2008:

> [@Cover Dimensions - another approach](https://community.mp3tag.de/t/cover-dimensions-another-approach/6421):
>
> Cover Dimensions - another approach The following method creates some tag fields to hold cover image related data from up to ten stored covers. This method relies on a helper tool called identify.exe, taken from the powerful graphical tools suite made by ImageMagick, which can extract technical informations from a picture. (ImageMagick ftp://ftp.imagemagick.org/pub/ImageMagick/binaries/ 1. In Mp3tag grid view mark the tracks to be changed. 2. Run the actiongroup 'Get Cover Info Step 1 Exp…

One of the more recent threads around this topic:

> [@Display Album Art Size in Column in Main UI](https://community.mp3tag.de/t/display-album-art-size-in-column-in-main-ui/18806):
>
> I am replacing all low resolution album art cover embedded in mp3 files. Is it possible to have MP3Tag display the embedded album art cover dimensions (300x300) in a column (like, Title, Cover, Track, etc) so that I can easily identify mp3 files with low resolution album art. The ability to display art art dimension in a column will allow me to easily sort & filter to identify mp3 files with low res album art (300x300). Any tips are appreciated on how to do this, besides clicking on each albu…

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 5:25pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/4 "2018-03-29T17:25:33Z")

</div>

Hi @ohrenkino, per my request above, I'm not asking for the ability to **manipulate** the image in any way. I'm simply asking for the ability to **display** the image resolution.

As I noted, Mp3tag can already display the image mime-type, size (in kilobytes), and cover type, using the respective information fields that I mentioned. These fields are not used for manipulating the image, but just for displaying information **about** the image.

I'm merely making a feature request for a new info tag that displays the image resolution.

The resolution is already calculated by Mp3tag and shown in the left-hand sidebar, as you can see in this screenshot, where it says "1600x1600". That's the exact data that I'm asking to have available in a new info field:

![2018-03-29%2019_15_26](https://community.mp3tag.de/uploads/default/original/2X/8/8afd18b1bbfe3c81823d02c8599a1aa4d698ccc4.png)

If Mp3tag is able to calculate the resolution and display it there on the left, for the currently-selected file, then why is it not technically possible for it to include this exact same information in a new field?

The two older posts that you mentioned were asking if it is **currently** possible to do this, or if there is a workaround. However, I'm not asking if it is currently possible (I already know that it is not). I'm asking for this feature to be added in a future release of Mp3tag. That's the purpose of making a feature request, right?

Please kindly pass this on to the developers as a feature request! If I've posted this in the wrong area for a feature request, I'm happy to re-post it in the correct area of this forum. Or if there is another way I can officially make a feature request to the developers, please kindly let me know.

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 5:27pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/5 "2018-03-29T17:27:08Z")

</div>

@LyricsLover - just showing "500x500" - exactly as it already shows in the left-hand sidebar - would be fine for me. My point here is that the data is already calculated by Mp3tag, so why not allow it to be shown in a field too, just as the other image data (mime type, size etc) is already available in fields. It makes logical sense.

---

<div class="post-metadata">

### Author: ![Zerow](https://community.mp3tag.de/user_avatar/community.mp3tag.de/zerow/32/11379_2.png) [@Zerow](https://community.mp3tag.de/u/Zerow)
#### Post date: [March 29, 2018, 5:33pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/6 "2018-03-29T17:33:37Z")

</div>

And if implementing such feature: why not also give ability to display in Column only vertical size and only horizontal size?

So something like:

- cover\_resolution
- cover\_resolution\_horizontal
- cover\_resolution\_vertical

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 5:36pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/7 "2018-03-29T17:36:42Z")

</div>

...Let me illustrate my point a little further with another screenshot, showing the cover image and the four lines of image data in the left sidebar: mime-type, resolution, size, and cover type.

As you can see, it's possible to show mime-type, size, and cover type in respective columns in the main area of the window.

But it's not possible to show the resolution in a column. Why is that, when the resolution data is already there?

 ![2018-03-29%2019_32_30](https://community.mp3tag.de/uploads/default/original/2X/9/93f47fa25b46759f4db0b3db981d61695b08f814.png)

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 5:39pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/8 "2018-03-29T17:39:09Z")

</div>

> [@Zerow](#):
>
> And if implementing such feature: why not also give ability to display in Column only vertical size and only horizontal size?
> 
> So something like:
> 
> - cover\_resolution
> - cover\_resolution\_horizontal
> - cover\_resolution\_vertical

@Zerow - yes, I like that idea too! Why not all three?!

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 29, 2018, 6:40pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/9 "2018-03-29T18:40:56Z")

</div>

I just found a thread from 2006:

> [@Spalte Coverauflösung](https://community.mp3tag.de/t/spalte-coverauflosung/4010):
>
> Hier fehlt der Platzhalter, um auch diese Info rüber zu bringen. Der Explorer ist leider sau langsam und ich weiß nicht, ob ich dies schon mal so erfaßt oder irgendwo miterfaßt hatte. Es macht auf alle Fälle Sinn, um gezielt Cover zu überarbeiten, speziell nach Amazon und Co. Automatisierungen. Anzeige des 1. Bildes oder evtl. des mit der größten Auflösung , wobei dann die Frage ist, was die Auflösung ist (Anzahl Punkte versus Achsmaße) bzw. was wichtiger ist (Proportionen oder Pixe), um schne…

The answer in those days was: This will not be implemented as it would slow down MP3tag dramatically.

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 7:21pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/10 "2018-03-29T19:21:18Z")

</div>

Hi @ohrenkino,

First of all, that thread is 12 years old, and computers have come a long way since then. 😉

Second of all, the user in that thread is not asking for the same thing as I am. He writes, "Anzeige des 1. Bildes oder evtl. des mit der größten Auflösung" - so he is asking for the ability to display the image itself in a column. Obviously that would, indeed, slow down Mp3tag dramatically. But that's not what I'm asking for, of course! I'm just asking for the resolution of the image to be displayed, not the image itself.

I don't see my request having any burden on the speed of Mp3tag, for the following reasons:

1. If I open a folder in MP3tag containing over 1000 MP3s, I can click on each MP3 one by one and it shows the cover image (I mean the actul image itself) in the left sidebar instantly. Literally instantly, as I click from one song to the next. There is not even a fraction of a second of delay.

2. If Florian were to add a new "cover\_resolution" info field to Mp3tag, it would not be enabled in a column by default. Users would need to manually add it as a new column. Therefore, even if it would slow down Mp3tag a little bit (which I don't accept), it would be the user's choice to do this. As long as this new field is not added to a new column, there would be zero effect on the performance.

3. Mp3tag now has a new Library feature, which stores the tag info in a database for faster reading. Therefore, even if this new "cover\_resolution" field were to affect the loading times of Mp3tag (again, I don't believe it would), I can avoid this by using the Library feature. And again, this is my choice as the user. For users who don't want to use this new field, they aren't affected in any way.

Remember, we've come a long way since 2006 - we have much faster hard drives, and most of us are using SSDs now. But in any case, the post from 2006 was asking for something else, as I mentioned above. 🙂

Question: does @Florian read these feature requests too? I appreciate your comments and help with this, but how can I give a feature request to Florian as the developer, so he can consider it? You can see that there are other users here (commenting in this thread) who would also like to see this feature added.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 29, 2018, 7:30pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/11 "2018-03-29T19:30:57Z")

</div>

> [@Jezz](#):
>
> Question: does @Florian read these feature requests too? I appreciate your comments and help with this, but how can I give a feature request to Florian as the developer, so he can consider it? You can see that there are other users here (commenting in this thread) who would also like to see this feature added.

Yes, I think @Florian does read all this.  
And: I did not want to disqualify or dismiss your request in any way.  
I am not the one who implements such things or does not implement them.  
But as it is a good exercise to see if possibly somebody else already had an idea, i tried to point out the older threads. It would have been nice to revive an old thread just to proove that the idea is still worthwhile being followed as there is still demand for it.  
Such a proceeding also reduces the need to repeat arguments or it is easier to pick up old arguments and see if they are still valid.  
Nothing more.  
But as always with requests: until it is implemented you can use the workaround that I linked.  
It is never quite clear whether a request is published to overcome a certain problem and any way to solve it is welcome or whether teh request has only one particular implementation in the focus.

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 29, 2018, 7:53pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/12 "2018-03-29T19:53:04Z")

</div>

Thanks @ohrenkino. And I agree with what you're saying about older posts, to see if someone already asked for the same thing.

But from my own searching of older threads about this topic (including one that I actually [created myself in 2013](https://community.mp3tag.de/t/column-for-cover-dimensions/15241)), they are mostly people asking "is this currently possible" or "is there a workaround", and the answer, of course, was "no it's not", and "yes, here is some (complicated) workaround".

So I thought to create a new thread as a proper feature request, to specifically ask for this feature to be added, rather than just ask if it's currently possible. 😉

What would actually be a nice feature of this new community forum, if possible, is to have a dedicated "feature request" section, and also to allow the developer(s) to mark each feature request somehow as "Will do", "Might do", "Won't do" etc - so that the requester can know if there is any chance of it happening in the future, or not. 😉

(I should add: in my day job I'm a software Quality Assurance Engineer - mostly working with Jira...😉 )

---

<div class="post-metadata">

### Author: ![Etz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/etz/32/7648_2.png) [@Etz](https://community.mp3tag.de/u/Etz)
#### Post date: [March 30, 2018, 5:47pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/13 "2018-03-30T17:47:31Z")

</div>

> The answer in those days was: This will not be implemented as it would slow down MP3tag dramatically.

But, now we have library feature...so this data could be stored there and only inital loading would be "slow" this way.  
So basically @Florian could tie it to Library enabled/disabled if it affects performance too much. 😉

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 30, 2018, 6:00pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/14 "2018-03-30T18:00:18Z")

</div>

> [@Etz](#):
>
> But, now we have library feature...so this data could be stored there and only inital loading would be "slow" this way.  
> So basically @Florian could tie it to Library enabled/disabled if it affects performance too much. 😉

Even that should not be necessary, as I explained in my comment above! 😉

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [March 30, 2018, 6:21pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/15 "2018-03-30T18:21:52Z")

</div>

I would like to draw your attention to the fact that even now the properties already shown for embedded images describe only the "first" image - whatever that first image may look like and may be.  
For a thorough investigation it would still be necessary to export the embedded images to files with unique names and then see if there is anything left to be done.  
Right now it is not possible to define the order of embedded images (which is first, second, third and so on).  
And without export it is not possible to see of what type further embedded images are as only the first one is shown.  
So I get the impression that showing the dimensions is either not enough (as a lot of functions to handle embedded images properly are missing) or it is too much of an effort (as even with this additional shown property it would still be ncessary to go the way of exporting the images where you could see this property straightaway).

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [March 30, 2018, 6:42pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/16 "2018-03-30T18:42:14Z")

</div>

Hi @ohrenkino,

If I'm honest, it seems like you're over-complicating the feature request!! 😉 It's absolutely not necessary to export the images to files. It's also not necessary to try and determine which image is which, for the purpose of my request. I'm only - simply - requesting that the resolution of the currently-displayed image is available as a new Information Field, which can be added to a column. Nothing more! 🙂

Let me show you my screenshot again:

 ![2018-03-29%2019_32_30](https://community.mp3tag.de/uploads/default/original/2X/9/93f47fa25b46759f4db0b3db981d61695b08f814.png)

Here you can see, that there are already Information Fields for the mime-type, image size, and cover type. It's certainly not necessary for Mp3tag to export the images to files, in order to calculate those three values, is it? Mp3tag simply grabs the mime-type, size, and cover type values of the default image, which is already displayed in the sidebar. If the MP3 file has more than one image, it's too bad - Mp3tag will still only show the values from the default image.

Therefore, by extension, Mp3tag can also show the image resolution of that SAME image. No need to export to a file, or do fancy calculations or anything else. Just take the SAME image that is already used to show the mime-type, size, and cover type columns, and grab the resolution of that SAME image. Very, very simple - right?

Do you get what I mean?

I think the things you are proposing are going way beyond what I (and the other users in this thread) are hoping for. I just want to keep it nice and simple! (So yeah, maybe your extra wishes should belong in another thread?? 😉 )

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [April 6, 2018, 9:29am UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/19 "2018-04-06T09:29:23Z")

</div>

> [@Jezz](#):
>
> I'd like to have a new information field for the cover resolution.

I agree that this information field would be an improvement.  
I am constantly working on my music files with the intention to embed front-cover-art with a standard resolution of 800x800.  
At the moment I have to use third-party-software to filter for the resolution parallel to MP3Tag. In MP3Tag it is only possible to filter for the size of the embedded cover at the moment.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 9, 2018, 2:19pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/20 "2018-04-09T14:19:26Z")

</div>

After various internal experiments, I'm happy to have a solution that has no significant performance implications.

With [Mp3tag v2.87b](https://community.mp3tag.de/t/455), you can now use `%_cover_width%` and `%_cover_height%` to access the width and the height of the first embedded cover art.

An example column configuration that resembles the requested information field for cover resolution would be `[%_cover_width% x %_cover_height%]`

---

<div class="post-metadata">

### Author: ![Jezz](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/57b2e6/32.png) [@Jezz](https://community.mp3tag.de/u/Jezz)
#### Post date: [April 9, 2018, 2:39pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/21 "2018-04-09T14:39:29Z")

</div>

Wow thanks so much Florian! I just tested it on a large folder I have with over 1200 songs, and it works perfectly! 🙂 Really appreciate the quick implementation.

---

<div class="post-metadata">

### Author: ![Etz](https://community.mp3tag.de/user_avatar/community.mp3tag.de/etz/32/7648_2.png) [@Etz](https://community.mp3tag.de/u/Etz)
#### Post date: [April 9, 2018, 4:58pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/22 "2018-04-09T16:58:07Z")

</div>

@Florian, huge thank you...been waiting this feature for ages.

[Next page](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243.md?page=2)
