Jump to content

Reptorian's G'MIC Code Workshop


Reptillian
 Share

Recommended Posts

  • 2 weeks later...
  • 1 month later...
Posted (edited)

G'MIC 3.1 is about to be released. Serendipitous Circle will be available. There is also an upgrade to Popcorn Fractal [Transformative].

 

Here's the upgrade output:

 

230343d65b25ae92490724dfe0cfd28760410ec3

 

 

Edited by Reptillian
  • Like 2

G'MIC Filter Developer

Link to comment
Share on other sites

  • 2 weeks later...
Posted (edited)

Thank you, @Ego Eram Reputo and @lynxster4.

 

Another update I have for now, and I know it's not much. I upgraded Premade Palette for when 3.1 comes. There has been some changes to workflow. In addition, you'll have the option to export palettes.

 

Note this when G'MIC 3.1 arrives, look at filename before export because Windows doesn't support certain characters. Regardless, most of them will export successfully. I should probably find a way to address that though.

Edited by Reptillian
  • Like 1

G'MIC Filter Developer

Link to comment
Share on other sites

1 hour ago, Reptillian said:

I should probably find a way to address that though.

 

The list of reserved characters in Windows file/directory names can be found at: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions

PdnSig.png

Plugin Pack | PSFilterPdn | Content Aware Fill | G'MICPaint Shop Pro Filetype | RAW Filetype | WebP Filetype

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language. ~BoltBait

 

Link to comment
Share on other sites

Posted (edited)

Thanks @null54, I managed to address that issue. It's unlikely these characters will be used. And the allowed convention for Premade Palette name is compatible with most OS except Mac OS 9 due to character count limit.

 

On Premade Palette, I have a question for users here. When 3.1 arrives and you are using Premade Palette, you will note this message: "96 Colors Restriction Exceeded! Disabled Export!" when a palette containing more than 96 colors is selected. Should this export block be disabled or should it be overridden by allowing split before export? There's also other palette format that doesn't show the message such as GIMP .gpl, and JASC_PAL.

 

This isn't something that's hard to address.

Edited by Reptillian

G'MIC Filter Developer

Link to comment
Share on other sites

Posted (edited)

Another change that will come in 3.1 is full-sized preview. This would make it possible to have accurate Hitomezashi and Mitchell Concatenation preview. I will look at other filters that need it.

Edited by Reptillian

G'MIC Filter Developer

Link to comment
Share on other sites

  • 2 weeks later...
On 4/12/2022 at 6:58 AM, lynxster4 said:

When's the ETA for 3.1 @Reptillian?  Thanks.

Now, we have an answer. He said that full-size preview option for gui filter will have to be ready before release of 3.1. So, it'll be this month or the first week of next month give or take 1 week.

  • Like 1

G'MIC Filter Developer

Link to comment
Share on other sites

Posted (edited)

Hitomezashi has been upgraded with full-size preview support that arrived in 3.1. It is wonderful to use. I also fixed a bug there. It's not perfect yet, I will have to talk with @G'MIC about improving the cropped viewport.

 

EDIT: More accurate preview for Serendiptous Circle. Precursor to a upgrade soon.

Edited by Reptillian
  • Like 1

G'MIC Filter Developer

Link to comment
Share on other sites

  • 2 weeks later...
Posted (edited)

There's not much update for now. Just some news.

 

Vibrato and OOBS are going to be updated. Gimpchat users seem to like them. It is not known when I will do that.

 

Certain Plans:

Add white background support for Serendipitous Circle.

 

Upgrade Transfer Color [Reduced Color].

Edited by Reptillian
  • Like 1

G'MIC Filter Developer

Link to comment
Share on other sites

  • 2 weeks later...
Posted (edited)

Made some work on Transfer Color [Reduced Color].

 

It is turning out to be a difficult project. Not because dithering is difficult, and it isn't. It's finding how to make window-based dithering work. And for this one, I have to use multiple dithering algorithm. A simple dithering algorithm was used to aid in finding colors, and then the JJN dithering was used on each window. The other difficult part is to make dynamic code based on condition.

 

Here's a picture of progress:

 

b844de5f87ccba569e2390eda5ceb7825cf0884f

The evidence is given by the fact that you see square set of dots. That shows dithering is based on windows size. This is important to emulating old hardware graphics.

Edited by Reptillian
  • Like 2

G'MIC Filter Developer

Link to comment
Share on other sites

  • 2 weeks later...

Some progress has been made in the update. Also, stuck on finding an appropriate algorithm for finding nearest color for ordered dithering.

 

That being said, I updated Bit-Plane Shuffler. I know that isn't much, but it is now possible to blend multiple layers and rearrange in any order with ease.

 

I made few commands to deal with generating lexicographic order at specified index, and predict which index contains an order. This is why the update is mentioned as it is a prelude to possible new filters.

  • Like 1

G'MIC Filter Developer

Link to comment
Share on other sites

@Reptillian maybe this would help? https://github.com/paintdotnet/PaintDotNet.Quantization/blob/main/PaintDotNet/Imaging/Quantization/ProximityPaletteMap.cs

 

It takes a list of palette colors, and then you ask it for the nearest palette color for each color you need to find a mapping for.

 

This is the algorithm Paint.NET uses. It's very fast. It only works with opaque (A=255) colors, however.

The Paint.NET Blog: https://blog.getpaint.net/

Donations are always appreciated! https://www.getpaint.net/donate.html

forumSig_bmwE60.jpg

Link to comment
Share on other sites

  • 4 weeks later...
Posted (edited)

@Rick Brewster Thank you, I think that helps in case of having a existing palette and it's something @G'MIC has provided me a code for. I have found a even faster method that doesn't involve taking the euclidean distance to determine which color to pick in case of bit-depth reduction. Imagine that you have a int color, and a double color which is generated using a threshold map. You take the difference between those two color, and power the difference to the two, then add it back to integer color, then rescale it back. This involves assuming linear color space. This only works with 100% dithering, so I had to use linear interpolation for arbitrary dithering.

 

 

Edited by Reptillian

G'MIC Filter Developer

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...