Levente Uzonyi wrote:
On Tue, 22 Oct 2013, Mateusz Grotek wrote:
It is (even on Cog). What is the reason for that? Is it a problem with the algorithm used in the image or it's unsolvable inside the image and a plugin or FFI is needed.
I doubt it can be significantly faster using smalltalk only. When we wanted to store images in files using lossless compression, we decided to use jpeg instead of png, because it has plugin support, so it's a lot faster to load and save the images.
That sounds contradictory since JPEG is not lossless (I know you know, just stating the obvious). For computer generated images with solid blocks of colour JPEG can have artifacts. PNG is lossless. In general, photo=JPEG, graphics=PNG.
P.S.
Code: (PNGReadWriter formFromFileNamed: something) durationToRun "0:00:01:09.591" "unacceptale if you want to program an image browser"
Data: 1301.png: PNG image data, 2048 x 1536, 8-bit/color RGB, non-interlaced (a pic of a street taken from a cell phone)
That image is huge. Cell phones and digital cameras usually create jpeg images. But if you really need to support png, then ffi or a plugin is the way to go.
I believe this is because a higher level of compression would take longer and use more battery. You can use http://www.xnview.com/ to often drop 80% of the file size of of cell phone images without any apparent loss of quality.
-ben
Levente