前言

先声明：从去年的7~8月份我开始折腾自建相册，当时对比了immich最后选择了photoprism，至今也用了一年半的时间了，所以算是个老用户了，不是简单新手向的吐槽。

为什么用了一年半以后才开始写这个吐槽文，因为我自己用java写了一个小服务来处理照片归档，所以最后一个对pp的依赖也没有了，终于可以把pp从我的服务器上remove掉惹。

在放弃pp的这一刻，写篇文章记录一下我在使用pp的过程中碰到的几个超级大槽点。

超级大槽点

槽点一：照片统一重命名都按照UTC时区处理

这个是pp归档照片时最大的bug。

pp有个功能，就是按照统一规则生成一个唯一的文件名将照片进行重命名，所以最后的文件名都是yyyyMMdd_HHmmss_xxxxxxxx.jpg这种格式，其中最后8位x应该是类似md5一样根据文件生成的8位字符串。

这个功能很好用，也是强制启用的功能。按照这个规则重命名以后的照片/视频，根据文件名就能很方便的知道文件的创建时间，而且也统一了文件名，看上去很干净规整。

但是这个功能有个很大的bug！！！！

pp是按照utc时区来生成的文件名，也就是北京东八区的照片时间需要减去8个小时来生成文件名！！！

比如某时某刻我在东八区拍了一张jpg照片，拍摄时间是2024年12月5日15点36分44秒，那照片归档正确的文件名应该是20241205_153644_xxxxxxxx.jpg。但是pp会读取照片exif中的时区信息，换算成utc时区的时间生成文件名，也就是北京时间减去8个小时，最后就变成了20241205_073644_xxxxxxxx.jpg。

(╯‵□′)╯︵┻━┻

不过，比起原始照片文件各种乱七八糟无规则、无意义、自然递增的文件名格式，现在这个文件名只是时间少了8个小时，好像也不是太大的问题。

那就要配合上下面这个大杀器！

槽点二：照片归档也按照UTC时区处理

pp归档图片和视频文件时，是根据文件的创建时间，按照yyyy/mm的目录结构来归档文件的。

但是由于槽点一的存在，又导致了一种情况：

  • 月初拍的照片有可能被归档到上个月！比如，2024年12月1号早上7点拍的照片，减去8小时是2024年11月30号晚上11点，就被归档到2024/11目录惹
  • 年初拍的照片可能被归档到上一年！比如：2024年1月1日早上7点拍的照片，减去8小时候是2023年12月31日晚上11点，就被归档到2023/12目录惹

这种情况下，如果在pp中搜索2024年12月份的照片，或者搜2024年的照片，这种错误归档的照片就搜不到了！！！

(╯‵□′)╯︵┻━┻

我在使用photoprism的这一年半时间里，也想过是不是我什么地方没设置正确，比如是不是docker-compose.yml中没有加timezone参数，是不是服务器的时间设置错误。我在官方wiki和官方github issue里也找过，但实在是个人能力有限，没有找到什么有用的解决方法。我甚至在想，也许这是因为pp是一个面向全球用户的服务，开发团队为了解决那些经常往返不同时区的用户的照片归档问题，所以直接暴力的统一换算成utc时区。如果真的如此，那我要给pp开发团队送上1000个赞👍，这明显不是像我这种今生都没有离开过东八区的宅男能有的国际视野。

我非常喜欢pp这个按照文件时间统一命名的功能，虽然有换算成utc时区的大槽点，但另外几个相册（比如immich）都没有这个功能，所以最后我不得不继续坚持使用pp。

槽点三：图片算法识别功能很垃圾

pp作为一个完整的相册服务，也提供了图像算法识别功能，用来进行图像主体识别、人脸识别、自动标签、自动创建精彩时刻、图片质量打分等等智障功能。

但我实体使用下来的体验是：不好用，非常不好用。

不说和google、apple的图像识别算法对比，也不和国内各个手机厂商提供的手机智能相册比，只是和immich比，我都感觉差了很多。主体识别错误、检测不到人脸、自动标签错误，很难说达到可用级别。

对于pp的图像识别算法功能，我的点评是：能用但是不好用，徒增功耗、浪费算力，建议关闭。

槽点四：免费版pp的gps解析功能有限制

相信很多pp用户和我一样都是用的免费社区版（community）做自建相册，pp免费版也带了照片地图功能，根据照片exif中保存的gps信息显示照片的拍摄地并显示在地图上。

但是，但是，pp的骚操作又又又来惹！！！

免费版pp根据gps坐标数据解析地理位置的api有请求数量限制！！！有rate limit！！！

也就是如果导入比较多的照片，很容易就达到这个reverse geocodeing接口的请求数量限制，这个api会超时无响应报timeout错误让你以为是自己网络出了问题。因为immich就有很多请求是访问google，如果不挂科学上网使用immich，查看日志的时候会看到大量的timeout请求。

如果不小心触发了这个rate limit，很抱歉你的pp解析照片地理位置的功能就gg了。

如果你在导入照片的时候，导到中途免费请求次数用完了，会发生什么：

  1. 剩下的照片依然能导入，只是剩下的照片都没有地理信息了
  2. 解析照片gps的请求依然会发起，但每次都是超时无响应（timeout），这个超时要等好几秒，导致整个导入过程变成非常慢

在官方wiki我没有查到明确的免费请求次数，也没有查到如果免费请求次数耗尽以后是否会隔天重置。

不过作为免费白嫖党，官方对此功能做出rate limit也算可以理解，因为官方提供这个服务需要开销，只是让付费用户分摊了。

如果你是pp重度用户，建议花钱订阅支持pp，就可以无限制使用照片地理信息解析的接口惹。

如果你和我一样是pp白嫖党，建议关闭pp的【地点】功能。

槽点五：普通图片的时间信息提取规则不完善

首先定义下这里说的普通图片。这里把用手机、相机拍摄而成的图片称之为【拍摄行为】产生的照片，把存的网图、微信图、截图、微博图称之为【非拍摄行为】产生的普通图片。

pp在将文件进行归档时，需要提取文件的时间信息。如果是照片文件，这类文件的exif中都有完整的Date/Time Original、 Date/Time Digitized信息，只需要读取这些tag中保存的时间字符串解析成时间，然后用这个时间给文件重新命名就行了（别忘了会减去8个小时）。

如果是普通图片，这种文件的exif中没有Date/Time Original、 Date/Time Digitized这些tag，那要如何提取这个文件的时间呢？

经过我的摸索，pp提取文件时间信息的规则优先级如下：

  1. Date/Time Original、 Date/Time Digitized：这俩tag可以理解位照片的拍摄时间，pp读到这个时间后会按照utc时区处理
  2. 从文件名中提取时间：图片文件的exif没有以上两个tag，但文件名中包含了时间信息，比如Snipaste_2024-12-05_20-50-36.jpg，只需要拿到2024-12-05_20-50-36这段字符进行解析即可。这个规则下，pp读到什么时间就是什么时间，不会处理时区。
  3. 如果以上两个规则都无法提取到文件的时间，则以系统当前时间为准，pp读到这个时间后也会按照utc时区处理

这些规则不仅仅是pp在用，其它相册服务应该也大差不差。

从以上规则可以看出，普通图片文件很容易因为无法满足规则1、规则2，最后在归档时，直接以系统当前时间给文件重命名。从某种程度上说，这倒也无可厚非，毕竟没有其它方法获取这种文件的创建时间了，只能用这种方式作为保底。

但是，是的，又要接一个但是，为什么这也会成为pp的一个大槽点？

因为pp的规则2（从文件名中提取时间）甚至都不支持它自己的归档文件名格式，也就是yyyyMMdd_HHmmss_xxxxxxxx，pp碰到这么标准的文件名竟然无法提取时间，最后会按照规则3给文件重命名！！！

这个bug会导致的问题就是：用pp归档过一次的文件，如果重新导入pp，那这些普通图片文件都会按照系统当前时间进行重命名和归档！也就是这些普通文件不管第一次导入时被归档到哪天，在二次导入时，都会被归档到今天。

你可能会觉得奇怪，为什么会有傻x把已经归档过的照片反复导入pp归档。

是我！是我！我就出现过这种操作！

比如我目前有8w个照片、图片、视频文件，全部导入pp进行归档，归档完成后删除了原始文件，保留了归档文件。然后很不幸我部署pp的系统崩了，但8w个已归档的文件还在。这时我重新部署一个pp，把8w个已经归档的文件又全部导入pp进行【二次归档】。

🤔🤔🤔🤔🤔🤔🤔🤔

这个时候我发现很多普通图片都被归档到今天，排在了最前面！！！！！！

(╯‵□′)╯︵┻━┻

小槽点

对硬件性能要求略高

photoprism要求的最低硬件配置

  • 双核cpu
  • 3GB内存
  • 64位的系统
  • 4GB swap

但我实际测试下来，在关掉所有图像算法、地理位置、webdav等等各种智障功能，只保留导入、归档功能的情况下，在玩客云上都能跑起来，要知道玩客云只有1GB内存 + 512MB swap。

不过部署在玩客云上时，归档照片问题不大（虽然很慢，大概7秒钟处理一张照片），归档体积比较大的视频文件时很容易就oom导致服务挂掉。而且玩客云刷debian以后不支持视频解码，如果真的在玩客云上部署pp，记得千万不要在pp的web端播放本地不支持解码的视频（比如h265/av1），要不然玩客云会用它羸弱的s805芯片开始及其漫长且看不到尽头的视频转码。

但是，如果只是用到pp的统一重命名 + 归档功能，pp硕大的docker镜像体积（本体接近3GB，如果用pg数据库还要再加1GB的pg镜像）、至少1GB的内存占用，又显得硬件性能要求略高了。

照片墙布局和ui不好看

这点纯个人主观喜好，每个人审美不同要求也不同，我觉得pp的照片墙不好看，ui也显得很老气。

搜索功能只能精确到月

无法精确到天搜索文件。

没有免费app

官方推荐pwa，我一直用的这个，用来上传照片够用了。

官方也推荐了第三方的收费app：photosync，有钱的可以上。

对视频的支持很差

web端浏览视频的体验很糟糕，也可以说对视频的支持很差。在手机pwa上浏览视频的体验更是糟上加糟。

优点

不过，虽然pp的雷点这么多，小缺点也不少，但我依然坚持用了一年半，说明它比起其它自建相册服务还是有很多过人之处的：

  • 免费且稳定：免费这点打败了mtphotos，稳定这点打败了immich
  • 归档功能好用：文件统一命名，解决了原始文件名乱七八糟的问题
  • 老硬件友好：至今还在发布arm32硬件的docker镜像，在玩客云上跑pp成为可能

结语

在被迫接受了pp的大雷点和小缺点并坚持使用一年半之后，我花了点时间重操旧业用java写了一个简单的照片归档程序（本来想用golang写的但年纪大了实在学不会新语言），100%符合我想要的需求：

  1. 按照yyyyMMdd_HHmmss_xxxxxxxx格式统一文件命名（而且正确处理了时区问题哦）
  2. 按照yyyy/mm目录结构进行文件归档
  3. 重命名和归档操作不修改文件原始exif

经过测试已经完美运行并部署到机器上惹，从此可以抛弃photoprism。

至于抛弃photoprism以后会用哪个相册服务？🤔

我对相册服务的需求其实主要就是上述的3点，对于照片在线展示并没有需求，对人脸识别、标签分类、照片地图也没有需求，所以目前用的fnos自带的相册，很好用。

最后还是感谢一下photoprism，感谢它陪伴了我一年半的时间。

🎉

喝杯奶茶