由于有问题评论的人反复告诉我这很琐碎,因此我实际上做到了:一个应用程序,通过将实际的头对头比较留给用户来对当前目录中的图像进行排序。1个
用C#for .NET 2编写。它也可以在Mono上运行(到目前为止已经在Linux上测试过)。在PATH上需要dcraw(可在此处下载Windows或OS X的编译的可执行文件)。
当前,用户交互非常初级。这可能会更改。同样,使用这种hack-job,代码也像往常一样是一团糟。
必须在包含要排序图像的目录中启动该应用程序。然后,它将继续加载它可以找到和处理的所有图像(本地支持JPEG,GIF,PNG,BMP,dcraw支持所有其他格式,否则不跳过)。保持图像数量合理,因为每个图像都已预加载到内存中以加快显示速度–我尝试在包含约600张图像的文件夹中启动它,并在2 GiB内存使用量时终止它。
之后,您将获得一个两窗格视图,左侧和右侧都有一个图像。单击您认为两者中最好的一个。然后,您将获得两个新图像。继续直到完成。您可以根据需要关闭程序,该程序将从您上次中断的地方继续。
在完成所有必要的比较之后2,可以看到结果:
它的图像排序列表在左侧,最高的在顶部,最低的在底部。
待办事项清单:
- 允许选择要排序的图像。
- 解决了肖像图片始终以横向显示的问题(至少对于原始图像而言。dcraw允许旋转,但无法自动旋转,而且我看不到从外部找到该图像的简便方法)。
- 减少大量图像的内存使用量。
- 事先将图像随机播放,这样几乎不会直接比较彼此几乎相同的图像突发。
- 将排序线程和UI之间的同步更改为不再依赖
Thread.Sleep
和轮询,而是使用适当的同步方法。
- 添加1:1预览(或至少更大的预览)。当前,这不能用于在像素级别上判断事物。
现在是5:26,所以我现在停止对此进行黑客攻击。
可以在我的SVN存储库中找到源代码,并根据MIT许可证发布了源代码。我欢迎补丁;-)
上面截图中的图像是我自己的。
1当然,这并不比其他人想让我相信的那么简单。经过与Libraw的长期斗争,我干脆走了dcraw路线。不漂亮,但是只用最少的代码即可工作。
2这是n log 2 n的顺序,其中n是比较的图片数量–因此,对于20张图片,您可以期望大约20×4.3≈85个比较–我知道,这不是一个小数目。对于您提到的300张图像,您将得到2400张左右。必须手动执行的实际数字是(a)不同(因为复杂度省略了线性因子),而(b)据我观察到的较小。为避免不一致,将永远不会在同一张两张图片(两次订购)上两次提示用户,也永远不会在两边都用同一张图片提示用户。