Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve file size estimate #41

Open
eonist opened this issue Oct 16, 2018 · 16 comments

Comments

@eonist
Copy link

commented Oct 16, 2018

Issuehunt badges

GifSki is my go-to gif-app. But,,,,

Problem 馃槫

I always have to convert videos 3 times before I get close to the size I want. Changing FPS, Quality and resolution to hit the sweet spot. Which in my case is usually under 5mb.

Why is this relevant? 馃挕

I create a lot of gif videos to show how apps work etc. I host these on github, because GitHub is where work happens 馃憯. I need to be able to post these videos in GitHub comment fields etc. Github has a max limit of around 5.2mb So I want to keep my gif videos a bit under 5mb.

Thinking 馃

So Gifski is unique because it creates a unique Color-maps for each frame. Ball-park correct? So the file guesstimater of old doesn't work, you used to be able to do 256 * FramesInTotal = size. But you can't now because each frame is not defined from scratch.

Solution 馃挵

FileSizeGuestimatorPro.swift 馃槆

  1. On a background thread (at startup, and while user interacts with settings)
  2. let segmentCount = (TotalFrameCount 240/4) = 60
  3. let sizes:Int = (0..<4).indecies.map {i in GifSkiConverter.gifFrame(video:test.mp4,frameIdx:i* segmentCount).size }
  4. let size:Int = sizes.reduce(0,+) * segmentCount
  5. onBGComplete = {/*double the sampling, on each pass*/} //馃憟 rinse repeat until the size is hardned, or user changes variables or cancels
  6. Bonus point if these samples are re-used in the final conversion.

Note: This is not an easy issue and requires good Swift and macOS/iOS experience.

There is a $82.00 open bounty on this issue. Add more on Issuehunt.

@kornelski

This comment has been minimized.

Copy link
Collaborator

commented Oct 17, 2018

It's true that estimated size in the app is very rough. Because of the way GIF and Gifski work, actual size is just impossible to know until entire compression is done.

Can you elaborate on your proposed solution? I don't understand the pseudocode.

@eonist

This comment has been minimized.

Copy link
Author

commented Oct 17, 2018

IMO very rough is 0.4mb +-. When the current estimator says it's going to be 4mb and it ends up being 8mb. the next time it says its going to be 26mb. and it ends up at 3mb. To be fair: the current estimator could work better on gif movies that are more uniform, say cartoons, or nature-films. UI/UX gif animations tends to be very asymmetrical in content. You end up with a lot of whitespace etc. Anyways.

@kornelski I will attempt to elaborate

ELI5:

These are the gif frames in a final gif movie
[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]

  • It's impossible to know the final size until all frames are converted.
  • So what you do is "divide and conquer" 鈿
  • Divide the range of indices into 4 parts. then convert only the first frame in these ranges.
  • If you then multiply the size of the the 4 sizes with 4 and then sum them up you have a rough estimate.
  • To get a better estimate. Divide the entire range Into 8 parts. and get the average of these. then multiply with 2
  • The final and 100% accurate estimate is when you finally divide by 16 and all frames are basically converted and you have the correct size.
  • The point is you get incrementally better estimates the more time you wait. As each sampling pass completes.

I don't know if this is a better explanation than the pseudo code. 馃し I left some parts out of the pseudo code of course. To Keep it simple.

Let me know if you want more details 鉁岋笍

@kornelski

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2018

I think you're assuming that size of a GIF is a sum of all sizes of its frames. But that's not true. If you encode frame 10 as a full frame it will be larger than if you encoded frame 10 as a difference between frame 9 and 10. And you don't know the exact difference until you encode frame 9.

@eonist

This comment has been minimized.

Copy link
Author

commented Oct 18, 2018

@kornelski

Did not know gif animations reused portions of the previous image 馃憤 Found a small ref to that just now here: https://en.wikipedia.org/wiki/GIF . IMO It's not really relevant to this scheme though. As this scheme relies on the random chance. And You will hit equal amount of reused bitmaps as you will full bitmaps. Over time it averages out so to speak.

A simpler implementation:

  1. Immediately start the conversion process (on startup, and while user dials in the settings)
  2. When 10% is completely converted. Stipulated final size = (Size of 10%) + (Size of 10%) * 9
  3. When 60% is completely converted. Stipulated final size = (Size of 60%) + (Size of 10%) * 4

Assuming the conversion process converts linearly from first frame to last

@kornelski

This comment has been minimized.

Copy link
Collaborator

commented Oct 20, 2018

Refining of the estimate would help. However, I'm wondering how users would react to estimate that keeps changing.

@eonist

This comment has been minimized.

Copy link
Author

commented Oct 20, 2018

@kornelski You could use the current estimation but have the font be gray. Then when real estimation completes it shows the font in green. Something simple like that. Then if you dial in a different quality etc, the font becomes grey again until the real estimate completes and it becomes green. Also you can reuse the completed gif movie when you hit the convert button. The point of all this is that it would save you a lot of time saving, dragging in new files, waiting, deleting etc etc.

@sindresorhus

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2019

I would definitely like to see the estimate be improved, even if it's not perfect. @eonist's proposal will be a big improvement from what we currently got.

@sindresorhus sindresorhus changed the title File-size is always wrong Improve file size estimate Jan 17, 2019

@IssueHuntBot

This comment has been minimized.

Copy link

commented Mar 20, 2019

@IssueHunt has funded $80.00 to this issue.


@IssueHuntBot

This comment has been minimized.

Copy link

commented Apr 8, 2019

@0maxxam0 has funded $2.00 to this issue.


@ufo22940268

This comment has been minimized.

Copy link

commented Apr 16, 2019

I found this method works

  1. Generic gif file with only one image
  2. Get the size of the gif, mulply by the total image count of gif

The result is sometimes larger than the real size and sometimes smaller than the real size. And the difference will be less than 10%.

@ufo22940268

This comment has been minimized.

Copy link

commented Apr 16, 2019

I already tests for 5 video clips. And implement this algorithm in my app. If it works well, i will comment below.

@eonist

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

@ufo22940268 Which 5 video clips? Gifs of screen-captures are hard to predict with just 1 frame as the basis for multiplication of .count. See earlier discussion in this thread.

@ufo22940268

This comment has been minimized.

Copy link

commented Apr 16, 2019

@eonist Taken by IPhone X.

Ok, may be it's not a good solution.

@eonist

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

It was my initial idea too. Problem is if you take videos of nature or city scapes. each frame is almost the same size. If you however take screen-captures. one frame can take 1kb and another 44kb. So we need to progressively calculate while it converts. Or that seems to be the most optimal solution. Of course it would be much better to use some sort of fast algorithm to estimate each frame before it converts to gif. But yeah. Tough one to crack. and will require some elbow grease to complete.

@ufo22940268

This comment has been minimized.

Copy link

commented Apr 16, 2019

https://gist.github.com/ufo22940268/210eab0d58828da73534313942894a16

It's the code in my app to estimate the gif size. It works good so far. I will continue to test it. Hope it will help others.

@eonist

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

Did you try it with something recorded with QuickTime screen recording?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can鈥檛 perform that action at this time.