Yes, that’s the point. Basically, what I wanted to with stimulating hardware restriction is to force the end image to contains x amount of numbers of colors per tiles. Many older hardware has x colors per tiles restriction. The only issue with hardware restriction stimulation is the G’MIC speed of generating it. Just very slow.
Could be faster if you did it in a piece-wise fashion, saving temp files along the way. I have been meaning to explore this or at least ask about it, but alas, I don’t have time or energy to do everything that I want to do. 
Guess, what, I believe I am now ready to update my transfer color reduced or almost ready as everything is figured out. I changed _pal_i a bit so pal db32 = pal db32 pal -1 = pal db32 pal i
That picture looks terrible, but that’s what you probably get for emulating old system. You can see obvious hardware color restriction, and you can see that the pixels are not in 1:1 ratio.
From experiments, I think it’s a little too difficult to work with 14 variables. Best to use this with GUI.
EDIT: Better picture with C64 palette
EDIT: Fixed boundary. There’s a bug which I have no explanation for though. This filter does not always work on images, it seems to like images with more colors. When it doesn’t work, it throws out needs two layers error, and I am utterly lost at explanation for that. Then, there’s the issue of alpha. I’ll probably have to work a bit more with the alpha.
@David_Tschumperle Never mind, I fixed the bug. That was a difficult one.
Ok, I fixed the lctwp command. It’s changed to pal_t, and I added a way to enable hardware restriction on the alpha. Though with two hardware restriction stimulation, you are going to need a good PC to see it quickly. $4<2 is now allowed, 0 or 1 disable alpha while 2 or more enable alpha. Disabling alpha is ideal if you don’t need it to stimulate older hardware. I think now I’l going to wait till 2.5 is released to create a transfer color reduced replacement with the pal_t cli, or maybe I might try to experiment with the new G’MIC dynamic GUI filter soon.
Hmm, hardware color restrictions is definitely taking too long. Should I have multi-level of indexing instead instead of doing square by square? What this does is group by boxes of colors, apply indexing to each images, and then merge the result back again. Would be faster, but much harder to code. at “autoindex something,something,something”,5,5 speed generation is not acceptable. It takes me like 10 minutes to generate for a 500 px square image.
I have just solved the hardware restriction issues! Now, to wrap it up and update the pal_t filter with a much faster hardware restriction emulation.
There is only 4 colors per every 5x5 tiles. Time to render in preview in my pc. 20 seconds. The older method - 15 minutes to generate (can’t see in preview basically). It’s usable now and gives far more uniform result.
This is my take with resizing only (<1s). Results change depending on how I tweak the parameters.
Can you specify how many colors per x*y tiles with your technique? the <1s finding beats my version. I had to create two version for my pal_t script.
Here’s my version
#@cli pal_l :
#@cli : Convert palettes to layers
pal_l :
repeat $! l[$>]
_iw={w}
if {h=1} repeat {${_iw}-1} [0] done repeat ${_iw} crop[$>] $>,0,$>,0 done else v + error "This is not a palette!" fi endl done
#@cli ahre_rgb: (eq. to auto_hardware_restriction_emulation_RGB)
ahre_rgb : auto_hardware_restriction_emulation_RGB $*
#@cli auto_hardware_restriction_emulation_RGB : precision_factor>1,tile_size_width>0,tile_size_height>0,colors_per_tiles>0,0>=dithering<=1,color_mapping_method [0 = median-cut | 1 = median-cut and k-means]
#@cli : Emulates hardware restriction automatically being based on the image.
auto_hardware_restriction_emulation_RGB :
repeat $! l[$>] remove_opacity to_rgba repeat $1 [0] done l[$1] +colormap $1,0,0 at[0] "s c f "ia" a c",$2,$3,,,,,3 index.. .,0,1 pal_l. r[1-{$1}] {w#0},{h#0},1,4,1 l[0] repeat {$1-1} [0] done endl repeat $1 l[$>,{$>+$1}] f[0] "i#0==i#1?255:0" endl done k[0-{$1-1}] to_gray endl to_rgb[0-{$1-1}] repeat $1 a[$>,$1] c done repeat $1 l[$>] +solidify 0,0,0,0,0 blend normal endl done ac "autoindex $4,$5,$6",rgb blend alpha to_rgb endl done
EDIT: Now, I updated via g’mic community. pal_t is ready for testing. Here’s a result with hardware restriction stimulation.
Looks really antique as a image. With a few edit, it’ll be looking accurate as an antique looking image. Hopefully all goes well, and if the cli command works, I’ll turn it into a gui filter.
EDIT: Also, I compared result with its android equivalent 8bitphotolab, and it turns out that 8bitphotolab wins by its trickery. G’MIC pal_t downscale, android 8bitphotolab keeps the image sharp somehow without needing to downscale. Plus, for some reason, there is no explanation whatsoever as to why cga11 with hardware restriction enabled seem to erase a color.
cga11 is cga mode 1 high
EDIT: May I need to start this filter all over again. 
EDIT: I am finding that treating cga as a luminance gradient map before assigning pal_t fixes the issue with cga 4 colors modes. Maybe, I would have to add a condition to assign colors based on clut before that. Also, I might have to find a way to recreate the looks of 8bitphotolab. So conclusion, not ready to move on to making the gui filter yet. But, you’re welcome to test the new pal_t to see if I need more suggestion.
Edit: Might add upscale nearest neighbor method for pal_t. That’s what 8bitphotolab does to make it look good.
So new features will be:
- Pixel upscale
- Luminance to gradient based on 3-6 colors palette (if applicable) or by clut transfer - Makes it better with cga series.
EDIT: I have just added upscale option, and transfer_rgb option (ain’t really interested into gradient mapping as transfer_rgb does a better job). Still doesn’t always fix the issue with cga11 pal at times.
1 Like
Now, the GUI filter version is happening, and it’s dynamic as well! At long last, the pal project is about to be finished.
So, when you disable hardware stimulation and/or pixel ratio or swap Method of Color Transfer, options will either disappear or be grayed out.
That being said, @David_Tschumperle I would like to document the pal commands for g’mic reference seeing it’s a noticeable new feature that could be of use for some filter writers in the future, would that be ok? Though, I do think that it needs testing before documentation to see if anything is at a wrong place or how it can be improved. I did swapped $8, and $9 on pal_t recently since it makes more sense to have 0 before the other pixel ratio variables if you want to disable it.
What can be documented at the moment
pal input_number or pal id - This generates palettes, pal -1 or pal i converts one of the two images into a palette if possible
pal_l - convert palettes to 1x1 pixel layers
pal_t only needs $8 and $9 variable swapped before it can be documented
EDIT: The GUI filter has been finished! The older transfer color reduced filter is replaced with a new version with more features. Hopefully, it’ll work fine and dandy when using it correctly as it how it suppose to be. I’ll check if it works after it is pushed though because of the way that I’m patching things from my end to github end, so I don’t know if it’ll work like in my computer. That was a very difficult project.
I received a bug claim where my emboss-relief filter does not work with relief mode set on inside GIMP. As I do not use GIMP nor has G’MIC installed there, can someone confirm? Use the latest version of G’MIC though and click update.
Sorry, I cannot check. I have an older plugin version.
Hello,
Here are my specs:
Windows 10 (64 bit)
Gimp 2.10.4
G’MIC 2.5.3
As soon as I click on Ok to try the filter:
Reptorian > Emboss-relief (standard default: no change applied) an error always pops up:
*** Error in ./fx_emboss_relief/*repeat/*local/ *** Command ‘l’: Invalid selection [-2] (contains index ‘-2’, not in range -1…0)
Afterwards, the g’mic window with the filter disappears (crashes?) and I am back to GIMP. Needless to say the filter is not applied on my image (1 single layer)
BTW, this filter has no short description and I do not know what it is supposed to do, altough, from its label, I suppose it should apply some sort of embossing on my image
It’s based off Paint.NET embossing/relief technique. Hmm, it works fine and dandy on Paint.NET and Krita. I guess I’m gonna have to change the code on the filter to make sure that it works on all of those softwares. Though, the fact that it works on Krita and Paint.NET just fine, but not on GIMP concerns me into thinking I may have stumbled into something here. I guess I’ll have to find a way to install GIMP and G’MIC inside Windows to verify that changes to code works. @David_Tschumperle - Is there a bug within GIMP G’MIC side of thing?
Hello @Reptorian,
There is something weird going on with the 3 links you provided in your previous message, namely “Paint.NET”
On every one of them when you click to open the corresponding web-page you are directed to this web-page: http://www.warrenpaint.com/index.html
On the contrary, if you right click (copy web-link command) with your mouse on these 3 links you get the correct web-page, that is: http://paint.net/
I have tried with Firefox 66.0.1 (Windows 10)
EDIT: strangely enough, this occurs even with my own current post.
I am always pointed to the standard and architecutal web-page whenever I click on the Paint.NET link. Not the paint.net web-site…
Just ignore that. I didn’t intend to provide a link. Paint.NET is a software. I dislike using the name for this reason. The actual website is https://www.getpaint.net/ .
Here is something that seems to work with Gimp :
#@gui Emboss-ReliefTEST : fx_emboss_reliefTEST, fx_emboss_reliefTEST(0)
#@gui : Enable Extreme Emboss or Relief? = bool(0)
#@gui : Angle = float(0,0,360)
#@gui : Depth (%) = float(100,0,500)
#@gui : Depth (%) = float(100,0,5000)
#@gui : Smoothness = float(0,0,10)
#@gui : Invert Embossing? = bool(0)
#@gui : Preserve Alpha? = bool(1)
#@gui : sep = separator(), note = note("Relief Section")
#@gui : Apply Relief? = bool(1)
#@gui : Blending Opacity (%) = float(100,0,100)
#@gui : sep = separator(), note = note("<small>Author: Reptorian. Latest Update: <i>2019/3/19</i>.</small>")
fx_emboss_reliefTEST :
split_opacity
if $8
+em {$6?$2+180:$2},{$1?$4/100:$3/100},$5
blend grainmerge,{$9/100}
else
em {$6?$2+180:$2},{$1?$4/100:$3/100},$5
blend grainmerge,{$9/100}
fi
if $7
a
c
else
k
fiEarlier comment removed for update
@samj @Silvio_Grosso - I just made a pull request on g’mic-community though I have to admit the original was working fine on my end. Something’s probably is up on my end, then. Could you verify that it does work?
I don’t have any idea what’s going on here nor I don’t know how to fix it, so I can’t update it. It doesn’t really help that the code does work on my end of things. I had to add repeat around because the suggested code didn’t work on multiple layer, and changed a few thing because the result wasn’t suppose to look nearly white.
Let’s see here…
fx_emboss_relief : repeat $! l[$>] split_opacity if $8 +em[0] {$6?$2+180:$2},{$1?$4/100:$3/100},$5 blend[^1] grainmerge,{$9/100} else em[0] {$6?$2+180:$2},{$1?$4/100:$3/100},$5 fi if $7 a c else k[0] fi endl done
1. "repeat $! endl done" provides the way to loop the effect on each layer
2. split_opacity split into "rgb" and "alpha" layer.
3. when $8, then, add embossing layer which makes 3 layer, then blend excluding alpha layer (alpha layer is -2). 2 layer in the end. After that, you either append rgb to alpha or remove alpha altogether.
4. When not $8, em simply affects the rgb layer and does nothing else. After that, you either append rgb to alpha or remove alpha altogether.
My interpretation could be wrong, I’ll admit that. If it is, then I have no idea where.
I applied your change Emboss Bug fix for GIMP 2.10.8 G'MIC by Reptorian1125 · Pull Request #163 · dtschump/gmic-community · GitHub
then I added ‘to_a’ at the beginning of your script for images that do not have an alpha channel :
1 Like