I just “move” image, and its metadata changes…
I simply copied my image and saved it to another temp folder in the current directory, nothing is modified, but the image is taking way more "disk space" than it's "bytes size".
And! When I done so, I lost most of my image's metadata such as location data, Device model, F number and others, only Color space, Alpha channel and Dimensions are preserved.
Here is the code I do:
from PIL import Image
import os
image_path = "/Users/moomoochen/Desktop/XXXXX.jpg"
img = Image.open(image_path)
pathname, filename = os.path.split(image_path)
new_pathname = (pathname + "/temp")
if not os.path.exists(new_pathname):
os.makedirs(new_pathname)
img.save(os.path.join(new_pathname, filename))
# If I want to adjust the quality, I do this:
img.save(os.path.join(new_pathname, filename), quality=80)
So my question is:
1) Why bytes size is different than disk space?
2) How can I adjust my code so that it will preserve all image's metadata?

python-3.x image size python-imaging-library jpeg
add a comment |
I simply copied my image and saved it to another temp folder in the current directory, nothing is modified, but the image is taking way more "disk space" than it's "bytes size".
And! When I done so, I lost most of my image's metadata such as location data, Device model, F number and others, only Color space, Alpha channel and Dimensions are preserved.
Here is the code I do:
from PIL import Image
import os
image_path = "/Users/moomoochen/Desktop/XXXXX.jpg"
img = Image.open(image_path)
pathname, filename = os.path.split(image_path)
new_pathname = (pathname + "/temp")
if not os.path.exists(new_pathname):
os.makedirs(new_pathname)
img.save(os.path.join(new_pathname, filename))
# If I want to adjust the quality, I do this:
img.save(os.path.join(new_pathname, filename), quality=80)
So my question is:
1) Why bytes size is different than disk space?
2) How can I adjust my code so that it will preserve all image's metadata?

python-3.x image size python-imaging-library jpeg
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
1
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53
add a comment |
I simply copied my image and saved it to another temp folder in the current directory, nothing is modified, but the image is taking way more "disk space" than it's "bytes size".
And! When I done so, I lost most of my image's metadata such as location data, Device model, F number and others, only Color space, Alpha channel and Dimensions are preserved.
Here is the code I do:
from PIL import Image
import os
image_path = "/Users/moomoochen/Desktop/XXXXX.jpg"
img = Image.open(image_path)
pathname, filename = os.path.split(image_path)
new_pathname = (pathname + "/temp")
if not os.path.exists(new_pathname):
os.makedirs(new_pathname)
img.save(os.path.join(new_pathname, filename))
# If I want to adjust the quality, I do this:
img.save(os.path.join(new_pathname, filename), quality=80)
So my question is:
1) Why bytes size is different than disk space?
2) How can I adjust my code so that it will preserve all image's metadata?

python-3.x image size python-imaging-library jpeg
I simply copied my image and saved it to another temp folder in the current directory, nothing is modified, but the image is taking way more "disk space" than it's "bytes size".
And! When I done so, I lost most of my image's metadata such as location data, Device model, F number and others, only Color space, Alpha channel and Dimensions are preserved.
Here is the code I do:
from PIL import Image
import os
image_path = "/Users/moomoochen/Desktop/XXXXX.jpg"
img = Image.open(image_path)
pathname, filename = os.path.split(image_path)
new_pathname = (pathname + "/temp")
if not os.path.exists(new_pathname):
os.makedirs(new_pathname)
img.save(os.path.join(new_pathname, filename))
# If I want to adjust the quality, I do this:
img.save(os.path.join(new_pathname, filename), quality=80)
So my question is:
1) Why bytes size is different than disk space?
2) How can I adjust my code so that it will preserve all image's metadata?

python-3.x image size python-imaging-library jpeg
python-3.x image size python-imaging-library jpeg
asked Nov 15 '18 at 6:35
moomoochenmoomoochen
9019
9019
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
1
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53
add a comment |
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
1
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
1
1
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53
add a comment |
1 Answer
1
active
oldest
votes
Two things...
You are not actually "simply copying" your file. You are opening it in an image processor, expanding it out to a processable matrix of pixels and then resaving the image to disk - minus anything that your image processor wasn't interested in :-)
If you want to copy the complete file including EXIF data, use shutil like this:
#!/usr/local/bin/python3
from shutil import copyfile
copyfile('source.jpg', 'destination.jpg')
Check in Finder:

Secondly, all "on-disk" filesystems have a minimum allocation unit which means that if your file grows, it will grow by a whole unit, even if you just need 1 more byte of space. Most disks use a 4,096 byte allocation unit, so a 33 byte file will take up 4,096 bytes of space. I must say yours is rather higher than 4k of slack so maybe you are running on a fat RAID that works in big blocks to increase performance?
As an example, you can do this in Terminal:
# Write a file with 1 logical byte
echo -n "1" > file
# Look at file on disk
ls -ls file
8 -rw-r--r-- 1 mark staff 1 15 Nov 08:10 file
Look carefully, the 1 after staff means the logical size is 1 byte and that's what programs get if they read the whole file. But the first 8 on the left is the number of blocks on disk. Each block is 512 bytes, so this 1-byte file takes 8 blocks of 512 bytes, i.e. 4kB on disk!
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53313717%2fi-just-move-image-and-its-metadata-changes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Two things...
You are not actually "simply copying" your file. You are opening it in an image processor, expanding it out to a processable matrix of pixels and then resaving the image to disk - minus anything that your image processor wasn't interested in :-)
If you want to copy the complete file including EXIF data, use shutil like this:
#!/usr/local/bin/python3
from shutil import copyfile
copyfile('source.jpg', 'destination.jpg')
Check in Finder:

Secondly, all "on-disk" filesystems have a minimum allocation unit which means that if your file grows, it will grow by a whole unit, even if you just need 1 more byte of space. Most disks use a 4,096 byte allocation unit, so a 33 byte file will take up 4,096 bytes of space. I must say yours is rather higher than 4k of slack so maybe you are running on a fat RAID that works in big blocks to increase performance?
As an example, you can do this in Terminal:
# Write a file with 1 logical byte
echo -n "1" > file
# Look at file on disk
ls -ls file
8 -rw-r--r-- 1 mark staff 1 15 Nov 08:10 file
Look carefully, the 1 after staff means the logical size is 1 byte and that's what programs get if they read the whole file. But the first 8 on the left is the number of blocks on disk. Each block is 512 bytes, so this 1-byte file takes 8 blocks of 512 bytes, i.e. 4kB on disk!
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
add a comment |
Two things...
You are not actually "simply copying" your file. You are opening it in an image processor, expanding it out to a processable matrix of pixels and then resaving the image to disk - minus anything that your image processor wasn't interested in :-)
If you want to copy the complete file including EXIF data, use shutil like this:
#!/usr/local/bin/python3
from shutil import copyfile
copyfile('source.jpg', 'destination.jpg')
Check in Finder:

Secondly, all "on-disk" filesystems have a minimum allocation unit which means that if your file grows, it will grow by a whole unit, even if you just need 1 more byte of space. Most disks use a 4,096 byte allocation unit, so a 33 byte file will take up 4,096 bytes of space. I must say yours is rather higher than 4k of slack so maybe you are running on a fat RAID that works in big blocks to increase performance?
As an example, you can do this in Terminal:
# Write a file with 1 logical byte
echo -n "1" > file
# Look at file on disk
ls -ls file
8 -rw-r--r-- 1 mark staff 1 15 Nov 08:10 file
Look carefully, the 1 after staff means the logical size is 1 byte and that's what programs get if they read the whole file. But the first 8 on the left is the number of blocks on disk. Each block is 512 bytes, so this 1-byte file takes 8 blocks of 512 bytes, i.e. 4kB on disk!
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
add a comment |
Two things...
You are not actually "simply copying" your file. You are opening it in an image processor, expanding it out to a processable matrix of pixels and then resaving the image to disk - minus anything that your image processor wasn't interested in :-)
If you want to copy the complete file including EXIF data, use shutil like this:
#!/usr/local/bin/python3
from shutil import copyfile
copyfile('source.jpg', 'destination.jpg')
Check in Finder:

Secondly, all "on-disk" filesystems have a minimum allocation unit which means that if your file grows, it will grow by a whole unit, even if you just need 1 more byte of space. Most disks use a 4,096 byte allocation unit, so a 33 byte file will take up 4,096 bytes of space. I must say yours is rather higher than 4k of slack so maybe you are running on a fat RAID that works in big blocks to increase performance?
As an example, you can do this in Terminal:
# Write a file with 1 logical byte
echo -n "1" > file
# Look at file on disk
ls -ls file
8 -rw-r--r-- 1 mark staff 1 15 Nov 08:10 file
Look carefully, the 1 after staff means the logical size is 1 byte and that's what programs get if they read the whole file. But the first 8 on the left is the number of blocks on disk. Each block is 512 bytes, so this 1-byte file takes 8 blocks of 512 bytes, i.e. 4kB on disk!
Two things...
You are not actually "simply copying" your file. You are opening it in an image processor, expanding it out to a processable matrix of pixels and then resaving the image to disk - minus anything that your image processor wasn't interested in :-)
If you want to copy the complete file including EXIF data, use shutil like this:
#!/usr/local/bin/python3
from shutil import copyfile
copyfile('source.jpg', 'destination.jpg')
Check in Finder:

Secondly, all "on-disk" filesystems have a minimum allocation unit which means that if your file grows, it will grow by a whole unit, even if you just need 1 more byte of space. Most disks use a 4,096 byte allocation unit, so a 33 byte file will take up 4,096 bytes of space. I must say yours is rather higher than 4k of slack so maybe you are running on a fat RAID that works in big blocks to increase performance?
As an example, you can do this in Terminal:
# Write a file with 1 logical byte
echo -n "1" > file
# Look at file on disk
ls -ls file
8 -rw-r--r-- 1 mark staff 1 15 Nov 08:10 file
Look carefully, the 1 after staff means the logical size is 1 byte and that's what programs get if they read the whole file. But the first 8 on the left is the number of blocks on disk. Each block is 512 bytes, so this 1-byte file takes 8 blocks of 512 bytes, i.e. 4kB on disk!
edited Nov 15 '18 at 8:52
answered Nov 15 '18 at 8:04
Mark SetchellMark Setchell
91.2k779183
91.2k779183
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
add a comment |
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
Thanks Mark! Very detailed and well explained.
– moomoochen
Dec 4 '18 at 7:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53313717%2fi-just-move-image-and-its-metadata-changes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Hi, I would suggest the Wikipedia article on data clusters in filesystems
– Vivick
Nov 15 '18 at 6:41
Thanks for the article, and I am not exactly sure if that's the problem, I should have mentioned that it does not happened to all my images, normally it would just be roughly the same bytes size and disk space as expected, but in some cases, like this one, it just takes more disk spaces.
– moomoochen
Nov 15 '18 at 6:54
1
Did my answer sort out your problem? If so, please consider accepting it as your answer - by clicking the hollow tick/checkmark beside the vote count. If not, please say what didn't work so that I, or someone else, can assist you further. Thanks. meta.stackexchange.com/questions/5234/…
– Mark Setchell
Nov 20 '18 at 9:53