PHP Fatal when trying to convert a jpg image

[kidonsky]

Installation :

I cloned the repo on Fedora 31 and I installed php 7 with php-gd

Problem :

I can not convert a big jpg image the command line php img_conv_core.php "name=wallpaper&img=my_image.jpg" Where my_image.jpg is 72kB ends with :

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 21570880 bytes) in lv_utils/img_conv_core.php on line 339

A conversion for a 31kB image is working.

---

EDIT : With another jpg file of 15kB :

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108872 bytes) in lv_utils/img_conv_core.php on line 451

(same error but line is different)

[kidonsky]

Not used to PHP, I resolved my problem by increasing memory_limit in php.ini.

Maybe a related comment can be add on the Readme ?

[embeddedt]

Good idea. I've added a note here: https://github.com/littlevgl/lv_utils/commit/70f553e2b7d13ef3e9a88683ba4d8689330ec2e3

[kisvegabor]

I've added a minor clarification: https://github.com/littlevgl/lv_utils/commit/ec7d2676b36a27fa13b21162aca1476ad8456ec5

[kidonsky]

Perfect, thank you.

P.S. : I encountered this error on the website too with a 100ko file and option True color. Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 134217736 bytes) in /web/littlev/littlevgl.com/tools/img_conv_core.php on line 451

[kisvegabor]

I've already set the PHP memory to the maximum value on the server. :slightly_frowning_face: Probably the script can be optimized to use less memory.

[embeddedt]

@arnold0kang @kidonsky I notice that both of you had this problem with JPEG files. Do either of you get the same error if you convert a PNG file instead?

[kisvegabor]

@puzrin just rewritten the font converter in Node.JS. I wonder if we could do the same with the image converter. It should be much more simple because it needs only export a byte array from the images.

Do you also think it'd be worth to be rewritten in Node.JS?

[puzrin]

That's doable via canvas in browser (without server at all) or node-canvas in cli.

[kisvegabor]

Do you mean it could be an offline tool?

[puzrin]

Could you clarify meaning of term "offline"?

• CLI - "command line interface"
• "serverless" - static page for browser, working without additional server requests.

I mean, your task has noting special to require specific image decompression software. All can be done via Image() (to load file) and Canvas (to extract raw rgba), if we speak about JS. But since nodejs has no DOM, it will need node-canvas package, implementing "missed" features.

This can work both as CLI and as browser page (~ the same way as convertor is organized now).

[embeddedt]

I think a static, serverless page should be fine. I don't see a case where someone would want to use a CLI version. It would also simplify the code (as there would be no need to include any extra node libraries).

If @kisvegabor agrees I would be happy to rewrite the image converter, but not in the next few weeks (I'm quite busy at the moment).

[puzrin]

I don't see a case where someone would want to use a CLI version.

IMO anyone who uses CI, will select CLI version. Manual conversion via website is a bit retro style :).

Just a simple example - when you create tests with screenshots, it's convenient to keep original fixtures as images, and regenerate to C on update.

It would also simplify the code (as there would be no need to include any extra node libraries).

You've seen font convertor project. IMO there is no difference how many dependencies to add.

[embeddedt]

IMO anyone who uses CI, will select CLI version.

Good point. I didn't think about automated testing. A CLI would definitely be easier to automate.

[puzrin]

If you wish, i could do this in exchange to font decompresser rewrite. That may be more simple for all. And lvgl will get two improvements instead of one :).

I can do everything except styling: CLI + web form (~ the same as font convertor).

[kisvegabor]

I've also used CLI when I needed to convert 50 images. I wrote a script to convert all images from a folder.

@puzrin

If you wish, i could do this in exchange to font decompresser rewrite.

My problem is that I don't think RLE decompression can be almost free as you mentioned. So you need to convince me first about it's possible to make a big improvement here. :stuck_out_tongue:

IMO because you need to process the data on bit-level you can't avoid the cost of bit read and write. Earlier you suggested reading/writing 32-bit variables. It's really faster to read/write them but the bits still need to be extracted and written back.

Besides, I'm fully engaged now with the new styles, so even we find a reasonable way to improve decompression, I couldn't start to deal with it in the near future.

However, if it's really possible to make it better and I'll have time for I'll do it anyway without a "deal" too.

@embeddedt

If @kisvegabor agrees I would be happy to rewrite the image converter, but not in the next few weeks (I'm quite busy at the moment).

Of course, I agree. I believe both of you can do it right, so I'd be happy if any of you do it :slightly_smiling_face:

[puzrin]

IMO because you need to process the data on bit-level you can't avoid the cost of bit read and write. Earlier you suggested reading/writing 32-bit variables. It's really faster to read/write them but the bits still need to be extracted and written back.

I described how to process bits with "blocks" & via cheap operations & minimized registers use. That's a main difference. Another options could be to disable prefilter to avoid second pass (spec of bin format supports this).

We have a bit differend start points in this question:

• You say, you need proofs why improvements are possible.
• I say, code should be "normalized" first, to apply well known RLE decoding approaches. Because discussing non-normalized code is reinventing wheel and ineffective spend of time.

[kisvegabor]

Let's continue the decompression topic in its issue.