Size of pictures proportional to diameter of coin

According to guidelines pictures of coins need to be tightly cropped.

This is perfect to have optimal readability. what about an option to show pictures resized proportionally to the largest coin to have an idea of how they appear?

https://en.numista.com/catalogue/index.php?p=1&ru=5692&e=milan

A good idea. however, it would depend on knowing the correct dimensions of each coin, and then we would need to resize all images so that they are in proportion to each other. 

Hibernia

we would need to resize all images so that they are in proportion to each other. 

It’s quite easy to dynamically resize the images on display. You don’t actually have to resize the images on disk.

It would make smaller coins unreadable when mixed with larger ones. Your image example assumes only less than 50% difference in size.

From code perspective it would require recalculating image size in every search result.

take a look at these 3 coins

https://en.numista.com/catalogue/index.php?e=lombardy&r=&st=147&cat=y&im1=&im2=&ru=&ie=&ca=3&no=&v=&a=1848&dg=&i=&b=&m=&f=&t=&t2=&w=&mt=&u=&g=&c=&wi=&sw=

on numista

and on a paper catalogue

it seems to me that a crucial information is missing on numista and an option to dynamically resize pictures would make numista better than a paper catalogue even for this feature

by the way some real coins are indeed unreadable without a magnifying glass

Hello
The recommendation is that the coin fills the entire surface of the thumbnail image with a minimum of 360/360 without having to enlarge it
Photography  5. Take a photograph of sufficient size to allow the coin and its details to be seen; the larger the image, the better it will identify the coin.

smvdbrink

Hibernia

we would need to resize all images so that they are in proportion to each other. 

It’s quite easy to dynamically resize the images on display. You don’t actually have to resize the images on disk.

Probably. But the issue is the same - it would need to be done for every relevant image, separately.

Hibernia

smvdbrink

Hibernia

we would need to resize all images so that they are in proportion to each other. 

It’s quite easy to dynamically resize the images on display. You don’t actually have to resize the images on disk.

Probably. But the issue is the same - it would need to be done for every relevant image, separately.

No, that’s the point I’m trying to make. You don’t have to do that. All you have to do is write a few lines of code that trigger when an image renders. You don’t have to change the image itself to show it in different dimensions.

The code would need to be specific to each image.

Hibernia

The code would need to be specific to each image.

Honestly, don’t make these kind of comments if you don’t understand what you’re talking about…

Like already said it would be relatively easy you only need the value size/diameter and then relate all the objects to a reference.
Let's say the largest coin is 100 mm it is the reference 1.00 and a second coin with the diameter of 25 mm will be depicted at 0.25 size of normal.

It would be a nice little feature BUT it would be necessary for it to function properly that each and every picture is cropped perfectly and non round objects could be sill off under certain circumstances. For a little toy feature I don't think that this effort will be worth it and I also don't see much use for it in a search (more in some kind of gallery view).

The beauty of catalogs that do this (SCWC) is that the pictures are not only sized proportionally but at actual size (up to 55mm for SCWC).  This functionality obviously won't happen here so I don't think there's an advantage when trying to ID a coin.

Kind of sounds good, but just imagine having some series …  like US set with 1 dollar as biggest and then a dime you'd hardly see …

Might be nice to use on the series page or on a set page, but please don't do it in the general catalogue. Is you want to take size into account, just use the filter function for diameter.

BramVB

Kind of sounds good, but just imagine having some series …  like US set with 1 dollar as biggest and then a dime you'd hardly see ….

that‘s the goal. You show 10 coins, you click a button to dynamically see minuscules dimes next to huge dollars, you have an idea of proportions and you revert to pictures of all coins magnified to occupy as much space as possible 

smvdbrink

Hibernia

The code would need to be specific to each image.

Honestly, don’t make these kind of comments if you don’t understand what you’re talking about…

You are being far more insulting than you need to be in a friendly topic.
And you have not added anything that supports your point.

Hibernia

smvdbrink

Hibernia

The code would need to be specific to each image.

Honestly, don’t make these kind of comments if you don’t understand what you’re talking about…

You are being far more insulting than you need to be in a friendly topic.
And you have not added anything that supports your point.

I'm sorry if you felt insulted, that was not the purpose of my comment. For that I apologize. 

However, by repeating that every image needs to be resized separately, you show that you do not understand the technical implications of the original request. In response, I told you that images can be dynamically resized on display, which means that you render the image to a certain size, and that you don't have to change the image itself. In that regard, I think I made more of an effort to support my point than you did in this discussion. If that doesn't convince you, I'm a senior full-stack programmer. I know what I'm talking about.

It is possible to provide photos of the exact size of the coin, a 9mm photo for a 9mm coin, a 22mm photo for a 22mm coin
They would then be reproduced on the screen in proportion to the size of this screen to preserve their original real dimensions. Obviously by disabling the zoom so as not to distort them.
 

More seriously
In the principle of what is presented above, the series could be presented in .GIF format which preserves the proportions of each piece

The same goes for the catalog by grouping Obverse, Reverse and Slice

But we would have to review the whole catalog
On the other hand, we can consider animating the home page a little more with the random pieces
 

Just an idea

smvdbrink

Hibernia

smvdbrink

Hibernia

The code would need to be specific to each image.

Honestly, don’t make these kind of comments if you don’t understand what you’re talking about…

You are being far more insulting than you need to be in a friendly topic.
And you have not added anything that supports your point.

I'm sorry if you felt insulted, that was not the purpose of my comment. For that I apologize. 

 

However, by repeating that every image needs to be resized separately, you show that you do not understand the technical implications of the original request. In response, I told you that images can be dynamically resized on display, which means that you render the image to a certain size, and that you don't have to change the image itself. In that regard, I think I made more of an effort to support my point than you did in this discussion. If that doesn't convince you, I'm a senior full-stack programmer. I know what I'm talking about.

Yes.
And I am saying that you need to know to what degree each of the images would need to be rescaled to. 
Many images will be very different from each other. 
[I will use ‘rescaled’ instead of resized to describe the action of your script, for clarity, as I have used ‘rescaled’ previously to describe working on images.]

I am also scientifically educated, so let’s explore this with some more clarity.

I think you are also not seeing what I said. I am not disputing that the physical image itself would not need to be resized. I am pointing out that there are a vast amount of images which would need to be adjusted by your code so that they would be rescaled for the viewer. My turn to apologise for not being clear.

How would your script know what dimensions to rescale each image to in every case so that they would appear in correct proportions to each other? 
Explain to me how a single unaltered script could rescale three or more different images which are neither in proportion to each other nor to the original coins they are representations of.

Let’s take 3 Examples [with apologies for using three coins I am familiar with].
Example 1. A Hiberno norse Irish coin, phase 2, imaged by a cameraphone - this will be 72dpi, and be several hundred to a few thousand pixels wide. It would weigh in at around 3MB in decent quality compression. 
Example 2. An Irish coin, 1928 Half Crown, scanned by an auction house, at say, 1200dpi, and resized to make a nice big auction-friendly image, saved to 300dpi. This would also weigh in at about 2MB in high resolution. 
[Here, I am skipping the technical bits on how to scan something at 1200dpi, and resize it to 300dpi without altering the file size so that it is much bigger than it originally would be if printed out, or zoomed in on, as it is not relevant to the example].
Example 3. An English decimal 50p piece 1973, picture taken with a cameraphone, 72dpi, small file, say 200k.

In all cases, we know the dimensions of each original coin.

How would a single unaltered script rescale each of these there images to appear in correct proportions to each other?
My understanding of what you are implying from what you have written is that the same script would produce the correct relative scaling for all three coins without that script needing to be altered in any way, and thus the script could easily be used sitewide on all images.
I dispute this. I am saying that the script would need to be adjusted for many images.
Prove me wrong.

Note, I did not feel insulted, I just have a low tolerance for comments I consider insulting on forums. No worries. In explaining something, you ought to take into account that others might not have the same understanding of a subject that you do. On a forum such as ours, with so many people from many different backgrounds with many skillsets, anything technical should be explained from scratch, imho.

Numista already scales pictures or in the case of the search picture thumbnails rezises everything to max 135x135 px so the resolution doesn't matter (unless it's over Numista's size cap).

This 135 by 135 is the limit for this example, if we would apply it to search results … which I would not do but other limits could by applied elsewhere and the same fundamentals apply.

The largest size/diameter in a given sample of objects is determined and set as the norm (be it width/height or diameter), then everything else get's scaled proportionally.
Here is an example for two coins, the 100 mon is the largest and has a height that reaches the limit of 135 pixels and is set as the norm or 1.0. The height and width or diameter of the smaller coin now gets scaled accordingly to 25/49 or  51%.

@CREPOSUC my proposal is to dynamically and temporarily rescale images of a list of coins proportionally to the dimensions of the largest one, not to modify permanently all images in a 1:1 scale.

Considering the coins you are mentioning

N#3298

N#307050

N#10947

it seems to me that regardless of resolution and weight they appear all the same right now on your screen

this means, if I'm not wrong, that a single unaltered script rescales each of these images to appear of the same size.

once a filter applied to a catalogue search it would be possible to give the option to rescale images of result list proportionally to the dimensions of the largest one (or the smallest by the way) instead of setting  height to around 400 pixels as it's done right now

****Posted 2 seconds after @Idolenz message above 

@Idolenz I personally prefer pictures resized proportionally to the biggest coin as I don't like distortion created by magnifying small pictures

@cippirimerlo
Thanks. You answered the question I proposed to smvdbrink.
The script would draw on the data of the coin's known dimensions, already in the coin's entry, to rescale the image proportionately.

We still can't harmonize the existing catalog and yet we've been trying for almost 10 years.

Honestly, I think that a hi-res image is just what we need if it's shown as big as the Numista layout allows, why scale it?

The diameter is given on the coin page, so that's it, no?

What we lack is a photo laboratory equivalent to those of auction houses.
The coins will follow the same circuit.