Release of G'MIC 3.2

To answer my own question: filter update appears to happen at 6am, 12pm, 6pm what I assume is France local time (therefore CET and CEST in summer).

1 Like
  • 2022/06/16 : Release of G’MIC 3.1.3.
1 Like

I think I found a bug though I’m not sure if that is my fault. Bricks, and Array [Random] [Jumble by px] don’t work. I only checked out Bricks. The error says A ‘done’ command is missing, before return point. The thing is that there is a done. The code is literally simple to read:

gui_rep_shape_brick:

-m "MergeChoice : $""=_mode" -MergeChoice "add","alpha","and","average","blue","burn","darken","difference","divide","dodge","exclusion","freeze","grainextract","grainmerge","green","hardlight","hardmix","hue","interpolation","lighten","lightness","linearburn","linearlight","luminance","multiply","negation","or","overlay","pinlight","red","reflect","saturation","screen","shapeaverage","softburn","softdodge","softlight","stamp","subtract","value","vividlight","xor","edges","error"

foreach {

 to_a
 rep_shape_brick $1,$2,$3,$4,$5,$9,$10,$6%,$7,$8,$26

 n. 0,1

 r. {w#-2},{h#-2},100%,{s#-2},0,2,0,0

 if $5 ($19,$15,$11^$20,$16,$12^$21,$17,$13^$22,$18,$14)
 else ($19,$11^$20,$12^$21,$13^$22,$14)
 fi

 r. {($26+1)*100}%,100%,100%,100%,3

 f.. i(#-1,(w#-1-1)*i,0,z,c,3) rm.

 if $23 blend ${_mode{$24+1}},{$25%}
 else k.
 fi

}

See that } in the end? That is the done point.

It seems there is actually a problem in the update script, that gathers all sources together to build the filter update file.
In the generated filter update file, the ending } character does not appear.
I’ll try to fix that.

Fixed with:

The next updates should be OK now.

1 Like

Guess, I’ll have to wait another 6 hours.

That being said, is there anything that can be done about the 3 period in preview?

The numbers checks out. There’s a 3 periods that are ideally better off not there when it can fit. If it can’t, then period should be there, I guess?

  • 2022/06/22: Release of G’MIC 3.1.4.

I’m not too sure about this, but can g’mic search string inside a series of string? Something like:

echo ${find\ abcdef,cats,dog,abcdef,hat}
=> 2

Would be useful for your suggestion regarding my palette as I want to be able to retrieve a palette from name alone. Would also be nice if it can be use to find multiple names at once. Something like:

search_strings=dog,hat

echo ${find\ $search_strings,cats,dog,abcdef,hat}
=> 1,3

If you have a list of names images, something as:

  eval "
    repeat(l,k,
      N = name(#k,128);
      find(N,['$1'])>=0?print(k);
    )"

allows to search for a string in the image names.

That will work for single images name. However, in my case, I didn’t want images name as they’re reserved for bigger names. Here’s my solution, but it’s super-super slow.

foo:

num_of_ids,found={$#},0

$=shortened_form

repeat $num_of_ids

 short_name=${shortened_form{$>+1}}
 place=-1
 
 repeat 379
 
  t_shortened_name=${arg\ $>+1,bw,rgb,b_rgb,bw_rgb,cmy,cmyk,wcmyk,rgbcmy,1bitrgb,aurora,zenit_241,gbg,duel,hocuspocus,playpal,srb2,uzebox,kens16,kens32,kens54,aap12,aap16,aap64,aap96,aap128,aap_dga16,cheerful32,db8,db16,db32,db_iso22,dimwid17,dimwid23,edg4,edg8,edg16,edg32,edg36,edg64,famicube,juicy32,juicy56,xaiue,15pdx,20pdx,24pdx,cabana64,fant16,fant24,tf23,tfp39,faraway48,fleja_m,koni32,linearbasic,lego,lego2021,vinelinear,arcade29,arq16,atom8,blk36,blkneo,brokefac,bubblegum,cpcboy,cade15,calder8,cdbac,cgarne,dino,4l,fzteth16,indc,island16,journey,shallowmarsh26,lago_nenufar,juicy,chocolateganache,brightwinter1,brightwinter2,kawaii,xdb_01,gzxp,chrom16,piet,boltbait_matrix,material_design,thehamster_rainbow,boltbait_rainbow,scrj36,pxls_default,moderna,oak,nature55,rbypgo,new_worlds,nauris16,dynamite,interstate_28,downgraded_32,pear36,pineapple32,peach,resurrect,rosy42,slso,softy15,spec12,roarin80s,starmancer,superfuture,sunshine_35,sweetie16,calm48,optimism,taffy16,todayland,trirampo,reddit_place_2022,tropical_cone_24,vivid17,shido76,intacto,itatsi,enos16,grixel_grotto,sup8,undertones,tango,cheese,equpix15,zu32,voodo,franzston_30,night16,star29,star34,stilllife,simjpc16,acid15,battery24,clump18,cthul,crimso11,coptec,drz15,eggy15,europa,greyt,jewel,polar11,sheltzy,wyrm,yume_nikki,rube_goldberg,boomboom,g8,crayola,matriax8c,nt1h,jerrypie22,nineties_nine,on70,anb16,retrocal,punolit,luap_40,autumvil6,au15,au15y,galaxy_flame,antiquity16,mushroom,aerugo,hotel_paintings,nopal,gpy,blessing,fairydust_8,fuzz4,fairy,naji16,easter,pastel_and_darks58,pastel17,nostalgia15,ocaso,pastel,pollen8,kule,hydrangea,fluffy8,st8rb,neon_space,cyclope6,sy17,syz15,tui15,cave,psygnosia,marshmellow32,lost_century,finlal11,industrial_factory,murder_mystery,fatedestiny,vinik24,ykb22,halloween,graveyard,steamlords,frostical,deuterospill,cool_bone_7,muted_ally_6,ephemera,ink,violet_dreams,tinyfolks,old_gold_7,rosemoss,aaprad,aapmaj,dead_weight_8,mojave,pet8,pet8d,xaiue_rad,daruda,firestorm,borkfest,spicy_07,rust6,apricot,supernova7,pastry,sandy_06,illumination,nyx8,dreamhaze,oil6,regal,softdemon,sgm,midnight_ablaze,black_cherry,sunset_red,inkpink,brash_pink,pink_neon_sign_6,enchanted_purple,arch,spaceyeaster,fornaxvoid1,fornaxvoid2,pixelwave,s1_6,berry_nebula,abyss9,moonlight,moon39,h2o,magic_waters_9,bluemold,moss,deep_maze,toxic_slime,lush_green,tsunami,cryptic_ocean,marsh_madness,oxyd,pinkgreen,walking_in_the_woods,paper_8,sahara_pastell,sunflower_painting_7,arthoe7,sky5,ocean_glass,royalguard,eulbink,winter_wonderland,moon_squid,stratus,arctic_dust,clouds_sunset,lilac_skies,sea_of_fire,autochrome3,autochrome5,gb_d_1,gb_d_2,gb_andrade,gb_blue,gb_bz,gb_suburb,gb_crimson,gb_didi,gb_dirty,gb_arne,gb_easy,gb_forest,gb_hg,gb_lg,gb_nostalgia,gb_platinum,gb_kirokaze,gb_cyber,gb_wish,gb_grapefruit,gb_ice_cream,gb_rb,gb_gold,gb_choco,gb_gray,gb_space,gb_purpdawn,moon_crystal,arne4,autumn_chill,cherrymelon,hal4,hollow,lavender4,maw,voltage_warning,tritanopia,rabbit7,amiga2600ntsc,amiga2600pal,amiga2600secam,amiga7800mess,amiga7800,amstrad_cpc,apple2,atari8bit,cga,cga00,cga01,cga10,cga11,cga20,cga21,c64_pepto,c64_colodore,com_vic_20,colecovision,jmp,mac2,mac8,msx,nes,pico_8,risc,samcoupe,mo5,trs80,virtualboy,vga,win95,zx,gnome32,elc22,chip16,deluxepaint,flat_ui,makecode_arcade,oekaki,lms,msxp,vis,humanfaces,madjikhsv,st24_christmas,ladybugreds,dullish_rainbow}
  
  if '$short_name'=='$t_shortened_name' echo $> break fi
  
 done
  
done

Test Output:

C:\Windows\System32>gmic tic foo sea_of_fire,hocuspocus toc
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Initialize timer.
[gmic]-0./foo/*repeat#12/*repeat#18/*if/ 290
[gmic]-0./foo/*repeat#12/*repeat#18/*if/ 13
[gmic]-0./ Elapsed time: 0.207 s.
[gmic]-0./ End G'MIC interpreter.
  • 2022/06/30: Release of G’MIC 3.1.5.
2 Likes

I don’t understand what this mean. Anything to clarify on using this? I’m thinking it might be useful for my Picture Mosaic filter which is something I’ll definitely refactor down the road. I also have the idea of using base64 codes to store images, and to use multiple gui lines to verify changes (this is something I done for other filters as #@gui=var_0 elements can be used to store temporary values).

Variable $_persistent is a now a specific variable whose value is shared along multiple calls of the same filter. As for any variable, it can contain a string, an image or an image list (using the store command).
It remains until you change the filter or you reset its parameters.

So for instance, a filter preview command can set this variable to something (string or image data), and another call of the filter preview command can retrieve it as it is already defined.
The practical use of this, is when a filter needs to do a relatively long task (e.g. reading a large file). Now you can read the file once, store it in memory (in variable $_persistent) and retrieve it for the next call.

EDIT: After looking up $_persistent in updatexxx.gmic, I figured out. I think a update in Picture Mosaic is in order now. Here’s a sample code to understand what _persistent does.

#@gui Persistent Test: fx_rep_pers_test, fx_rep_pers_test_preview
#@gui:Folder=folder()
#@gui:Number of Images=int(0,1,1000)
#@gui:Change This=int(0,0,1)
fx_rep_pers_test:
skip "$*"
if narg($_persistent) $_persistent fi
fx_rep_pers_test_preview:
if narg($_persistent)
 f 0
 $_persistent
else
 f u(255)
 oi={$!}
 10 s. x f u%256
 +store[$oi--1] _persistent
fi
u "{$1}"\
"{"$!"}"

Seem like it would be useful to make some of my earlier filters easier to read and manage, but a bit too late to do that given some of them has 50+ gui parameters. Maybe next year or so or after my refactoring is done which won’t be done in a while.

EDIT: Now I learned what _persistent is. I think it’ll be useful to speed up filters.

EDIT (7/3/2022): It seems to be a GUI filter only thing. I wanted to use it in the cli to dodge the need to use multiple pass commands. Maybe this can be addressed?

1 Like

This is indeed a G’MIC-Qt thing only.
My suggestion : use $_persistent mainly to optimize filters that require to load large data in memory.
This has no sense to have $_persistent to work for CLI calls (those are different processes)

Follow up of multiple _persistent idea: I have another idea. What about these two new commands idea?

keep_named: Keep only named image while not deleting unnamed image. Similar to remove_named.

unname: Unname all images on the list.

My motivation for this is to create differently named _persistent images, and thus I can keep only relevant images from the stored image for different purposes. Unname basically is for avoiding complications arising from remove_named and keep_named i.e avoid affecting unnamed images.

Good idea. Will add this.

What does ‘unname’ means ? Any image in the list has a name.
Do you mean setting an empty string as the name? If so, why not using =>[^] "" ?

That’s exactly what I mean. I chose name[^] instead because it’s easier to understand though I would prefer if name targets all images by default, and => target last image by default.

@David_Tschumperle I have tested keep_named. That’s not exactly what I wanted.

Observe the difference:

C:\Windows\System32>gmic 5,5,1,1 sp cat,dog remove_named dog
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input black image at position 0 (1 image 5x5x1x1).
[gmic]-1./ Input sample image 'cat' (1 image 600x550x1x3).
[gmic]-2./ Input sample image 'dog' (1 image 1024x685x1x3).
[gmic]-3./ Remove images named 'dog'.
[gmic]-2./ Display images [0,1] = '[unnamed], cat'.
[0] = '[unnamed]':
  size = (5,5,1,1) [100 b of float32].
  data = (0,0,0,0,0;0,0,0,0,0;0,0,(...),0,0;0,0,0,0,0;0,0,0,0,0).
  min = 0, max = 0, mean = 0, std = 0, coords_min = (0,0,0,0), coords_max = (0,0,0,0).
[1] = 'cat':
  size = (600,550,1,3) [3867 Kio of float32].
  data = (202,212,212,219,219,219,219,219,219,219,219,219,(...),95,103,103,95,70,79,128,147,146,117,59,13).
  min = 4, max = 244, mean = 113.418, std = 66.7982, coords_min = (293,0,0,0), coords_max = (144,29,0,0).
[gmic]-2./ End G'MIC interpreter.

As you can see, images with empty string name are kept with cat.

However, only dog is kept here:

C:\Windows\System32>gmic 5,5,1,1 sp cat,dog keep_named dog
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input black image at position 0 (1 image 5x5x1x1).
[gmic]-1./ Input sample image 'cat' (1 image 600x550x1x3).
[gmic]-2./ Input sample image 'dog' (1 image 1024x685x1x3).
[gmic]-3./ Keep images named 'dog'.
[gmic]-1./ Display image [0] = 'dog'.
[0] = 'dog':
  size = (1024,685,1,3) [8 Mio of float32].
  data = (67,71,67,71,67,71,71,67,67,71,71,67,(...),79,90,90,90,79,79,84,84,84,79,79,79).
  min = 2, max = 254, mean = 119.113, std = 53.8004, coords_min = (409,183,0,0), coords_max = (474,89,0,0).
[gmic]-1./ End G'MIC interpreter.

That can be done with just k[dog]. The ideal new command should just target every images with a non-empty string name. This should make it possible with work with multiple named images stored in _persistent for different purpose.

I guess my solution is to do name[^] "" dec_imgs={$!-1} k[^0-$dec_imgs] {insert name here}.

Indeed, just as remove_named[sth] is equivalent to rm[sth]. But remove_named (and keep_named) will work also for images whose names contains spaces or special characters (i.e. are not variable names), e.g. remove_named "image name", which is not possible to do with rm.

Having a command named keep_named that would keep images with an empty title makes no sense to me. An empty string is a string as any other string and must be treated this way. Why considering weird exceptions such as “if an image has an empty string, keep it when using keep_named ?”.