Jpeg photos here imported from an iPhone 4 can be resized by XnView, by '100%', becoming files of half their former size - without any apparent visual or dimensional changes.
These photos originate from iOS vn 6.1.3 in an iPhone 4; they are imported via Windows Live Photo Gallery 2012 and manipulated by Resize (by both Resize, Shift+S and Batch Processing, Ctrl+U) in XnView vn 2.22.
I have a test set of 25 files whose original aggregate size is 42,725 k, resized in batch by 100% to 22,997 k.
Each photo of a pair carries the same number of pixels (H & W) and the same colour depth, yet 90% of the time, one of the pair is about half the size of the other. And each looks the same as the other.
This seems anomalous. iPhone photos appear to be excessively 'overweight'.
Can anyone explain the apparent contradiction?
Phred
5th Oct, 2014
iPhone Photos Appear To Be Overweight
Moderators: XnTriq, helmut, xnview
iPhone Photos Appear To Be Overweight
Regards, PhredE
Willing donor, if only a 'donor token' were supplied in return, putting 'Phred's XnView' or '$D', '$Dd', '$dd' (depending on size) or 'Donor Version' in the title bar. (See Wiztree for partial solution.)
And a local Help file
Willing donor, if only a 'donor token' were supplied in return, putting 'Phred's XnView' or '$D', '$Dd', '$dd' (depending on size) or 'Donor Version' in the title bar. (See Wiztree for partial solution.)
And a local Help file
Re: iPhone Photos Appear To Be Overweight
The XnView Image > Resize function provides a means of of changing the pixel dimensions of an image, either increasing or decreasing the dimensions according to the settings used. When 100% is selected the pixel dimensions are unchanged, as you say.Phred wrote:Jpeg photos here imported from an iPhone 4 can be resized by XnView, by '100%', becoming files of half their former size - without any apparent visual or dimensional changes.
...
Each photo of a pair carries the same number of pixels (H & W) and the same colour depth, yet 90% of the time, one of the pair is about half the size of the other. And each looks the same as the other.
The differences in file sizes after using Resize you report are likely due to the settings used when you saved the images after resizing them: primarily the compression factor 'Quality' selected, and also possibly the other detailed settings available in the File > Save as... 'Options' menu below.
Edit:
What result do you wish to achieve?
Re: iPhone Photos Appear To Be Overweight
Thanks for the suggestion, cday, but - no. Nothing much changed.
I tried again with the exact set of jpeg options that you illustrated, even on a different set of originals, and the proportions were about the same.
42 MB for 24 files versus 24 megs for the same 100% resized output.
In fact, with nothing [ ] for the parameters in the resize width and height - empty, zero, zip in the boxes, the resultant anomalous resize was the same. Strange code in there...?
By adding a sixth tick for 'Keep XMP' the resultant set increased by only about 500 k. Plausible.
The largest files decrease the greatest amount in file-size, as you'd expect; more 'fat' in them..
And I say again, the linear dimensions and number of colours remain the same as the originals'.
By trying really hard - unticking IPTC/ICC/XMP, ticking Optimise Huffman, other defaults - I got the total file size down to 24.6 mn bytes, rather than the original result's 24.9. Consistent.
> As for the result I'd like to achieve, first, more knowledge, second, more confidence in XnView, and third, I'm very happy if I can reclaim space wasted by Apple's way of writing jpeg files.
> What I do want to avoid is the loss of something that I'm not seeing at the moment - a dêja gnu: something that'll hit me in the face later when I look at it.
Phred
6th Oct, 2014.
I tried again with the exact set of jpeg options that you illustrated, even on a different set of originals, and the proportions were about the same.
42 MB for 24 files versus 24 megs for the same 100% resized output.
In fact, with nothing [ ] for the parameters in the resize width and height - empty, zero, zip in the boxes, the resultant anomalous resize was the same. Strange code in there...?
By adding a sixth tick for 'Keep XMP' the resultant set increased by only about 500 k. Plausible.
The largest files decrease the greatest amount in file-size, as you'd expect; more 'fat' in them..
And I say again, the linear dimensions and number of colours remain the same as the originals'.
By trying really hard - unticking IPTC/ICC/XMP, ticking Optimise Huffman, other defaults - I got the total file size down to 24.6 mn bytes, rather than the original result's 24.9. Consistent.
> As for the result I'd like to achieve, first, more knowledge, second, more confidence in XnView, and third, I'm very happy if I can reclaim space wasted by Apple's way of writing jpeg files.
> What I do want to avoid is the loss of something that I'm not seeing at the moment - a dêja gnu: something that'll hit me in the face later when I look at it.
Phred
6th Oct, 2014.
Regards, PhredE
Willing donor, if only a 'donor token' were supplied in return, putting 'Phred's XnView' or '$D', '$Dd', '$dd' (depending on size) or 'Donor Version' in the title bar. (See Wiztree for partial solution.)
And a local Help file
Willing donor, if only a 'donor token' were supplied in return, putting 'Phred's XnView' or '$D', '$Dd', '$dd' (depending on size) or 'Donor Version' in the title bar. (See Wiztree for partial solution.)
And a local Help file
Re: iPhone Photos Appear To Be Overweight
Your primary aim is to minimise the file size of your IPhone JPEGs without any perceptible loss of quality, or presumably metadata?
It isn't entirely clear why you first used the XnView Resize function, presumably because you believed that it was a function provided to reduce the byte size of files? And you have continued using it because it does, incidentally, reduce the size of your iPhone JPEGs?
The one setting you haven't referred to above is the save 'Quality' setting: saving at a lower value is the most obvious way of reducing file size, and arguably the most obvious explanation for the file size reduction you are seeing unless you have been saving at 100% Quality.
The JPEG format is a lossy format, but for colour images it is almost the only practical format available when file size is important. But inherently lossy as is, photographic images often compress very well with no perceptible loss of quality. So you might explore that if you haven't considered it already; one caveat, though, would be to leave some margin to allow for the possibility that future higher-resolution screens may show defects that aren't visible at present day screen resolutions.
The halving of file size you are seeing after opening and saving an image in XnView is a mystery unless the images are being saved at a lower quality, with no visible loss, than the original images. It could be easily explained if your images were 48-bit colour, as XnView only supports 24-bit colour, but the JPEG format doesn't support that bit depth, even if your iPhone camera did...
Do you have an original image you could upload for inspection? The forum attachment size limit is currently 1MB, so that may be a problem, alternatively you could possibly upload an image to a file hosting service in the cloud and provide a link.
It isn't entirely clear why you first used the XnView Resize function, presumably because you believed that it was a function provided to reduce the byte size of files? And you have continued using it because it does, incidentally, reduce the size of your iPhone JPEGs?
The one setting you haven't referred to above is the save 'Quality' setting: saving at a lower value is the most obvious way of reducing file size, and arguably the most obvious explanation for the file size reduction you are seeing unless you have been saving at 100% Quality.
The JPEG format is a lossy format, but for colour images it is almost the only practical format available when file size is important. But inherently lossy as is, photographic images often compress very well with no perceptible loss of quality. So you might explore that if you haven't considered it already; one caveat, though, would be to leave some margin to allow for the possibility that future higher-resolution screens may show defects that aren't visible at present day screen resolutions.
The halving of file size you are seeing after opening and saving an image in XnView is a mystery unless the images are being saved at a lower quality, with no visible loss, than the original images. It could be easily explained if your images were 48-bit colour, as XnView only supports 24-bit colour, but the JPEG format doesn't support that bit depth, even if your iPhone camera did...
Do you have an original image you could upload for inspection? The forum attachment size limit is currently 1MB, so that may be a problem, alternatively you could possibly upload an image to a file hosting service in the cloud and provide a link.
Re: iPhone Photos Appear To Be Overweight
Yes, it is well known that all phones save their files very big if you select the 'fine' setting. iPhones are among the worst, basically not doing much compression at all because users think big files = good quality. In fact an iPhone file is often bigger than a similar image taken with a DSLR and edited in photoshop. You can safely save at 80-90% is XnView, because you're not really losing detail at that point, it's all noise from a small phone sensor. If you take it through photoshop and de-noise it it'll be even smaller.
Re: iPhone Photos Appear To Be Overweight
The 50% reduction in file size observed after using Image > Resize... in XnView, without actually changing the pixel dimensions, is possibly entirely due to the resampling that occurs smoothing the noise? That could easily be checked by testing with and without resampling selected...obelisk wrote:Yes, it is well known that all phones save their files very big if you select the 'fine' setting. ... You can safely save at 80-90% is XnView, because you're not really losing detail at that point, it's all noise from a small phone sensor.
Edit:
We don't know yet whether the resized files have been intentionally saved at 100% quality, in which case a reduction in noise due to resampling might possibly be an explanation for the large file size reduction obtained, or whether the resized files were actually saved at a lower quality setting, in which case a reduction in noise is a likely additional factor in the file size reduction.