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.
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)
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.
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.
Levente
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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
On Wed, 23 Oct 2013, Ben Coman wrote:
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.
You have to set the quality parameter to 100 to get a lossless image. The only drawback versus png is that it only supports three channels, so there will be no alpha channel in those images. But that was not a problem for us.
Levente
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.
If that is a concern, then I'm pretty sure these machines have hardware which can compress the images. The do have it for video (mpeg2/h264), so adding jpeg is basically no extra cost.
On the other hand, I don't think creating a png file is computationally less expensive, than creating a jpeg file.
Levente
-ben
Levente
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Levente Uzonyi wrote:
On Wed, 23 Oct 2013, Ben Coman wrote:
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.
You have to set the quality parameter to 100 to get a lossless image. The only drawback versus png is that it only supports three channels, so there will be no alpha channel in those images. But that was not a problem for us.
Thats interesting. I'd never heard of that. I always believed 100 was still lossless per [1] [2]. What software did you use for the lossless JPEG encoding? cheers -ben
[1] http://stackoverflow.com/questions/7982409/is-jpeg-lossless-when-quality-is-... [2] http://photo.stackexchange.com/questions/19876/converting-raw-images-to-loss...
Levente
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.
If that is a concern, then I'm pretty sure these machines have hardware which can compress the images. The do have it for video (mpeg2/h264), so adding jpeg is basically no extra cost.
On the other hand, I don't think creating a png file is computationally less expensive, than creating a jpeg file.
Levente
-ben
Levente
On Wed, 23 Oct 2013, Ben Coman wrote:
Levente Uzonyi wrote:
On Wed, 23 Oct 2013, Ben Coman wrote:
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.
You have to set the quality parameter to 100 to get a lossless image. The only drawback versus png is that it only supports three channels, so there will be no alpha channel in those images. But that was not a problem for us.
Thats interesting. I'd never heard of that. I always believed 100 was still lossless per [1] [2]. What software did you use for the lossless JPEG encoding? cheers -ben
[1] http://stackoverflow.com/questions/7982409/is-jpeg-lossless-when-quality-is-... [2] http://photo.stackexchange.com/questions/19876/converting-raw-images-to-loss...
You're right, it's not lossless, but the difference is not visible by a human on non-forged images.
Levente
Levente
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.
If that is a concern, then I'm pretty sure these machines have hardware which can compress the images. The do have it for video (mpeg2/h264), so adding jpeg is basically no extra cost.
On the other hand, I don't think creating a png file is computationally less expensive, than creating a jpeg file.
Levente
-ben
Levente
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Tue, 22 Oct 2013, 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.
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 just realized that it's one minute and nine seconds runtime for you. That's way more than what it should be. Reading an 1920x1004 non-interlaced RGBA png image takes less than 200 milliseconds for me using Cog.
Can you share the png image, so we can test it?
Levente
Levente
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
I just realized that it's one minute and nine seconds runtime for you. That's way more than what it should be. Reading an 1920x1004 non-interlaced RGBA png image takes less than 200 milliseconds for me using Cog.
Can you share the png image, so we can test it?
Levente
After you said that it's not normal behaviour I tried to reproduce it today. 1. I cannot reproduce those 1 minute delays. 2. I've downloaded fresh Cog (http://www.mirandabanda.org/files/Cog/VM/VM.r2776/coglinux-13.33.2776.tgz) and Squeak (http://ftp.squeak.org/4.4/Squeak-4.4-All-in-One.zip) 3. I've got the following delays in one of my images with the fresh Cog: 0:00:00:41.598 0:00:00:26.942 0:00:00:36.862 0:00:00:32.338 0:00:00:38.316 3. I've got the following delays in the fresh Cog and the fresh Squeak image: 0:00:00:09.108 0:00:00:14.544 0:00:00:12.226 0:00:00:14.174 0:00:00:13.816 4. Still it's around 15 seconds. Image dependence is interesting because they seem to be the same versions (latest update: #12327).
uname -a Linux mglap 2.6.27.21-3.2-pae #1 SMP Wed May 20 03:21:35 CEST 2009 i686 i686 i386 GNU/Linux
cat /proc/cpuinfo ... model name : Genuine Intel(R) CPU T1600 @ 1.66GHz ... cpu MHz : 1662.478 ... cache size : 1024 KB ... bogomips : 3324.95 ...
And here are some photos:
https://dl.dropboxusercontent.com/u/37119147/all.zip
And here is the application I use to read them in: a) Create an empty directory b) Unpack all.zip to it c) Filein Anotator.st d) Run it: Anotator new start. e) Open transcript e) Choose the directory with photos f) Klik lewo (left) and prawo (right) to move from one image to another (it will create some .txt files while doing it, so it may ask you if you want to overwrite) g) see the numbers in Transcript
If you don't want to run the whole app, just run: [PNGReadWriter formFromFileNamed: '/some/path'] durationToRun
Mateusz
Thanks. I found a really bad bottleneck, and fixed some others in PNGReadWriter. I have uploaded my changes to the Trunk, you can find them in Graphics-ul.275. Loading any of the png images you've sent takes 1-1.5 seconds on my machine with the new version. They took 4-7.5 seconds with the old, so the speedup is about 4-5x, which might not be enough for you. You could achieve another 2.5x speedup if your images were in RGBA format (they are in RGB now), because that way the scanline can be converted to a Form without byte level manipulations.
Levente
On Fri, 25 Oct 2013, Mateusz Grotek wrote:
I just realized that it's one minute and nine seconds runtime for you. That's way more than what it should be. Reading an 1920x1004 non-interlaced RGBA png image takes less than 200 milliseconds for me using Cog.
Can you share the png image, so we can test it?
Levente
After you said that it's not normal behaviour I tried to reproduce it today.
- I cannot reproduce those 1 minute delays.
- I've downloaded fresh Cog
(http://www.mirandabanda.org/files/Cog/VM/VM.r2776/coglinux-13.33.2776.tgz) and Squeak (http://ftp.squeak.org/4.4/Squeak-4.4-All-in-One.zip) 3. I've got the following delays in one of my images with the fresh Cog: 0:00:00:41.598 0:00:00:26.942 0:00:00:36.862 0:00:00:32.338 0:00:00:38.316 3. I've got the following delays in the fresh Cog and the fresh Squeak image: 0:00:00:09.108 0:00:00:14.544 0:00:00:12.226 0:00:00:14.174 0:00:00:13.816 4. Still it's around 15 seconds. Image dependence is interesting because they seem to be the same versions (latest update: #12327).
uname -a Linux mglap 2.6.27.21-3.2-pae #1 SMP Wed May 20 03:21:35 CEST 2009 i686 i686 i386 GNU/Linux
cat /proc/cpuinfo ... model name : Genuine Intel(R) CPU T1600 @ 1.66GHz ... cpu MHz : 1662.478 ... cache size : 1024 KB ... bogomips : 3324.95 ...
And here are some photos:
https://dl.dropboxusercontent.com/u/37119147/all.zip
And here is the application I use to read them in: a) Create an empty directory b) Unpack all.zip to it c) Filein Anotator.st d) Run it: Anotator new start. e) Open transcript e) Choose the directory with photos f) Klik lewo (left) and prawo (right) to move from one image to another (it will create some .txt files while doing it, so it may ask you if you want to overwrite) g) see the numbers in Transcript
If you don't want to run the whole app, just run: [PNGReadWriter formFromFileNamed: '/some/path'] durationToRun
Mateusz _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Levente Uzonyi pisze:
Thanks. I found a really bad bottleneck, and fixed some others in PNGReadWriter. I have uploaded my changes to the Trunk, you can find them in Graphics-ul.275. Loading any of the png images you've sent takes 1-1.5 seconds on my machine with the new version. They took 4-7.5 seconds with the old, so the speedup is about 4-5x, which might not be enough for you. You could achieve another 2.5x speedup if your images were in RGBA format (they are in RGB now), because that way the scanline can be converted to a Form without byte level manipulations.
Levente
Thank you very much!!!
beginners@lists.squeakfoundation.org
-
Ben Coman -
Levente Uzonyi -
Mateusz Grotek