我只是“移动"图片及其元数据发生了变化... [英] I just "move" image, and its metadata changes...

查看:90
本文介绍了我只是“移动"图片及其元数据发生了变化...的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我只是复制了映像并将其保存到当前目录中的另一个临时文件夹中,没有进行任何修改,但是映像占用的"磁盘空间"比"字节大小"更多".

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".

然后!这样做时,我丢失了图像的大部分元数据,例如位置数据,设备型号,F号等,仅保留了Color spaceAlpha channelDimensions.

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.

这是我要做的代码:

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)

所以我的问题是:

1)为什么字节大小与磁盘空间不同?

1) Why bytes size is different than disk space?

2)如何调整代码,以保留所有图像的元数据?

2) How can I adjust my code so that it will preserve all image's metadata?

推荐答案

两件事...

您实际上不是仅复制" 您的文件.您正在图像处理器中打开它,将其扩展为可处理的像素矩阵,然后将图像重新保存到磁盘-减去图像处理器不感兴趣的任何内容:-)

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

如果要复制包括EXIF数据的完整文件,请像这样使用shutil:

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

签入 Finder :

第二,所有磁盘上" 文件系统都有一个最小分配单位,这意味着,如果您的文件增长了,即使您只需要1个字节的空间,它也会增长一个整体. .大多数磁盘使用4,096字节的分配单元,因此33字节的文件将占用4,096字节的空间.我必须说您的磁盘的松弛度要高于4k,所以也许您运行在胖RAID上并且可以大块运行以提高性能?

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

仔细查看,staff之后的1表示逻辑大小为1字节,这就是程序读取整个文件时得到的内容.但是左边的第一个8是磁盘上的块数.每个块都是512字节,因此这个1字节的文件需要8个512字节的块,即磁盘上的4kB!

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!

这篇关于我只是“移动"图片及其元数据发生了变化...的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆