你们老师吃的好饱搞不好都有点撑了暂且认为是故意考验你们技术吧40W记录，读取磁盘都要花时间，所以再快也快不到哪去 好吧，回归正题： 这种情况下，你的数据表要另外设计，不能按你之前说法设计，关键字段要这样来： int X, int Y, int RGB 理解么？数据库中直接存储点的颜色，不要存储图片本身！然后在 X 和 Y 上建立索引，以便快速检索某行或某列的点出来。
你们老师吃的好饱搞不好都有点撑了暂且认为是故意考验你们技术吧40W记录，读取磁盘都要花时间，所以再快也快不到哪去然后在 X 和 Y 上建立索引，以便快速检索某行或某列的点出来。快都快不到哪去呀，我知道这种做法，x，y标示这个像素点的坐标，，建了索引也慢哎呀。 理解么？数据库中直接存储点的颜色，不要存储图片本身！
所保存的文件格式是什么？这点很重要。某些文件格式，文件头需要保存“配色表”甚至是“压缩编码信息”，会占用很大空间。所以这种超小图片，你可以尝试用 bmp 格式保存。
所保存的文件格式是什么？这点很重要。某些文件格式，文件头需要保存“配色表”甚至是“压缩编码信息”，会占用很大空间。所以这种超小图片，你可以尝试用 bmp 格式保存。
google默认也是用png的，我想用，有没有办法去掉配色表，如果去掉后4w个像素点还能不能组成一副图片呀
当然了，40000个像素点的图片怎么可能有4M多啊，就算是24位的无压缩的位图也只有100多K而已啊。
谢谢了，我下午试试！
应该不行，png是有压缩的，去掉就没法还原实际图片了。不要纠结 4W 个像素点的问题了，如果你4W个像素点颜色都完全一样，被png压缩下可能就剩几百个字节
应该不行，png是有压缩的，去掉就没法还原实际图片了。不要纠结 4W 个像素点的问题了，如果你4W个像素点颜色都完全一样，被png压缩下可能就剩几百个字节如果4w我不纠结了。我讲讲我现在的状况，我数据库里存的都是1*1的google像素点的二进制字节，大小为98字节，我如何才能把4w个这样的像素点绘成200*200的一张图片呢.我的想法是提取每个像素点的rgb值，众多rgb值合成一张图片。我的一个界面为1000*1000的，我new一个这样大的bufferedImage，它不报错吗？MickRice如果是你，你会怎么样做呢？
粗略估算：1000×1000×4 = 4,000,000 Byte，也即这样的图片在内存中需要占用大约4MB的空间，注意到图片在内存中是处于非压缩状态的，这样才能便于进行显示和处理。当然实际上还会再浪费更多的空间去辅助存储其它信息，但我们大致已经能得到数量级层面的内存开销了。所以，不会报错。可以用你的方法来提取每个像素点的RGB值，然后进行图片合并。合并完的图片是 1MB 的像素点，压缩png后存储成文件也许就1MB～3MB，如果用jpg则可能就几百K。
2.我试了下从数据库里检索4w条记录，吧一个像素的读到1*1的bufferedImage，在提取他的rgb，再new一个1000*1000的bufferedIMage，用rgb在上面合成图片。very ，very慢，不是一般的慢，我该什么办呀，数据库检索真的慢，我打算这次用cluster了，看看什么情况？你有什么好建议吗？micerice！
1、你计算像素占用空间的方式错了，前面已经讨论了很多，一般来说就是4个字节，分别是：红、绿、蓝、透明度。另外，合并像素显然不能只是简单的把所有文件进行二进制合并，这样合并出来显然不是合法图片。2、慢是必然的，不知道你为啥开始会是1个点1个点的存储图片信息。不过应该不会超级慢。可以并发线程来做，同时开10个线程，先合并成 1000条 1×1000 的线。
数据库没道理检索很慢，不过也许你没有做索引，也许你是每次只查询了1个点而不是批量查询出100个点，这个我就不知道了。
Micerice,1.我赞同用所有二进制文件下手合成是不成功的，那我该如何操作这些二进制才能达到我的目的。
2.我是一次查一个点，我不太懂批量的查询，我只知道批量的插入，我上网查查！
1、就是用你之前说的创建图片，然后依次合并像素点；
2、批量查询就是一次性选取多个点出来呗，然后对ResultSet循环处理即可。
200*200/1024*3=118就是大概118k左右，哪里会有4M多那么大
这种合并应该是事前做吧，合并后的图片存起来，要显示的时候直接显示合并后的才对吧？如果每次都按点来显示图片，这不是折腾电脑么？这种系统需求也太诡异了吧？
老师是这样叫我们做的，不然我也不会去google服务器1*1的抓下来，我直接抓200*200的就是了，他讲显示的时候，先加载一部分，也就是隔几个像素加载，达到渐变模糊的效果，就算是隔几个地图加载也要好长时间，有没有很快的从数据库里检索40w条记录的方法呀？
200*200/1024*3=118就是大概118k左右，哪里会有4M多那么大
呵呵
晕 png 就是压缩格式 的 是一种无损的压缩格式 压弯的大小很小的 .具体是利用了一个调色板什么的 你要研究图像处理这个是必须看的.一个没有经过压缩的图片可以存储成bmp格式的 这个你直接存储一个就会知道确实是很大的.所以一般图片都会压缩 ,你说的吧图片弄到数据库里通过像素查询的东西 我以前写过一个.数据量小的话还是可以应付的 大的需要进行优化. 40w左右的记录应该没什么问题 看你用什么数据库了.
晕 png 就是压缩格式 的 是一种无损的压缩格式 压弯的大小很小的 .具体是利用了一个调色板什么的 你要研究图像处理这个是必须看的.一个没有经过压缩的图片可以存储成bmp格式的 这个你直接存储一个就会知道确实是很大的.所以一般图片都会压缩 ,你说的吧图片弄到数据库里通过像素查询的东西 我以前写过一个.数据量小的话还是可以应付的 大的需要进行优化. 40w左右的记录应该没什么问题 看你用什么数据库了.
我用的是mysql，你用的是什么呀？
现在想想这个做法好像不太合适
你们老师吃的好饱搞不好都有点撑了暂且认为是故意考验你们技术吧40W记录，读取磁盘都要花时间，所以再快也快不到哪去
好吧，回归正题：
这种情况下，你的数据表要另外设计，不能按你之前说法设计，关键字段要这样来：
int X, int Y, int RGB
理解么？数据库中直接存储点的颜色，不要存储图片本身！然后在 X 和 Y 上建立索引，以便快速检索某行或某列的点出来。
你们老师吃的好饱搞不好都有点撑了暂且认为是故意考验你们技术吧40W记录，读取磁盘都要花时间，所以再快也快不到哪去然后在 X 和 Y 上建立索引，以便快速检索某行或某列的点出来。快都快不到哪去呀，我知道这种做法，x，y标示这个像素点的坐标，，建了索引也慢哎呀。
理解么？数据库中直接存储点的颜色，不要存储图片本身！
你可以用字节数组保存图像的颜色信息，然后用流从数组中获取数据或者也有可能是让你研究下jpg的格式，因为jpg有种交错存储格式，它就是像你们老师那样实现的，把每隔几个像素点取一个像素点存到文件前段，然后间隔更小的(这样数据就更多)存储到后面，最后面存储的是最完整的数据。这样在网络速度或者GPU速度不足的时候，就会先模糊(因为取到前段数据)，再清晰。你在使用数码相机的时候应该有感觉，刚打开图片的时候是模糊的，后来清晰，实际上就是因为jpg格式。
后面的对话，我基本都没看了。楼主，你要明白，RGB像素点，在内存中，应该是一个 像素点由三个字节的数字来表示的。如果把这个像素点，保存成文件的话，理论上说，只需要3bit大小的文件就可以了，但是，实际当中，一个图形文件中，除了要保存图片像素的本身信息外，还要保存其他的信息，比如：文件类型，版本号，是否压缩，压缩算法，数据区的偏移量等等信息。楼主不应该把一个像素点的文件大小，机械的理解成所占内存的大小，因为，图形文件在加载到内存的过程中会有一个转换过程。
比如，一个像素的PNG图片，在内存中很可能占3个字节（RGB），但保存成图片可能占90+字节；
200X200像素的PNG图片，在内存中很可能占3X200X200=12W个字节=120KB，但保存成图片可能才30+K。楼主不能偷换这样的概念。最后，讲讲楼主要达到的目的。
楼主其实是想将4W个单像素点的图片，拼接成一个200X200的图片。
首先，要明确的一点是，这个方法效率相当的低下。
其次，在不考虑效率的前提下，楼主可以逐次加载这4W的单像素的文件到内存中，
注意，是逐次，不是一次性的全加载。
每加载一个图片到内存后，将单像素点的RGB（3字节）保存下来。
怎么保存？ 楼主可以先创建一个200X200的BufferedImage对象，然后，设置对应位置的像素点信息。
当像素点信息保存下来后，卸载已加载的图片（或交给垃圾回收机制）。
之后，重复上述过程，逐次加载、保存、卸载，直到4W个像素点都保存下来。
最后，将BufferedImage对象，以PNG格式输出到硬盘文件中，即可。