Reptorian's CImg/G'MIC fork thread

Software G'MIC
1

After playing with Cimg.h for some time, and now I have a slight deeper understanding of Cimg.h. I decided to announce a plan to fork G’MIC/Cimg. Now, the goal isn’t really to replace the main G’MIC at all, but rather to implement some of my ideas for the internals of G’MIC and to have a repository where they can be visited via separate branches. So, if one wants to merge a specific idea of mine, one can select a branch ‘feature_name’, merge it into local copy of Cimg/G’MIC, and then test it.

Here are some of the ideas I had:

  1. Next(), Previous() (Already discussed, and is done) - Basically they do find the previous/next representable value.
  2. Alpha-Aware Resize (Already discussed) - Optimized for resizing images with alpha, and preserves color. You can quickly see some optimization such as storing location of pixels with alpha, and then loop over that. And this is not dependent on alpha being 255 max.
# C = Color
# NC = New Color Value
# A = Alpha
# NA = New Alpha Value
# SA= Sum of Alpha
# WF = Weighing Factor

C = 85,255,55
A = 5,100,150

SA =255
WF = 1 / SA = 0.0038461538461538464
NA = 255 / 3 = 85

# To calculate NC, for each color, multiply the value of color by the corresponding alpha value. Multiply the resulting value by the weighing factor. Then, add them altogether

NC = sum(85*5*WF, 255*100*WF, 55*150*WF) =>134.01960784313727

So therefore, the new pixel value is [ 134.01960784313727 , 85 ] .
  1. Multiple-variable GCD support. - Instead of being limited to 2, one can find GCD of 3 or more variables at once.
  2. LCM - Find the least common multiple.
  3. Binary Literal support - ‘0b1111’ will be treated as 15. This makes it a little bit more visually clear of what’s going on in case of using binary operators. Done by David.
  4. ordered_set and unordered_set type - Scalar, and vector types are supported, but I have a idea to have support for these two types. Basically, there can never be a duplicate. I don’t plan to make it as flexible as Python set though I want that.
  5. Dictionary type - Another new type which allows one to dynamically adjust it, and find retrieved values via treating numbers as key. Would be useful for cases where one wants to emulate dictionary though you can do that in G’MIC outside of math evaluation easily.

That’s pretty much it. I think I can do all of that except the new types system which will take a while to figure out.

EDIT:

There’s few more I had in mind, but I don’t think I"ll do it.
Factors - Even though I had made this via G’MIC using prime factorization, I think it would be nice to have a native implementation of it instead.

And I’m not sure about these ones:
Numbers combinatorics library - All of this has been done via G’MIC within my gmic-community file. I have permutations, combinations, repeated combination, repeated permutation, and Cartesian Product. They’re more flexible than anything that’s out there because you can do it for all of the rank, or just one rank without having to calculate previous ranks.
String combinatorics library - This is one I’m actively looking at making via G’MIC. But, it’s a bit hard to resolve some issues for now and I’m not sure if doing this via C++ would make things easier.

2

This is a good idea. I’ve added it with commit:

For the other stuffs, I’ll watch what you do closely, in case some things can be included in the official CImg/G’MIC packages.

1 Like
4

Wow, I’m struggling super hard learning git. I really hope I didn’t screw up with CImg. Yes, I used -f to try to change my own branch with all the struggles, and I hope nothing bad happened. @David_Tschumperle .

Basically, I struggle to delete a branch. And now I just figured out how to clone only a branch. I only want the develop branch.

5

With git, this is almost impossible. If you screw up, you can always define a branch at your last known good commit, no matter how far back that commit may be. When you switch back to that branch, the contents of your working directory revert to exactly how it was at the moment of the commit. So:

  1. Commit frequently.
  2. Comment the commit (A “.” comment is a bad! practice. You are depriving your future self of significant development information. One or two simple sentences suffices. Your future self will appreciate the insights and reminders of things done months or years from now.)
  3. Never initiate change on the main/master branch. No matter how small or straightforward the change may be, branch, give the branch a meaningful name, switch to it, then initiate the changes, committing frequently to that branch as you go along. Don’t merge the branch back to main until its golden. The main branch is to be kept as stable as possible. Branches off of main are for exploration, experimentation, and royally screwing things up.
  4. If git is giving you a hard time about deleting a branch, then don’t delete the branch. Think first. Git is telling you that there are unique assets on that branch, which are no where else, and it is trying to prevent you from doing something rash. So don’t do anything rash. Do git log and read your commit comments, which are meaningful and useful because you have abandoned the treacherous “.” (dot comment). Of course, if you haven’t abandoned dot comments, then you have painted yourself into a corner. That’s not fatal. Your next recourse is to git diff against various commits to recover the intelligence that a nicely worded comment would have conveyed to you — quickly! — had you not used dot comments.
  5. Did I tell you not to use dot comments?
  6. If still in doubt about deleting a branch, then don’t. Just don’t. It’s not hurting you. It can hang around forever, and may be useful to refer to from time to time. Just locate a commit from which you can launch another series of changes, declare a branch off of that commit and switch to it. Remember, you can root a branch at any commit. Every time you commit, you create a place where you can root a branch — from anywhere, at any time. Every commit is a snapshot to which you can return to, if need be, and start off on another branch. By the way, any number of branches can root at the same commit.
  7. Go to the git-scm web site and Read the Book. Branching in git is powerful and light-weight, because it is based on a scheme of placing markers in a tree of diff-objects, and does not involve file copying, as what older version control systems are wont to do when creating branches. When i read “I just figured out how to clone only a branch,” I can only sadly shake my head and report: “No, you haven’t figured it out”, because branching does not involve cloning, or copying. Branching in git is a method of designating a commit point in a tree of differences as a new point of departure from that commit. You can run along that branch until you have something that is golden, then merge it into the parent branch, or abandon it and designate some other commit as a new, fresh starting point.

Notice that I write of “git”, and not “github,” which is a web-based wrapper around git. I don’t use github-based repositories other than targets to pull from or push to. Pull requests between github based repositories is straightforward, so I keep mirrors of my projects there, but i find using git directly on a local repository to be far more straightforward.

1 Like
6

Don’t take the following too seriously! I’m just playing devil’s advocate. But nevertheless…

A list of “best practices” is indeed very useful for people discovering a new software or programming language. But experience shows that there are always specific cases where you can reasonably deviate from these “good practices” without showing any incompetence.

Two examples come to my mind:

  • Tip: “Never use goto in your source code, it’s bad practice !”.
    Reality: You’d be surprised how many talented programmers use goto for good in their source code. People who’ve never written assembler code in their life won’t use goto. The rest know how to code :wink: (and will eventually use goto when necessary).

  • Tip: “Write long comments when you commit something in your git repo!”
    Reality: When your git repo is written only by you and when you use it basically as a convenient way to archive your source code “in the cloud” and nothing else. Then why matter with writing commit comments ? Don’t do that for collaborative repositories of course!

Anecdote:
I once completely deleted my gmic repository from github and created a new one. Someone wrote to me in the forums “Sorry for your loss!”. I was shocked!
Does anyone really think that the G’MIC project really depend on the services offered by github, a company offering a proprietary service, bought out by Microsoft?
Fortunately not! I’ve had no loss except perhaps the messages from the issues, but which had been stagnant for months anyway. Tomorrow, I can migrate from github to something I find more convenient to use, and it won’t have any impact.
Basically, I use it only as a way to archive my source code somewhere, rather than putting it on a USB key…

1 Like
7

There are rare times I wish for goto in G’MIC, but then I figure out solutions without it. Making the GUI version of Lavander Binary Map was one of those times.

8

I just came with another idea. Built-in Prime Factorization of numbers. I see that LCM can be calculated with prime factorization, and my G’MIC implementation of finding factors use prime factorization. Maybe not. But, definitely looking forward to see LCM in G’MIC.

9
1 Like
10

Ok, I’m reading this code.

And understanding where’s my mistake lies in. I don’t know what this thing is called ‘something.function()’ is called, but it seems to me that first there’s a initialization of whatever that thing is called. And the rest seems to be copying numbers into an array, and it outputs on .gcd() call.

Well, something like that, but just can’t put the words to it.

11
12

I tested both gcd(), lcm() as well binary literals, and they all work really well. Thanks.

13

@Reptorian arrived with a (pitch)fork and @David_Tschumperle said good idea. If only the rest of the world were as amicable. Joking aside, thanks everyone!

1 Like
14

Decided to come back here. I just have a couple of idea.

  1. As I read CImg code, I suspect G’MIC has builtin mechanism to resize memory array to fit in all data in doubles. So, as such it would seem difficult to implement set as it is in now without resorting to something like mem_set and a whole list of #define and functions specifically for set(). Probably not very feasible without years of work, debug, and testing.

2. I’m thinking of implementing clz, ctz, etc. Might be useful for something like Lavander Binary Map.

  1. Maybe some BIGINT support that converts to an array representing unicode of numbers. I don’t see it useful for math parser fill/eval, but I can see it useful as a separate evaluation tool.

  2. Clipboard support. I have yet to figure out how to trigger #ifndef in Visual Studio. But, dacap clip.h seems to be the most feasible library to implement.

1 is hardest.
2 is super feasible.
3 is more feasible than 1, but not very. I been making some BIGINT thingie in G’MIC, but it’s just not ideal. Less than ideal, even. But, I do find it useful to have in some cases.
4 is nice. Might even allow for a bridge to communicate between coding languages in G’MIC.

Changed my mind on 2. I see only few case where it’s helpful, and they can be implemented anyway in G’MIC math parser. At best, std::bitwidth can be used to replace the annoying int(log2(n)+1) technique. Maybe I’ll implemented digamma.