I just “move” image, and its metadata changes…










2















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?



it should be 1.3 MB on disk, but it's 2.2 MB on disk...










share|improve this question






















  • 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















2















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?



it should be 1.3 MB on disk, but it's 2.2 MB on disk...










share|improve this question






















  • 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













2












2








2








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?



it should be 1.3 MB on disk, but it's 2.2 MB on disk...










share|improve this question














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?



it should be 1.3 MB on disk, but it's 2.2 MB on disk...







python-3.x image size python-imaging-library jpeg






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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

















  • 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












1 Answer
1






active

oldest

votes


















1














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:



enter image description here




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!






share|improve this answer

























  • Thanks Mark! Very detailed and well explained.

    – moomoochen
    Dec 4 '18 at 7:08










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
);



);













draft saved

draft discarded


















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









1














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:



enter image description here




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!






share|improve this answer

























  • Thanks Mark! Very detailed and well explained.

    – moomoochen
    Dec 4 '18 at 7:08















1














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:



enter image description here




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!






share|improve this answer

























  • Thanks Mark! Very detailed and well explained.

    – moomoochen
    Dec 4 '18 at 7:08













1












1








1







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:



enter image description here




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!






share|improve this answer















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:



enter image description here




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!







share|improve this answer














share|improve this answer



share|improve this answer








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

















  • 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



















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

What does pagestruct do in Eviews?

Dutch intervention in Lombok and Karangasem

Channel Islands