JPNG

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JPNG

** Clarence P Martin ** via use-livecode
JPNG (named using JPEG and PNG) is not an image format but a compression method.
We use the file ending ".lcjpng" for that.

It takes features from both JPEG (setting JPEGquality to compress the imageData
and from the PNG compression the alphaData/transparency). It saves the alphaData,
optionally the maskData, and the JPEG-compressed imageData in one file. The
JPNG-compressed image has here, using a JPEGquality of 80, around 25% of the
PNG-compressed size.

So this may be interesting for people who wish to compress (significantly in
size) the PNG-images containing transparency in their stack/standalone and
decompress only some images for "current" use.

Compression/Decompression is very fast.

See stack "JPNG" via the "Sample stacks" of the LC toolbar or (slower) here:
http://livecodeshare.runrev.com/stack/841/JPNG
This sample stack compresses to files or to (numbered) custom properties.

Note: I don't use the JPNG data structure of js or objC, but you can easily
convert it to that.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPNG

** Clarence P Martin ** via use-livecode
In theory that sounds both impressive and useful . . .

But, what, apart from your stack can read the format/compression method
properly.

Also, for the sake of argument: LiveCode can export images in the .PNG,
.JPG, .GIF and the (horribly obscure ?) .PBM formats.

Can your stack export a JPNG image?

And, if, so; what will read it?

AND this:

"This may even result in a larger data size than the original when
decompressing."

doesn't bode well.

Richmond.

On 8/11/17 2:56 am, hh via use-livecode wrote:

> JPNG (named using JPEG and PNG) is not an image format but a compression method.
> We use the file ending ".lcjpng" for that.
>
> It takes features from both JPEG (setting JPEGquality to compress the imageData
> and from the PNG compression the alphaData/transparency). It saves the alphaData,
> optionally the maskData, and the JPEG-compressed imageData in one file. The
> JPNG-compressed image has here, using a JPEGquality of 80, around 25% of the
> PNG-compressed size.
>
> So this may be interesting for people who wish to compress (significantly in
> size) the PNG-images containing transparency in their stack/standalone and
> decompress only some images for "current" use.
>
> Compression/Decompression is very fast.
>
> See stack "JPNG" via the "Sample stacks" of the LC toolbar or (slower) here:
> http://livecodeshare.runrev.com/stack/841/JPNG
> This sample stack compresses to files or to (numbered) custom properties.
>
> Note: I don't use the JPNG data structure of js or objC, but you can easily
> convert it to that.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPNG

** Clarence P Martin ** via use-livecode
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.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPNG

** Clarence P Martin ** via use-livecode


On 8/11/17 11:13 am, Mark Waddingham via use-livecode 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.
>
It may not, but the stack does export images with a .lcjpng suffix . . .
and the question is what for?

Richmond.

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


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPNG

** Clarence P Martin ** via use-livecode
On 2017-08-11 10:41, Richmond Mathewson via use-livecode wrote:
> It may not, but the stack does export images with a .lcjpng suffix . .
> . and the question is what for?

Perhaps so it can be loaded again by code which knows how to decompress
them as images in LiveCode? After all you have to *store* resources
somewhere, disk tends to be quite a good place ;)

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPNG

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
@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.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...