Use TinyPNG API in App to Compress Thumbnails #599

New issue

Closed

opened 2018-09-16 19:55:04 +02:00 by tzarebczan · 2 comments

tzarebczan commented

2018-09-16 19:55:04 +02:00

(Migrated from github.com)

@Invariant-Change commented on Thu Jun 21 2018

Smaller Files = Faster Files, Less Storage, Less Overheads.

TinyPNG is a service I can't live without for my web development work, even after professionally compressing in Photoshop, I can still save a further 40% with TinyPNG.

Many/most content providers have no idea how to compress images for the web. With this in the LBRY app, they wouldn't have to, they would get vastly small files without having to do anything.

TinyPNG supports lossless, lossy and resizing. Lossless should be mandatory with other options being optional.

However, there is a charge, like Amazon AWS. But if it works out that you save more from smaller files then it's not only worth in terms of finance, but also in terms of having a better experience with faster files and less congestion.

The below image (thumbs.jpg) was a typical image a typical user would upload to LBRY.

@Invariant-Change commented on Thu Jun 21 2018

Example:

curl --user api:YOUR_API_KEY \
     --data-binary @thumbs.jpg -i https://api.tinify.com/shrink

@btzr-io commented on Thu Jun 21 2018

Open source: https://github.com/lovell/sharp

@Invariant-Change commented on Fri Jun 22 2018

I was going to suggest adding an open source option but didn't know of any or if they produced good results. I'll see if there is a test area for the one above and give it a go.

@alyssaoc commented on Fri Aug 10 2018

@tzarebczan should this be closed in favor of 1770?

@kauffj commented on Mon Aug 13 2018

Any optimization behavior that is logical to add to the desktop is presumably logical to add to spee.ch directly. So this should probably be a ticket on spee.ch.
If moving to spee.ch, it is decently likely this should be done locally rather than via a 3rd-party API.

@Invariant-Change commented on [Thu Jun 21 2018](https://github.com/lbryio/lbry-desktop/issues/1670) ## Smaller Files = Faster Files, Less Storage, Less Overheads. [TinyPNG ](https://tinypng.com/developers) is a service I can't live without for my web development work, even after professionally compressing in Photoshop, I can still save a further 40% with [TinyPNG](https://tinypng.com/developers). Many/most content providers have no idea how to compress images for the web. With this in the LBRY app, they wouldn't have to, they would get vastly small files without having to do anything. [TinyPNG ](https://tinypng.com/developers) supports lossless, lossy and resizing. Lossless should be mandatory with other options being optional. However, there is a charge, like Amazon AWS. But if it works out that you save more from smaller files then it's not only worth in terms of finance, but also in terms of having a better experience with faster files and less congestion. The below image (thumbs.jpg) was a typical image a typical user would upload to LBRY. ![image](https://user-images.githubusercontent.com/29914179/41731043-b639cfca-75c0-11e8-84d4-96dacee05ff8.png) --- @Invariant-Change commented on [Thu Jun 21 2018](https://github.com/lbryio/lbry-desktop/issues/1670#issuecomment-399159271) **Example:** ``` curl --user api:YOUR_API_KEY \ --data-binary @thumbs.jpg -i https://api.tinify.com/shrink ``` --- @btzr-io commented on [Thu Jun 21 2018](https://github.com/lbryio/lbry-desktop/issues/1670#issuecomment-399282743) Open source: https://github.com/lovell/sharp --- @Invariant-Change commented on [Fri Jun 22 2018](https://github.com/lbryio/lbry-desktop/issues/1670#issuecomment-399362815) I was going to suggest adding an open source option but didn't know of any or if they produced good results. I'll see if there is a test area for the one above and give it a go. --- @alyssaoc commented on [Fri Aug 10 2018](https://github.com/lbryio/lbry-desktop/issues/1670#issuecomment-412235158) @tzarebczan should this be closed in favor of 1770? --- @kauffj commented on [Mon Aug 13 2018](https://github.com/lbryio/lbry-desktop/issues/1670#issuecomment-412516084) 1. Any optimization behavior that is logical to add to the desktop is presumably logical to add to spee.ch directly. So this should probably be a ticket on spee.ch. 2. If moving to spee.ch, it is decently likely this should be done locally rather than via a 3rd-party API.

tzarebczan commented

2018-09-16 19:56:43 +02:00

(Migrated from github.com)

We'd need a way to tell the API/spee.ch whether or not the item being uploaded is a thumb, and if so, compress it in order to improve loading performance.

kauffj commented

2018-09-17 16:22:55 +02:00

(Migrated from github.com)

IMO most compression behavior should be pushed all the way to https://github.com/lbryio/lbry.

Some exceptions:

Behavior is idiosyncratic to the application
"Too costly" of some resource (disk / time / complexity / etc.)

It is also extremely unlikely that any app would use a remote service rather than whatever tool that service is inevitably using under the hood.

IMO most compression behavior should be pushed all the way to https://github.com/lbryio/lbry. Some exceptions: - Behavior is idiosyncratic to the application - "Too costly" of some resource (disk / time / complexity / etc.) It is also extremely unlikely that any app would use a remote service rather than whatever tool that service is inevitably using under the hood.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/spee.ch#599

No description provided.