Comments (11)
the same requirements need a lib .so
from gifsicle.
That sounds like the place to start for sure. I'm much more sympathetic to a PR that makes it possible to include all of Gifsicle, minus the main
function, into another program in a useful way. Such a PR might start by moving most of main
into another function. Perhaps the next thing to add would be a way to specify GIF inputs and outputs that are memory streams.
from gifsicle.
Take a look at include/lcdfgif/gif.h
and similar functions.
I won't be able to give you instruction or guidance.
from gifsicle.
@kohler I'm wondering, would you be open to PRs that help make this easier?
Right now the biggest issue I'm experiencing is that everything is all compiled into the binary. So while the gif.h
file defines many of the functions needed to use this as a library, it's not that straight forward.
For example, with ImageMagick the binary executables all utilized dynamic/static libraries of code. So while it does have the magick binary, if you delete the .la
files from the lib
folder then the binary breaks.
I believe that if we tweaked how gifsicle is built, at least on Unix/Linux, then it will facilitate easier methods to use it as a library. I have a local branch where things a configured to build a libgifsicle.la
file, this is built to include:
clp.c
fmalloc.c
giffunc.c
gifread.c
support.c
Then all the gifsicle related binaries loading this .la
file. The .h
files are also then installed on the system so that they, along with the .la
can be utilized as a system level library. I believe that if gifsicle were configured to compile like this that any other system library or tool to utilize it's function easier.
My specific goal is to eventually build a PHP extension for Gifsicle. However at this time I don't think that's easily possible without directly loading the gifsicle source into my extension and compiling them all together. However, from my experimentation, doing this method of compile does seem to make that easier to manage.
from gifsicle.
High-level comment is this would be a difficult route to go, and although I'm open to PRs, it's not super likely to achieve success. Large refactors might make it harder for me to maintain. The refactor you describe doesn't achieve very much.
from gifsicle.
I may have done a poor job explaining things, as your reply doesn't seem on the same page as my suggestion. I will try to clarify and hope it will make more sense than my first post.
I'm not suggesting a refactor in any significant manner - which is to say that I certainly would not consider my suggested changes a refactor. I'm simply suggesting a change in how the make script is setup. I think the branch I was testing this in has only a handful of lines changed in the Automake file and that's it. Everything else is handled by the build process itself.
Further I don't feel like what you said at the end is accurate in any sense at all. Here:
The refactor you describe doesn't achieve very much.
Maybe I'm just misunderstanding you though due to lack of knowledge in how you've suggested people reuse this package as a library. You said to reference the gif.h
file, which will work in theory. However, as things are now, gifsicle packages don't ship with their source code, or any published header files. Please let me know if I've misunderstood your suggestion.
If I haven't misunderstood your suggestion, then it stands to reason that this minimal effort change drastically improves the interchangeability of Gifsicle with other Unix programs.
from gifsicle.
I've created a PR(#139) as it likely will better demonstrate why I believe my suggestions aren't a 'refactor' and are in fact quite minimal.
from gifsicle.
If you're still not feeling up for this idea then no worries. I'll simply look about building my PHP extension idea with the Gifsicle code all wrapped right into it. Unfortunately this may make my end extension larger and, more importantly, would mean users could now have two different versions of Gifsicle on their system (i.e. one as their CLI/system command and the other built directly into the PHP extension).
However that's not a deal breaker for me I guess - I still think the PHP world could benefit from a Gifsicle extension, so for me it's still worth making even if less than ideal.
from gifsicle.
In my opinion a library that is only realistically useful for one set of executables “doesn’t achieve very much”. Making a library adds maintenance overhead and generally libraries have expectations of API stability. You may need to explain what you want your PHP extension to do. If you are looking to access Gifsicle's GIF writing and optimization features, the libgifsicle.la
idea you propose is not sufficient.
from gifsicle.
As Imagick is to ImageMagick, my extension would be to Gifsicle.
Imagick for PHP is a pretty simple 'wrapper' for the ImageMagick library (and commands). It's used to do all sorts of things to images within PHP that you would normally need to run via CLI. The benefit to the PHP Imagick extension, over just running the command in PHP via shell_exec
, is that it's much safer, more compatible and easier for end users to use.
By using my branch I've been able to successfully create a proof of concept (albeit in rust) that does in fact seem sufficient to utilize Gifsicle methods within another language. Perhaps my proof of concepts doesn't stretch things far enough for me to hit the issues you are expecting.
from gifsicle.
I think i'll just take your advice and forget about the idea of using Gifsicle as a static or dynamic library. Maybe there are other tools I can use for GIF manipulation within PHP instead of gifsicle, or maybe my best option is just to sync this repo into my extension at compile time and just let the PHP module include this full source.
from gifsicle.
Related Issues (20)
- name with negative number
- License HOT 1
- Script issue: `autoreconf: command not found` HOT 2
- Can i use gifsicle in wasm? HOT 1
- Crash during parsing of malformed GIF HOT 4
- Don't optimize file if result is bigger than input HOT 1
- Pink artifacts after resizing HOT 1
- Could not change --background after --crop
- After Fresh Installation fail: Must use import to load ES Module
- very import function HOT 2
- fatal error: frame selection and frame changes don’t mix
- [Help document bug] For gifsicle, the help document misses some options
- Can you set a wallpaper centered? HOT 1
- Add precise colormapping option
- Artifacts / trails when trimming HOT 2
- heap-buffer-overflow in ambiguity_error HOT 3
- FPE /home/root/sp/Dataset/Gifsicle/gifsicle_aflpp/src/xform.c:1325:49 in resize_stream HOT 3
- trouble croping HOT 1
- Memory leak on gifsicle HOT 2
- Two FPE bugs unique in gifsicle-1.94 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gifsicle.