所以我编写了一个C ++程序，可以生成非常高分辨率的图片（分形）。 我使用fstream将所有数据保存在.ppm文件中。
一切正常，但当我进入真正的高分辨率（38400x21600）时，ppm文件有~8千兆字节。 然而，凭借我的16 GB Ram，我仍然无法转换那张照片。我下载了几个转换器，但他们无法处理它。当我试图＆＃34;导出为......时，Gimp就崩溃了。＆＃34;。
那么，有没有人知道一个可以处理真正大ppm文件的好转换器？事实上，我甚至想要超过100千兆字节。我不在乎它是否缓慢，它应该起作用。
如果没有这样的转换器：有没有办法以更好的方式使用std :: ofstream？也许，是否有一个自动生成PNG文件的库？
谢谢你的帮助！
编辑：我也问自己，保存这些大图像的最佳格式是什么。我研究过，JPEG看起来很漂亮（体积小，质量还不错）。但可能有更好的格式？让我知道。感谢
答案 0 :(得分：1)
一些想法......
38400x21600的8位PPM文件应该占用2.3GB。相同尺寸的16位PPM文件需要两倍，即4.6GB，所以我不确定你从哪里获得8GB。
VIPS非常适合处理大型图像，如果我采用38400x21600 PPM文件，并在终端中使用以下命令（即命令行），我可以看到它在58MB的RAM处达到峰值从PPM转换为JPEG ...
vips jpegsave fractal.ppm fractal.jpg --vips-leak
memory: high-water mark 58.13 MB
在合理的规格iMac上需要31秒，并从我的（随机）数据产生480MB的文件，所以你会期望你的结果要小得多，因为我的相当不可压缩。
另一方面，ImageMagick需要1.1GB的峰值工作内存，并在74秒内完成相同的转换：
/usr/bin/time -l convert fractal.ppm fractal.jpg
73.81 real 69.46 user 4.16 sys
11616595968 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
4051124 page reclaims
4 page faults
0 swaps
0 block input operations
106 block output operations
0 messages sent
0 messages received
0 signals received
9 voluntary context switches
11791 involuntary context switches
答案 1 :(得分：0)
我建议更高效，更快速的解决方案是简单地获得更多内存 - 目前128GB并不是非常昂贵（或增加交换空间）。
答案 2 :(得分：0)
转到Baby X资源编译器并下载JPEG编码器savejpeg.c。它需要一个rgb缓冲区，它必须在内存中保持平坦。入侵它并替换为接受16x16块流的版本。然后编写自己的ppm加载程序，一次装入16像素高的条带。
现在系统将扩展到不适合内存的巨大图像。你不知道怎么展示它们。但JPEG将符合规范。