JPG for bitmaps
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#129 JPG for bitmaps
FMSLogo does a lot of wonderful things with bitmaps. Still .BMP seems to be the only format used.
Maybe it has already be proposed or asked or even discussed: Would it be possible to add .JPG?
The reason is that even normal BMPs take a lot of storage - they are really huge, without compression. So it may be impossible to perform projects which need larger sizes, perhaps of background photos. One example is the use of ortho-photos made by planes or satellites.
JPGs lose pixel information while compressing. PNGs don't lose pixel information while compressing. Why JPGs instead if PNGs?
APNG can do 24-bit image animations, similar to what FMSLogo can do with GIF animations now.
And WEBP (developed by Google) is said to have better compression than PNG, GIF and JPG.
Yes, this has been discussed before, or at least requested as feature request 101.
JPG makes sense for loading in Manfred's use case, which is to overlay turtle drawing on top of a photo. PNG makes the most sense for both loading and saving pictures drawn with the turtle. I didn't know about APNG, but that makes sense as a replacement for GIF. I'm glad it exists.
I don't have much time for logo development these days. I'm wondering what the cheapest thing is to satisfy Manfred's use case. If I added a new primitive procedure (a breaking change) called IMAGELOAD or PICTURELOAD that could determine the file format by inspection of the file and load BMP, GIF, and JPGs, would that be enough? That is, there'd be no JPGSAVE or IMAGELOADSIZE and no support for PNG.
Daniel asked:
It's true that PNG is a lossless compression while JPEG is more or less lossy. You loose accuracy and get smaller files. Example
A bird's eye view of an entire city center
-W 16480 -H 9270 (16:9)
447.568 KB BMP
251.174 KB PNG
138.189 KB JPEG best precision
23.573 KB JPEG 66% of best precision
Even the 66%-compression still yields a really good accuracy.
There must be a reason that most cameras use JPEG instead of PNG. The compression of PNG is limited because it is meant to be lossless, and so it uses an algorithmen which is based on run-length encoding, which is only efficient if you have only a small color- or grayscale-palette. A small palette instead of full solors is best suited to PNG. For ortho-photos as we use them PNG is not the best choice. But JPEG is a good choice in this case.
FMSLogo works well even with a huge image like this. As the viewport is much smaller than the image, scrolling is necessary. FMSLogo allows soft scrolling even in this case.
David wrote:
Yes this would be a great help. Do you think that PNG instead of GIF could be an option?
It is clear that the advantage is that the asset folder can take more images before it explodes. But every image has to be decompressed before use in the application and needs the full uncompressed storage while the program runs. In the aqbove mentioned example FMSLogo works well with the full uncompressed image which exceeds the viewport by far.
This means that the performance of our FMSLogo-program does not depend on the compression, but the usefulness of the asset folder does.