Reading PNG images into squeak image is slow

>
> 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 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
>>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

> 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
>>>
>>
>> _______________________________________________

> 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-set-to-100
> [2]
> http://photo.stackexchange.com/questions/19876/converting-raw-images-to-lossless-jpeg-using-gimp

>
>>
>>
>> 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
> [hidden email]
> 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
>

>
>>
>> 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
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

> 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
>