As described in another post, I was looking for ways to archive thousands of unimportant images in a space-saving way, without simply discarding them. Space was a concern because I was trying to decide whether it would work to combine all these JPGs into a single PDF, and unfortunately the PDF-creation software was crashing because the images were too many, too large, and/or too complex.
This post explores the use of IrfanView and FastStone Photo Resizer to reduce the size of those JPGs without losing quality. Briefly, the following discussion comes around to the conclusion that, for a set of 5,590 JPGs filling 5.6GB of disk space, FastStone was effective in achieving an 80% reduction in total file size (after treatment: ___GB) without any appreciable loss of quality. This size reduction was possible through setting FastStone to JPG quality setting 90, checking the option to “Use JPEG quality from the original file if possible,” and using other settings (mostly defaults) described below.
Comparing IrfanView Against FastStone
My starting question was whether I could get decent results by downsizing the larger images to be no more than 1280 pixels wide. I had previously used IrfanView to achieve that sort of resizing, but now I wanted to compare IrfanView against another resizing program.
I wasn’t sure which other tool to use for photo resizing. A search led to a Raymond list naming, among others, RIOT (Radical Image Optimization Tool) (4.4 stars from 63 raters at Softpedia) and FastStone Photo Resizer (4.4 stars from 32 raters at Softpedia). AlternativeTo named XnConvert as another possibility, but that appeared to be an XnView project, the latter controversial for allegedly stealing from IrfanView. I was interested in comparing IrfanView against an entirely different tool, and anyway AlternativeTo users vastly preferred RIOT (with strong warnings to be careful not to install its optional adware during installation). I was inclined to try RIOT. But when I tried to download it, my AVG antivirus software warned me (consistent with some older notices) that it contained MalSign.OpenCandy.7AF. I opted to let AVG remove it. (Later, Softpedia’s reply to my inquiry assured me that this version had been removed from the site, and that the newer beta version was virus-free.)
As indicated in the other post, I was working with a set of 5,590 JPGs. Some were larger than 1280 pixels wide; some were smaller. I made two duplicate copy sets from the originals. I used IrfanView to resize one set, and I decided to try FastStone (portable version 3.7) to resize the other. In IrfanView’s settings, I specified 1280 as the maximum width (checking the box that said, “Don’t enlarge smaller images”), with no height specification, and I also clicked “Use Resample function (better quality).” In FastStone, I clicked the Settings button, set the quality slider to 100 and changed Color Subsampling to Disabled, but otherwise kept its defaults. Back in FastStone’s main screen, it was probably just my oversight, but I was not sure the Advanced Settings button was visible when I first ran the program. Within Advanced Settings > Resize tab > check Resize box, I chose Resize Based on One Side > Width = exactly 1280. I also selected “Do not resize if image is already smaller than requested size” and “If image not resized, copy original file to output folder.” Then I clicked Convert.
The IrfanView conversion ran much more quickly than the FastStone conversion, though I supposed that could be due to higher priority demand on the system, as distinct from superior (or perhaps inferior) program design. Neither FastStone nor IrfanView reported any problems with the resizing operation.
So now I had two sets of JPGs, resized from the original files, both supposedly set to produce JPGs of width 1280 — or less, for those that were already less than 1280. I made copies of these two sets, and ran DoubleKiller to detect exact duplicates. Out of 5,590 files, there were no exact duplicates. It appeared the two programs had used rather divergent methods to achieve the resizing.
I prepared a spreadsheet comparing file sizes, as reported in directory listings from the two folders. The spreadsheet indicated that, for 52% of the 5,590 files, the FastStone 1280s were larger, while the IrfanView 1280s were larger for the remaining 48%. The differences tended to be substantial: on average, the difference between the larger and smaller 1280 was 75% of the smaller file’s size. An example coming close to that 75% figure: for one file, the IrfanView 1280 was 309,868 bytes, while the FastStone 1280 was only 178,590 bytes — 131,278 bytes smaller, where 131,278 was 74% of 178,590.
As described in another post, I had renamed the original JPGs by appending their original resolutions to their filenames. Now, in the spreadsheet, I extracted the original resolutions of the 5,539 files whose names still held that information. (I had removed that information from the other filenames, typically to keep them from being too long.) Sorting the spreadsheet by original width, I saw the source of the difference between FastStone and IrfanView resizing. In almost every case, the IrfanView 1280 was larger whenever the original JPG’s width was 1280 or less (six exceptions, and it was close even in those cases), and the FastStone 1280 was larger whenever the original width was more than 1280 (no exceptions).
I tried to see whether the differences between FastStone and IrfanView resizing yielded visible differences in the resulting files. First, I looked at those pairs with the largest number of bytes of difference in size. The biggest absolute difference was between an IrfanView 1280 of about 2.2MB and the corresponding FastStone 1280 of about 3.7MB (original resolution 1944×2592, 5MP). For those two images of a gravestone, I could see only the very slightest differences in how a few specific blades of grass were rendered. Even that was apparent only when the image was magnified to screen width (1920 pixels), and I could not say definitively which program had done the better job with those blades of grass. The other exception was the camera’s date stamp on the image: for that, the red was more vivid, and closer to the original, in the FastStone 1280. When I compared the 1280s to the original, I saw that both 1280s yielded slightly less sharpness for both the grass and the gravestone, and now I changed my mind: if my concern were quality at any price, I would have very slightly favored the FastStone 1280. But since I was more concerned with producing a smaller file, I was most influenced by the fact that the FastStone 1280 was much larger than that of the original, which (at 2,272KB) was close to the size of the IrfanView 1280.
I tried again, with the pair of 1280s displaying the next largest difference in filesize. This was an image of a statue — with, again, a difference of roughly 1.5MB in filesize, between the two 1280s and, again, an original about 10% larger than the IrfanView 1280 and much smaller than the FastStone 1280 (original resolution 1944×2592, 5MP). Here, again — short of spending 15 minutes looking desperately for differences, which in this case I did not bother to do — I really could not tell which was the original and which was which among the 1280-pixel copies, even when viewed at screen width. In this case I had a stronger feeling that the FastStone was simply producing inflated resizings.
I switched to the question of relative rather than absolute difference in filesize. Here, the biggest contrast was between a FastStone 1280 of 64KB and an IrfanView 1280 of 209KB (226% larger) (original resolution 1280×960, 1.2MP). In this case, it was IrfanView that had inflated the file beyond the original size of 64KB. This photo was actually of even worse quality than its specifications suggest: it was basically a blurry, bad shot, with no discernible differences among the two 1280s and the original. I tried again with another of similar specs. The same observations applied here. I skipped down the list to a pair with a 140% difference (again, IrfanView larger). Still no go: blurry. Likewise in several other samples, even down to where the IrfanView was only 50% larger than the FastStone 1280. It seemed that IrfanView did not do well in resizing blurry, lower-resolution photos. Even in a pair with slight blurring and only 20% difference in size (original 758×996, 0.8MP, size 252KB for the original and FastStone, 303KB for the IrfanView), viewed at full screen width, I could see little to no difference between original and copies, and no justification for IrfanView’s extra investment of disk space.
As the dimensions suggest, all of these extreme cases (that is, all of the ones I viewed manually) featured a photo that was taller than it was wide. I was not sure what to make of that. What did seem clear was that, for purposes of producing 1280-pixel-wide resizings of the original images, FastStone wasted disk space when the original width was higher than 1280, and IrfanView likewise when original width was 1280 or lower.
I was not sure how robust those findings were. It was possible that changing a setting or trying for a different image width, in either of the programs, would have produced a different outcome. There could likewise be different outcomes if I had been working with a different set of photos, of different quality or featuring different subject matter. But at present, at least for these photos, if I wanted to eliminate waste from the sizes of the images, it did seem I should use FastStone to resize the lower-resolution images and IrfanView to resize the higher-resolution images, pending experimentation with other programs that might yield even better results.
Later, it occurred to me to run a DoubleKiller comparison of the original JPGs against the resized 1280-pixel copies (as distinct from the earlier comparison of the two resized folders). This comparison underscored the difference between IrfanView and FastStone when dealing with smaller JPGs especially. IrfanView left no original file unchanged, possibly because I had checked its option to “Use Resample function,” whereas 2,705 of the 5,590 original JPGs had identical copies in the FastStone resized folder, presumably because FastStone did not attempt to change files that did not need to be resized because they were already at or below the 1280-pixel width.
There remained the question of how I could divide a large number of images according to their width, so as to prepare the different sets of originals that I would want FastStone or IrfanView to resize. In this case, as described in another post, I had used ExifTool to get resolution, filesize, and other information from these thousands of files by running a simple command and then parsing the results in a spreadsheet, using techniques like those detailed in a different post. Similarly, I could use the present spreadsheet to produce batch commands that would move large numbers of files to specified folders.
It might not always be convenient to use ExifTool, develop a spreadsheet, and work up a batch file, in order to separate out the files whose resizing might fare better in IrfanView than FastStone, or vice versa. I wondered whether filesize could serve as a proxy for those more refined calculations. I noticed, for one thing, that (as one would expect) the files that FastStone had had the good sense to leave unchanged — the ones that IrfanView tinkered with, and wound up inflating — were all relatively small. The largest was 705KB. Similarly, the spreadsheet indicated that the FastStone 1280s were overwhelmingly likely to be smaller than the IrfanView 1280s, up to a file size of 400KB, but then suddenly became mostly larger than the IrfanView 1280s above 525KB. Above 600KB, IrfanView 1280s were almost always smaller. So, in a pinch, I could run both resizers, and just keep the FastStone 1280s smaller than 525KB, and the IrfanView 1280s larger than 525KB, and that might give me a rough version of the most efficient resizing solution.
Results; Another Try
In this case, I used the spreadsheet to separate the originals by width, used FastStone to resize those at or below 1280 pixels and IrfanView to resize the larger ones, and then combined the resulting 1280s back into a single output folder. The ones treated by FastStone should have been left unchanged, because they were already the right width. FastStone’s statement of results largely confirmed that. A DoubleKiller comparison of the originals against a copy of the resulting 1280s, deleting the identical duplicates, highlighted the exceptions: five larger JPGs, lacking resolution information in their filanames, had been erroneously sorted into the FastStone folder, where they were shrunk dramatically.
I combined the 1280-pixel (or narrower) JPGs produced by IrfanView and FastStone into one folder. These 5,590 JPGs had a total size on disk of 2.8GB, representing a 50% shrinkage from the 5.6GB set of originals. Note, again, that this amounted to a combination of (a) no change to files with width of up to 1280 pixels and (b) IrfanView resizing of originals larger than 1280 width to the 1280 target size.
FastStone was superior to IrfanView, at least with the settings I was using, in the sense that it knew enough to leave the smaller JPGs alone. The problem with FastStone was that it bloated the larger JPGs. I realized now, however, that I might have inadvertently caused that, by failing to select FastStone’s option to “Use JPEG quality from the original file if possible.” I decided to run FastStone on a copy of the full set of 5,590 original JPGs, with that box checked. The difference was dramatic. The output folder required only 1.6GB, for a 71% reduction from the 5.6GB original set.
But what would such dramatic shrinkage do to image quality? Spot checks suggested very little visible change, at a viewing width of 1920 pixels. Using a spreadsheet, I examined instances of the greatest before-and-after change in filesize. The spreadsheet identified 715 files that FastStone had reduced in size by at least 90%. Most of these were originally larger than 1MB. Collectively, these files accounted for about 1.2GB of the set’s size reduction. I looked at the six files that had been reduced the most: 94% each. Four of the six originals were junk: blurry, barely recognizable, random outdoor scenes that should have been discarded. The other two showed people. In all six cases, there was essentially no visible loss of quality. As before, I verified that FastStone did not alter JPGs with widths no greater than 1280.
It appeared, in short, that FastStone was superior to IrfanView for file resizing. As long as I clicked the FastStone box offering to “Use JPEG quality from the original file if possible,” it tentatively appeared that I would not be forcing FastStone to inflate the sizes of JPGs that had been saved at lower quality levels, by insisting that they be saved at the maximum quality setting.
As I thought about the preceding paragraph, I began to have an uncomfortable feeling that I might not entirely understand JPEG compression, or FastStone’s implementation thereof.
The first unknown was, what quality level should I use? Like FastStone and IrfanView, image editing and resizing tools generally seemed to include an option to specify the quality level of JPEG files, on a scale of 1 to 100. I had been going with 100 as the default. I realized that was probably excessive — that, especially for these photos that I was archiving because I expected to have little further need for them, a lower quality level might be appropriate. But how much lower?
A search led to a variety of opinions. Probably the best summary of those opinions was that the choice of JPEG quality level depended on the purpose to which the images would be put. I didn’t expect to put these images to any purpose, but I did want to keep them in reasonable condition against possible future needs.
It was tempting to refer to the JPEG quality level as a percentage (e.g., 50%), but apparently that would be incorrect. Atwood offered a chart indicating that, at least for one photo he was examining in detail, a drop from 100 to 90 would reduce file size by about 65%; a drop from 90 to 70 would eliminate another 40% or so; and the gains from further trimming would continue to diminish from there. A participant in one discussion suggested that the size-quality tradeoff was typically unacceptable below 90, and that artifacts would typically become apparent below 75. For a different photo, Fulton noted that even JPEG = 100 is lossy, and that deterioration in quality becomes apparent at 80. There seemed to be a rough consensus that quality below 50 would be visibly inferior for most purposes, but Ekin contended that, for some purposes (e.g., webpages), a setting of 50-60 could be sufficient.
The situation became more confusing as I considered some bits of insight from a StackOverflow discussion. One was that the JPG file did not contain a JPEG quality level counter, or a memory of how great it used to be. If I reduced a file by saving it at level 90, and then did the same thing again and again, it wouldn’t just get to level 90 on the first round, and then remain unchanged forever after. Instead, I would lose quality at each one of those level-90 saves. There might not seem to be much loss of quality in any one step, but eventually the difference from the original would be noticeable.
The StackOverflow discussion added to or muddied that line of thought with an additional insight:
Some programs allow user to set quality level 0-100. But there is no common defenition of this number. The image made with Photoshop with 60% quality takes 46 KB, while the image made with GIMP takes only 26 KB.
That last sentence apparently drew from Patrakov’s article titled, “JPEG Quality Is a Meaningless Number,” offering a detailed comparison of the two programs’ treatment of a particular image. So now I was not sure what to make of the third insight from that StackOverflow discussion, which was that I could use ImageMagick to obtain a JPG’s quality level. I downloaded and installed the current version (7.0.4, Windows x64), accepting the default option of adding ImageMagick to the system path, and tried using the recommended command:
identify -format '%Q' "D:\Path Name\File Name.jpg"
but I got an error that at least 1 2 3 others also got. Not that it necessarily mattered: if I understood the situation correctly, a working ImageMagick installation would apparently just report the most recent JPEG change. So if I saved a copy of a JPG at level 10, and then saved a copy of that copy at level 90, apparently the last file would be reported as a JPEG = 90. And I was not even sure that was correct, because another remark in that same discussion said, “The quality number (0-100) of an image is saved at is not stored in the image header.”
By now, I really had no idea what to make of the FastStone option (“Use JPEG quality from the original file if possible”). Was it saying that the output would have the same quality level (e.g., 85, meaning further loss of detail) as that indicated in the source JPG? Or was it saying that it would try to preserve the actual quality of the original (meaning, in effect, a JPG setting of 100)? It couldn’t be the latter: I had just seen that checking the box produced a substantial reduction in file size. But why would anyone check the box otherwise? The previous owner of the original JPG might have found that s/he could get away with a quality level of 60; but saving a copy of that copy with, again, quality = 60 (i.e., another round of severe compression) would surely produce junk. That was not what seemed to be happening with my output JPGs.
I decided to try resizing these JPGs while simultaneously reducing their quality level. I ran FastStone again, with settings as before, resizing the originals to a width of 1280 at quality level 90. The resulting file set required about 1.6GB, same as the previous attempt. This seemed to say that the originals were already set to a quality level at or below 90, such that my decision to lower the level from 100 to 90 mattered, if at all, only to a few files whose levels had been set above 90. Neither FastStone’s homepage nor its built-in help offered any clarification. Several webpages (e.g., BlogIT) offered a different perspective: they said that the “Use JPEG quality from the original file if possible” option would actually be a hindrance if the user wanted to reduce file size below the level specified in the original JPG. So if the JPG quality level was set at 85 in each of these originals, then checking the box and specifying 90 would allow FastStone to compress them to 85; but checking the box and specifying 80 would prevent FastStone from compressing them below 85.
There were some unknowns about JPEG compression generally, and about JPEG compression within FastStone Photo Resizer specifically. I decided to notify FastStone of these unknowns, in case they wanted to help me clarify the preceding section.
The working conclusion seemed to be that, in any case, it would be advisable to keep doing spot checks, keep looking for other solutions, and continue gaining experience. On this particular set of JPGs, my spot checks seemed to confirm that using FastStone at quality = 90, specifying a width of 1280 and checking the option to “Use JPEG quality from the original file if possible,” had given me a dramatic reduction in file size with virtually no apparent loss of image quality. For purposes of my project, it appeared that I had arrived at a solution to the problem of having too many large files to combine in a single PDF.