JPNG

[hh]

@Mark

*** Thanks for your expertise. I couldn't do that this perfectly. ***

One of the reasons for posting this JPNG stack is to show the power of LC:
The essential code of compressing PNG -> JPNG and decompresing PNG -> JPNG
is both less than 10 *essential* lines of code, using comfortable LC tools.

It is currently "en vogue" to try using JPEG compression together with
transparency. The js- and/or objC-people have to do _a lot more_ for that.

So take my demo stack as 'suggestion for the engine', to add a JPNG format
to LiveCode with a compression parameter and an useAlphaDataOrMaskData switch.
[ Possibly also with adding JPEG 2000 (.jp2)? ]
The work is nearly done as it is already available in the engine to a big part.
And for the dictionary entry use your post ;-)

This all could contribute to make the size of standalones that contain a lot
of PNG-compressed images significantly smaller. An may also be of advantage
for a usage together with the browser widget.
Once again, with a JPEGquality of 80 I have here in average JPNG-compressed
sizes of 30% compared to the original PNG-compressed sizes.

[I'll update the JPNG stack today for use on RaspberryPi 2/3 (and in LC 6/7).]

====
Mark wrote:
> On 2017-08-11 09:29, Richmond Mathewson via use-livecode wrote:
> > In theory that sounds both impressive and useful . . .
> > 
> > But, what, apart from your stack can read the format/compression
> > method properly.
> 
> I think Hermann's suggestion is a bespoke way of reducing resource size 
> for built apps and their content - as there isn't a 'standard' for JPNG 
> (yet) it isn't really useful for interchange between apps, but it might 
> be that a standard does appear at some point.
> 
> > Can your stack export a JPNG image?
> 
> It doesn't need to in order to be useful. This is something which could 
> be used at the point of building a standalone (in a standaloneSaving 
> handler, for example) to convert PNG images into a smaller form for use 
> by the app at runtime.
> 
> > "This may even result in a larger data size than the original when
> > decompressing."
> 
> I'm not sure I quite understand that comment...
> 
> Any (loss-less) compression algorithm will produce output which is 
> larger than the input for some inputs 
> (https://en.wikipedia.org/wiki/Lossless_compression#Limitations). So all 
> (such) compression algorithms tend to have a flag in their encoded 
> output which says 'this is not compressed'. When the compressor runs, if 
> the output is greater in size than the original input it just emits the 
> output with that flag and the original data. (In this case, if the JPNG 
> process produces a data size larger than the original PNG, just use the 
> original PNG!).
> 
> In this case the JPNG idea exploits the fact that color images tend to 
> withstand data-loss, but alpha data (masks) do not - JPEG is lossy, it 
> removes information which our eyes cannot see. PNG compression (a 
> variant of gzip IIRC) is loss-less, it preserves the exact values of the 
> inputs. So you use the lossy method (JPEG) on the part of the image 
> which makes no difference to our eyes, and the loss-less method (PNG) on 
> the part of the image which our eyes would notice a difference in.
> 
> Warmest Regards,
> 
> Mark.