Resources and Support
 Pixel Joint Forum : The Lounge : Resources and Support
Message Icon Topic: DB ToolBox - Grafx2 scripts UPDATED dec13 Post Reply Post New Topic
<< Prev Page  of 2
Author Message
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 30 April 2013 at 7:12pm
I've explored the palette menu again and found that there are no 2-color 'generate ramp' functions. *

That surprised me, since the inbuilt GrafX2 'spread' function is predictable but not that high quality -- just a standard 'incorrect' interpolation through sRGB colorspace. If you're interested in including it, I could work up a script that does proper linear-RGB (or linear-HSL) interpolation, avoiding the errors caused by sRGB/HSL interpolation (brightness imbalance, discoloration of certain types of ramp). Let me know what you think.

I think there could also be benefit in a 'error diffusion' ramper, when working with a restricted colorcube; for example you can see these kinds of ramps in Amiga demoscene graphics, making sure the ramp is filled out with unique colors by distorting the intermediate colors between 'exact' ramp colors somewhat to achieve an appropriate brightness-gradient.
We'd need an API to get the current RGB-cube size from GrafX2 first though. I've filed an issue for that.


*EDIT: I just found the 'Curved Colorramp' function, which is based on 3 colors according to the documentation. I find it difficult to understand. With the new lua gui stuff being added to GrafX2 (see r2053-2057), perhaps we could get a type of button that allows you to choose a color from the palette. Specifying RGB channel values directly is pretty user-unfriendly.

Currently I opt to use GPick's "Blend Colors" dialog instead and eyedrop the result into GrafX2.
I agree that 3-color ramps are often better than 2-color., since they provide more context. I'd like to do this task purely in GrafX2, I just don't find the current UI friendly enough for that.


Edited by neota - 30 April 2013 at 8:14pm
absolutely.
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 30 April 2013 at 8:25pm
What about [Palette -> Curved ColorRamps]? (Edit: ok, you found it while I wrote this :D)
It takes the two PEN-COLORS as input values, the third manual value is an optional middle point (as default it's the average of the pencolors)

And I never seen any value in HSL ramps. But I'd love to see some more scripts for Grafx2 if you have good ideas.

I don't quite understand what you are talking about in the 2nd part, are you talking about generating colors, rendering ramps or what?

"I notice you never use LAB or LCH colorspaces in the DB-Toolbox code. Is this because you've tried it and found it unsuitable, it's too hard to implement correctly, too slow, it only roundtrips 99.5% of sRGB colors intact, or what?"

There's only RGB, everything else is derivatives. I have no interest in HSL-tweaks. Brightness-correction procedures takes care of problems with plain HSL and many other things. My quest in life is to understand the true shape of RGB-colorspace...I know it's a rectangular jellyblob, but to quantify it... :)


Edited by DawnBringer - 30 April 2013 at 8:44pm
IP IP Logged
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 30 April 2013 at 8:48pm
In newer versions of GrafX2 the GUI support is becoming more sophisticated, beyond inputbox(): Object oriented GUI building, so you can have control over individual GUI elements. I was saying that because the current Curved-Colorramps dialog is rather opaque (asking for direct RGB values), it would be more user friendly if we could replace the RGB sliders with a button that would let you pick a color directly from the palette.

When I say

Currently I opt to use GPick's "Blend Colors" dialog instead and eyedrop the result into GrafX2.

I mean, when I want to generate ramps. Since GrafX2's inbuild Spread function is too low quality, and the Curved Colorramps function currently requires that you write down the 3rd color's RGB values ahead of time, this is what I presently find more efficient.

In case you were also talking about this:


I think there could also be benefit in a 'error diffusion' ramper, when working with a restricted colorcube; for example you can see these kinds of ramps in Amiga demoscene graphics, making sure the ramp is filled out with unique colors by distorting the intermediate colors between 'exact' ramp colors somewhat to achieve an appropriate brightness-gradient.

I mean for example when RGB levels is set to 16 (Amiga), but you need finer stepping  in your palette ramp than that; Altering the hue so the intermediate colors have small incremental changes in brightness, rather than simply being quantized to the nearest 'true' approximation. It would be nice to not have to do that tweaking manually, but have the ramping code take care of it.

Hope that clarifies things :)

EDIT: re: HSL ramping: yeah, I don't like it myself, but a lot of programs seem to have it, so there must be some demand. I prefer its cousin, LCH ramping, which combines accurate brightness-interpolation with more interesting/painterly hue interpolation.


Edited by neota - 30 April 2013 at 9:08pm
absolutely.
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 01 May 2013 at 3:20pm
I mean for example when RGB levels is set to 16 (Amiga), but you need finer stepping in your palette ramp than that; Altering the hue so the intermediate colors have small incremental changes in brightness, rather than simply being quantized to the nearest 'true' approximation. It would be nice to not have to do that tweaking manually, but have the ramping code take care of it.


Ah, ok now I understand. Been thinking about this a little...and I suspect this may be a very complex problem (for a "perfect" solution).
A simple solution (for starters) would be to treat a limited colorspace as a palette (ex. Amiga 12bit = 4096 colors) and make a brightness-weighted colormatching for the values of the ramp. Error-diffusion would only enhance errors in the ramp...even iterative "check ahead" operations (inverted ED) could prove futile, since a single bad segment is enough to spoil things. I don't think there's any way good ramps can be consistently produced without tweaking the values of entire ranges, and playing on the fact that the brighter end of a ramp is less sensitive to bigger leaps in brightness.

Anyways, made a quick test by expanding the "Show AA colors"-script that does just this. These are examples from a space of 6 RGB shades (216 colors) and few 12 color ramps, with and without brightness-weighted colormatching. It looks fairly promising.

IP IP Logged
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 01 May 2013 at 6:03pm

Anyways, made a quick test by expanding the "Show AA colors"-script that does just this. These are examples from a space of 6 RGB shades (216 colors) and few 12 color ramps, with and without brightness-weighted colormatching. It looks fairly promising.


That -is- looking good. I want to point out that the greyscale ramp seems glitched, though (doesn't contain all the 'pure' matches.)

There are a few known characteristics that could improve the above matching:

* Saturation usually increases for intermediates, since it's almost never that all three channels can be increased at once and not simply duplicate an existing color. I suggest restricting the matching for intermediate colors to colors that range from a 50% saturation decrease to a 50% saturation increase.
* Some weighting by hue also could help  (to avoid situations like that green/pink interleaving, which causes noticable visual separation -- top left ramp)


Edited by neota - 01 May 2013 at 6:04pm
absolutely.
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 01 May 2013 at 7:51pm
Nope, there are no "pure" matches, only intermediate values of two points. And our only objective here is to match a color with every value, with the minimum error - many small errors are better than one big. You can't have the cake and eat it.

No, Saturation usually decreases with interpolation. But with a limited colorspace you have to use heavy brightness-weights to find any potential candidates - and they are not always close and similar (in hue & saturation)...if they were, we wouldn't have a problem to begin with :D

Hue-weight: Brightness is king, so you can't ever touch that...and if you put weight on Hue, there's only the feeble Saturation left to screw with. And how is that gonna help your grayscales? ;)

As I said, for a generic solution this is probably the best you're gonna get. But there sure could be other, more complex & dynamic methods to achieve more visually pleasing ramps.




IP IP Logged
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 01 May 2013 at 10:56pm
there are no "pure" matches, only intermediate values of two points

I presume you mean that all the 'natural' matches for the black->white gradient are not found because you are not actually interpolating between black and white (except in the first step), you're then interpolating between at least one distorted color and another, accumulating more error on each iteration. The ramp isn't a grayscale one any more. Certainly ramps that fitted the intent of the original ramp ('ramp from black to white') better could be generated by avoiding this recursive approach.


absolutely.
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 02 May 2013 at 11:58am
There's no ED etc going on here. It's a pure ramp from black to white, but the range you have over a certain number of colors may not align very well with the existing grayscale colors. F.ex if you want a 4 color ramp in a 3 grayscale space, the two middle-colors can only match with the one & same available gray. (That's why we use brighntess-weight to find more matches).

(note that logic will pick the first purple ramp, while the green-pink is much better as these colors are complementary and could mix to form gray...here some ED may actually improve things?)

Just beacuse we make a grayscale-ramp, it doesn't mean that a given grayscale in the colorspace will have to be included in that ramp. We embark on a journey in space between two colors, moving straight with constant steps, at every step we stop and look which available color is closest to us...that's the color we pick for that step. We're not plotting a course amongst predetermined colors. We might WANT to try doing that...but then we'll need to use different methods.

Note: the same logic applies to all ramps, not just grayscale ones.



Edited by DawnBringer - 02 May 2013 at 12:03pm
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 14 May 2013 at 11:08am
Experimenting with adding an isometric projection option to the geoshapes script. This would allow you to quickly get the isometric version of any (symmetrical) geometric figure.



Edited by DawnBringer - 14 May 2013 at 11:11am
IP IP Logged
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 02 August 2013 at 5:45pm
I've just made a simple tutorial which demonstrates how to use DBToolbox's fraction-based scaling to refit a too-small silhouette to the correct size:

Here is a link.



Edited by neota - 02 August 2013 at 5:46pm
absolutely.
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 03 August 2013 at 4:29am
Thanx for your hard work...but isn't that just a tutorial how to simply double the size of a brush? Something that you can do by just pressing Shift-h in GrafX2. Also note that the Fraction-scaling allows you to scale ANY fractions, like 11/7 (+57%) etc.

There's a lot of stuff behind the brush-scaling functions; too much to inform about in the interface...so there's some hidden power to explore, using different combos of settings, these f.ex:



However, these functions are not that great at smart-scaling up images at small increments like X2. Yrizoud have written a great Scale2x script (special algorithm to scale an image x2 in a neat way)... Couldn't find it at the homepage so I'll upload it Here

Edited by DawnBringer - 03 August 2013 at 4:47am
IP IP Logged
neota
Commander
Commander
Avatar

Joined: 29 January 2016
Online Status: Offline
Posts: 154
Quote neota Replybullet Posted: 03 August 2013 at 4:09pm
Originally posted by DawnBringer

Thanx for your hard work...but isn't that just a tutorial how to simply double the size of a brush?


Haha.. what?

No, it's a tutorial on how to use the fractional scaling to go from a too-small size to fit in the desired size (my example target size in the tutorial is 64x64, and the 'original size' is 39 (39x37 IIRC), so the fraction is 64/39 (164%) for my example). If I'd wanted 2x, I would have just used the shortcut you mentioned.

Would you find it clearer if I erased the values from the fraction specifier fields in the screenshot?

EDIT: I've now done this. Thanks for illustrating that people may not read the info in the first image; I'm not sure how to resolve that issue though. Since I also wrote that info out as text, maybe I should just make the text more appealing.

Possibly scale2x would have improved results, although two scaling steps would then be needed (one to upsize 2x, which is too far, and the next to shrink down to the intended size.)

EDIT3:
It looks like Bilinear+Sprite mode is significantly better than plain scaling. Makes sense now that I think about it, so thanks for pointing that out.


EDIT2: I see at some point you edited your somewhat earlier post to say
"There's only RGB, everything else is derivatives".
While I can respect making a project of exploring RGB, it would be far more accurate to say there's only XYZ, since that is the colorspace representing the actual response of our vision, which RGB is based on.

RGB is only a subset of the colors we can see, and sRGB (the usual encoding that computer RGB is stored in) is now only a modest subset of all of the colors that can be displayed on a capable LCD display.

Similarly in the interests of factual correctness I must point out that LAB and LCH are not in any way HSL derivatives - they are XYZ derivatives. Hence being actually very good at what they do, unlike HS*.



Edited by neota - 03 August 2013 at 8:21pm
absolutely.
IP IP Logged
helcril
Seaman
Seaman
Avatar

Joined: 06 November 2011
Online Status: Offline
Posts: 17
Quote helcril Replybullet Posted: 14 August 2013 at 9:30pm
First of all, DawnBringer, thank you very much for such a great work on a big amount of useful tools you made!

I have a question about SpriteAnimator script. It uses fixed number of cycles of animation. And IMHO that's not always good. I've modified it a little, so I can control the number of cycles. But that's not exactly what I wanted.

How can I modify script to make it stop when some key pressed?
(I've tried to apply some chunks of code from other scirpts, but they doesnt work, and I have no experience in lua-scripting)

Edited by helcril - 14 August 2013 at 9:31pm
IP IP Logged
DawnBringer
Commander
Commander
Avatar

Joined: 01 April 2015
Online Status: Online
Posts: 479
Quote DawnBringer Replybullet Posted: 15 August 2013 at 5:26pm
Cycles, as in number of times the animation will play, unless you stop it? Is there a reason you need to see it played a specific number of times? There's currently one free slot available for parameters, so I guess it could be added, if motivated.

In the next release the script will also be able to play anims ping-pong (forward-backward-forward...)

I've been looking into a pause function. It's possible to read mouse & keys (as seen in the 3D-palette script)...I've had some problems making a key-press work properly, but made it work decently with reading the mouse-button.

insert this code into the start-end loop:

moved, key, mouse_x, mouse_y, mouse_b = waitinput(0)
   if (mouse_b==1) then
    repeat
    moved, key, mouse_x, mouse_y, mouse_b = waitinput(0.05)
    until (mouse_b~=1)
   end   

Note however that this may interfer with scripts ability to detect the pressing of the escape-key (so you may have to hammer the key a bit to quit). Well, I'll have to investigate this issue further, as there seem to be some conflicts.
IP IP Logged
helcril
Seaman
Seaman
Avatar

Joined: 06 November 2011
Online Status: Offline
Posts: 17
Quote helcril Replybullet Posted: 04 September 2013 at 6:40pm
Originally posted by DawnBringer

Cycles, as in number of times the animation will play, unless you stop it? Is there a reason you need to see it played a specific number of times? There's currently one free slot available for parameters, so I guess it could be added, if motivated.

   It was only temporary method of solving problem with too big default 100 cycles of animation, that I could made by myself.

Originally posted by DawnBringer

In the next release the script will also be able to play anims ping-pong (forward-backward-forward...)

   That would be fantastic.

Originally posted by DawnBringer

I've been looking into a pause function. It's possible to read mouse & keys (as seen in the 3D-palette script)...I've had some problems making a key-press work properly, but made it work decently with reading the mouse-button.

   Thank you very much again for this very useful toolbox you've made.
IP IP Logged
Pixel_Outlaw
Commander
Commander
Avatar

Joined: 01 September 2005
Online Status: Offline
Posts: 3829
Quote Pixel_Outlaw Replybullet Posted: 13 January 2017 at 12:25am
I'm going to necropost the hell out of this particular thread and for very good reason.

The tile editor is freaking amazing in the latest version of GrafX2. Set your grid spacing, draw 9 adjacent squares of the same color, and then set it into tile mode. Any tile you draw on will automatically draw to the 8 adjacent tiles. It's amazingly powerful for getting continuous tiles and "breaking up the grid".
IP IP Logged
<< Prev Page  of 2
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum