Image resizing

[Mark Hennessy]

Mike, the question was about whether a resizing algorithm (shift+S in PSP) would do a better job before or after the image had been cropped (which is doesn't - it makes no difference). You're making the much broader point that an image that has been cropped will be a smaller file size - no argument there, obviously.

Regarding dither, it's one of those subjects that we don't have time to cover properly - the time pressures are immense, and arguably it's an issue for the manufacturers to worry about. Very occasionally you come across bits of kit where fundamental mistakes are made, but I can't remember the last example at the moment.

So to get the basics across really quickly, I usually show this video:

https://www.youtube.com/watch?v=zWpWIQw7HWU

The visual explanation at the start makes a lot of sense to most people - it's far easier to start with visuals rather than audio specifically.

Having demonstrated why it's a good idea to deliberately add noise to a system - a counter-intuitive result, I'm the first to admit, we can then think in audio-specific terms...

For example, the noise does not have to be white noise. Why not filter the noise so there's not so much energy in the midrange, but more at the higher frequencies? Doing that makes the noise less audible, despite the fact its amplitude has not changed. So this increases the signal to noise ratio (remember that audio noise measurements are "weighted", to roughly mimic the human hearing response, so the improvement isn't just subjective - it can be measured too).

[Mark Hennessy]

Back to the original topic, I've just remembered that resize is an option within the default Windows image viewer - just right-click on the image and select it from the menu. Not quite as quick as the PowerToy if you have a batch to do, but easier than MS Paint. You can use their preset options or edit your own, as well as choose the JPEG compression ratio (which makes it better than Paint IMHO).

As well as that, there is an Edit option, which lets you crop and do a few other things. I used those a couple of months back on a machine that didn't have PSP, and they worked pretty well.

So even if MS Paint isn't installed (unlikely these days) and there's no PowerToys on the machine, the options are there by default. For simple cropping and resizing prior to uploading to a forum, for example, plus a little bit more, it's all there as part of the OS.

[ppppenguin]

The other thing I do routinely is orientate images correctly. All too often forums etc don't respect the metadata that gives the orientation of an image. I think GVR is OK but you often see sideways and even upside down pictures. I use Irfanview to correct this.

[Crackle]

cropped then resized
   

resized without cropping the image
   

which is better result.
Mike

[Crackle]

The first image is 300 x 373 pixels

The second image of the radio is 148 x 183 pixels
Mike

[Mark Hennessy]

Hi Mike,

I see from the email notification that your original reply was somewhat different to the edited version that we all see now. That's fair enough - we're all allowed to change our posts within the 20 minute edit window. But, just in case, I did just want to clarify that I did not misunderstand what you said originally in post #20, and that you were perfectly clear. It's just that - as I said - you were making a much wider point than mine. And please note that I agreed with your wider point.

Of course I understand that if you crop unwanted parts of the picture, what remains will make better use of the prevailing file size and/or pixel count limits. I have been putting images online since the 1990s when we all had to struggle with dial-up connections, and have some experience in optimising images to get the best results for the fewest bytes. I am frequently complimented about the quality of the images on my website, and for a while I had some basic advice about image creation on my website because I was asked so many questions about it:

https://web.archive.org/web/200410100103.../about.htm

(Ironically given this topic, they've cached an older logo that is being stretched to the size of the new one!)

There's no point going over it all again - it's all here in the thread - but just to clarify a couple of points:

1. "Resize" means change pixel size.

2. This is not the same as file size - which depends on pixel count, and how much compression the file format uses. For a BMP file with no compression, then yes, there is a simple relationship between pixel count and file size. But for a JPG, it is a product of the pixel count and compression ratio. You can change the compression ratio in most decent graphics programs.

(For simplicity I've ignored colour depth - bits per pixel)

These 4 images all have the same pixel size (2000 by 1500), but the file sizes are 987KB, 389KB, 223KB and 96KB.

               

It's worth saying that the same image saved as an uncompressed BMP is 8.58MB! As has been said, JPEG is impressive!

This version of the image has fewer pixels (1000 by 750), but the file size is 288KB. That's bigger than image 3 and 4 above! It uses the same JPEG compression ratio as the first image above. So for anyone who is still in doubt, this clearly demonstrates that pixel size and file size are not the same thing.

   

Jeffrey did make this point in his penultimate paragraph of post #15. Despite picking him up on the "crop before resize" point, I've never doubted his knowledge in this area - we all know the work he's done with video. Video compression, of course, is the classic example of needing to reduce file sizes (or bit rates) while keeping the pixel count the same.

Purely out of interest, I tried reducing the colour depth of the original 2000 by 1500 image to 256 colours, then saved as a GIF. This uses much less sophisticated compression technology, so despite the saving from only using 8 bits per pixel, the final file was 2.25MB - too much to upload here. So I went back to the original and resized it to 1000 by 750, and reduced the colour depth and saved another .GIF. This was just shy of 600KB. The artefacts from the colour reduction are there, but it's not too bad overall. But definitely best to use JPEG for photos, both in terms of image quality and file size. But as we know, JPEG is a no-no for line diagrams.

   

A final work about resizing. When you change the number of pixels, it's not a straightforward process - just have a look at the Wikipedia article to get an idea of what's involved. And back in the 1990s, some graphics programs didn't do a brilliant job. Indeed, nor did web browsers until some time after this, which is why it was important to make sure that the size properties in the IMG tags matched the actual pixel size of the image (much less of an issue today). So given that implementations of image resizing algorithms were once necessarily less than perfect, that might have fed into workflow decisions like "crop before resize" back in the day, and that's where I thought Jeffrey was coming from in post #15. But that's not been an issue in the last 2 decades, which is why I said it doesn't matter. But obviously, "crop before JPEG encode" is what I'd hope anyone would do by default. Get all the manipulation done on the uncompressed image held in RAM, then only save as a JPEG file right at the end.

Although image resizing is a mature science, it's interesting to note the difference in quality in HD to SD downscalers - that's one of the practical exercises we get people to do at work. Of course, they're having to work in real time, unlike Paint Shop Pro

[Crackle]

You're making the much broader point that an image that has been cropped will be a smaller file size - no argument there, obviously.

Sorry but with respect Mark it was you in post #21 who said I was talking about a broader point (file size). I never mentioned file size in my post #20 neither did I intend to.
All I wanted to do was correct your statement which was "As I say, I'm not aware of any reason why the order matters between resize and crop - it's a matter of "operator preference". "
I believe I managed what I set out to do.

This thread is titled Image resizing, not reducing image file size.
And of course we dont want to confuse the issue by including image view size or print size.

Yes of course file size is a function of pixel count and any compression that may have been applied.
Mike

[Mark Hennessy]

I fear we're going around in circles. I'll give it one more go - but I'm anxious not to offend or fall out with anyone. In fact, that's the very reason I'm trying one more time. It would be far easier to simply tell you you're wrong and be done with it. But I don't think you're wrong. I do, however, think that we're talking about different things for some reason. And because we're talking about two different things, it is entirely possible that we're both right! And we are, whether you see it or not

You are talking about the entire process of taking a raw image and preparing it for the web.

This will, of course, involve many processes that include cropping and resizing (changing the pixel size). So once all those are done, you will then save it as a JPEG. As I say, no argument from me - it's exactly what I and many others will likely do, and as I showed you earlier, I had that advice on my website since 2004 (for about a decade IIRC).

I hope we can agree on that. I've repeatedly said that I don't dispute it, both here and in previous posts.

-----

Let's turn to my statement: "As I say, I'm not aware of any reason why the order matters between resize and crop - it's a matter of "operator preference"."

The key thing here is this: these 2 steps are just a part of the entire process outlined above. Only 2 steps out of what might be many if you have to do colour correction, image rotation, image stitching, sharpening, noise reduction, manual editing, etc, etc.

As I say, you broadened out the discussion to include the entire process, but again, I'm just talking about 2 of those steps.

Above you said "broader point (file size)". But the broader point is not file size - the broader point is the whole process of preparing an image for the web, as explained above. Perhaps now we've found the point that you've misunderstood? I feel optimistic that this might be the case, as if so, that moves us forwards - and I can apologise for not being clearer earlier.

When you are preparing an image for the web, you will - as I say above - crop and resize during the "session". Most likely I'll crop, then resize, as I normally want my images to be a specific width* to fit the width of the main content column on my website. But in terms of final image quality, it doesn't matter which way around you perform those sub-steps. The image-resizing algorithm specifically (what happens when you do Image -> Resize (of Shift+S) in Paint Shop Pro**) does not care if it's working with the original massive "raw" image (as opened straight from the file the camera or scanner made) or a cropped, more manageable version of the same.

* That's an example of "operator preference. As the operator of PSP, I might want the image to be a certain width, so that's why I'd crop then resize. It has no effect on the overall image quality, but it does ensure that it ends up being exactly the width I want. But there might be other scenarios where the aspect ratio matters more than the actual dimensions - in that case I might be tempted to resize (to make the image more manageable in PSP, and also closer to the approximate final size I'm after), then I'll do the crop, keeping an eye on the aspect ratio numbers in the status bar as I make the selection, and appreciating that I can have the whole pre-cropped image on the screen at 1:1 zoom level so my crop can be pixel-perfect. These are just examples - every operator will have their preferred workflows.

** PSP V6 and V7 - I haven't seen V8 in over a decade, so can't remember if it's the same.

So the end result is the same, whether you make the crop, then resize - or resize, then crop. When you File -> Save As, that's when the JPEG encoding algorithm runs to take the image held in RAM (in totally uncompressed form) and turns it into the JPEG which obviously will have a much smaller file size. So whether you crop before resize - or the other way around - is completely up to the user, and doesn't affect the end picture quality.

Yes, you're making the point that if you don't crop, then the area of interest is smaller (and of less quality) than it would otherwise be. Yes - that's utterly obvious, and I have never disputed that (nor did I need it pointed out). But if you are planning to crop and resize an image before making it into a new JPEG file, it really doesn't matter whether you crop before or after you resize - they will look pretty much identical and have almost identical file sizes. That is simply a fact. Honestly, I'm not sure how else I can explain it.

Again, if a given image is going to be cropped and resized before posting to the web, it doesn't matter which way round you do it in terms of image quality. And cropping and resizing are just 2 out of the potentially many steps you might perform before saving the final JPEG.

When it comes to preparing images for the web, we both have long-standing websites (21 years in my case), and we both have high quality images on them. Therefore, neither of us lacks understanding or experience when it comes to preparing images for web use. At a stretch, it's perhaps just about possible I have have slightly more understanding of the inner workings of a a graphics program - that'll be because of my knowledge of television, though I do my very best to stay away from video as I'm an audio person. But having said that, I really don't want to claim any knowledge of these inner workings - but I have many colleagues who could help me if I ever needed to know. Likewise, we all know (and I have already acknowledged) that Jeffrey will have this sort of in-depth knowledge too, as he knows far more about video than I. Indeed, as I explained in my last post, I thought that's where he was coming from - thinking that the image resizing algorithm might perform better with the smaller cropped image - and back in the 1990s, that might well have been the case, but when I said "I'm not aware of any reason why the order matters between resize and crop", I was making the point that problems with image resizing algorithms were historic problems that had gone away by the time of PSP6. But as he changed to "crop before compress" in post #17, it's clear that "crop before resize" in post #15 was just sloppy language or a brain fart. No problem - we'd moved on from that before you joined the thread and told me I was making a wrong statement.

So this is not a technical argument as such - as I say, I believe we're both right. Instead, it's a communication problem. I could accept that I'm not being clear enough. But I'm also aware that I'm writing long posts, and I do wonder if they are being read properly? My fault for not being more concise, perhaps? Well yes, but I hate that social media has reduced internet communication to short sentences at best, and find it frustrating that forums appear to be going the same way. Perhaps I'm a bit nostalgic for the 1990s, when text was almost all we had... But perhaps I should just restrict my lengthy ramblings to my website, and give up trying to post on forums? After all, I've almost entirely given up posting on social media... But if I don't feel free to contribute to this forum without causing confusion by writing in my preferred style, why on earth am I still paying the bills?

I'll repeat what I said at the start. This is an attempt to help. I hope I haven't offended or upset anyone. And if this post hasn't helped, tell me what I need to do...

I hope this is received in the constructive and conciliatory spirit in which it is offered - life is too short for fighting and point scoring on an internet forum. We're both right, for goodness' sake!

Mark

[Mark Hennessy]

Finally, just to prove that it doesn't matter whether you crop before resize, or resize before crop, here are two images of the same Philips 'scope I posted earlier.

I opened the original image from the camera and resized to about 75% of the original size, then took a crop. Saved that as a file called - imaginatively - "Philips - resized then cropped.jpg".

   

Then I re-opened the original file from the camera and took a crop that closely (if not 100% perfectly) matched the first image. Then I resized the image so the width was about the same as the first image. This is called "Philips - cropped then resized.jpg".

   

The two files are the same file size, give or take a few kB. In terms of pixel sizes, they are pretty close too - the first is 1192 by 878, and the second is 1200 by 879. Obviously I rounded when resizing the second one, but they are close enough for the purposes of this discussion.

So, it doesn't matter if you crop before resizing, or resize before cropping. It's operator preference

Does this help?

[Crackle]

I think I have realised why Mark and I have disagreed on his statement about cropping and resizing.

It appears Mark resizes to a percentage and then crops the image. I agree that method will not matter if it is cropped and then resized or resized and then cropped.
But there are drawbacks in using this method for an photo image.
1. You are not necessarily going to know the final size of the image you will end up with after resizing and cropping.
2. It may be possible that even after your resizing, and cropping to exclude unwanted background in the image, that the final pixel size and file size are too large for the constraints of the web page and further processes are required meaning more actions and experimentation is required.

My method for photos.
1. I always crop the unwanted background out of a photo.
2. Then resize the image to the pixel width that suits the website where you are uploading it to.
3. Save to your hard disc with a new file name. (leaving the original image as is, in case you want to go back to it.)
3A. If it is still too large a file size when I save it, then I adjust the compression of the JPG file to reduce the file size. This may or may not be possible depending on the program you are using.
There are many other processes that can be done to make improvements, but they will depend on the tools available in the image editing program you are using.

After uploading over 4000 photos and 1500 schematic pages to the Radio Museum and probably double those quantities to my own website I have found the above 4 easy steps to be the minimum required to present the photo you have taken.

My method for scanned schematics is different.
The constraints of the Radio Museum and most forums are quite precise and can be very tight and quite frustrating when an upload fails. This forum is quite generous in its pixel count and file size limits.
But sometimes it may be better to consider scanning and uploading the schematic as a PDF file. The limits for these are often more flexible.

For details on the various file sizes accepted by this forum see http://www.golbornevintageradio.co.uk/fo...p?tid=4835
However I am not sure if there are any max pixel width limitations.

I wonder if Mark can confirm if there any max pixel widths for any of the common image file types.

Mike