Open
Conversation
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I apologize if any of this is improper, I haven't spent a ton of time with the codebase and I don't usually work on C++ image projects in general, nor have I used CMake much either. So some of this was just a bit of trial and error until I got something working.
Changes include:
main.cppintoect_core.cpp. This way bothmain.cppand the library API can use the same core functionsect_core.cppintomain.hso the library API can access itlibect.handlibect.cpp. This adds a newLibECTOptionsstruct, which is mapped to the internalECTOptionsstruct internally. The main use ofLibECTOptionsis just to provide some more clear field names, since I found theECTOptionsto be a bit confusingly named but didn't want to modify the core project more than I had to. It also adds a number of constants and enums to make using the API a bit more clear.What this doesn't do, however, is extend the existing feature set of the tool. This means that even with this API, images are expected to be loaded from disk. Having an in-memory version of these functions would be ideal too, similar to oxipng (https://docs.rs/oxipng/latest/oxipng/#functions), but this would require some larger scale changes to the rest of the project, since every function currently assumes a file is being passed around. I did not go for these changes in this PR since I wanted to keep the scope minimal and not break anything (due to my limited experience with the codebase), but if that's something you're interested in I can give it a try too.
This should make features like #107 possible. I have not done extensive testing, but I can confirm that the original CLI program builds and functions just fine on my Mac, and using the new library API I was able to write a small test program that works as expected: