Wow @patdavid, great thorough article…apparently I screwed up by not poking through all of the history of this forum prior to the time I joined. Wonder what other nuggets I will discover…
Better late than never. You aren’t like me, reading almost everything.
I may have found an alternative. Pseudogrey is mentioned but no signs of it in the application. Delalaboratory
Obviously I shouldn’t have stuck curves on the top of the layer stack but wanted to see if it functioned as the others. The controls if any for all of the layers that are added remain active. Very photographer friendly. Just wish it had gimp levels as being able to set the output span can be very useful.
I had to edit the make file to get it to compile on Linux 64bit by forcing the selection. Just commented out the if else around it.
It couldn’t open a user directory and I didn’t check if it can save a file. Hope so
I can look at updating the script to see what went wrong.
In the meantime, you can also do this manually pretty easily:
I have GIMP 2.10.12 and the Pseudogrey Script-fu that I have still works. Still, one of my favorites and it runs quick.
Maybe you could post it as an attachment on here. I tried the google drive one via Pat’s site and found another but both the same.
Actually, on that note now that @lylejk has jogged my memory:
Got that from his post a while back:
The pseudogrey scheme, as described in http://r0k.us/graphics/pseudoGrey.html , can be implemented with ImageMagick like this. First, we create a CLUT (colour look-up table), with 3 channels, 4096x1 pixels:
magick ^ -size 4096x1 xc: ^ -fx (i-7)/w ^ -channel R ^ -fx "i%%16>=5&&i%%16<=8?u+1/256:u" ^ -fx "i%%16>=14&&i%%16<=15?u+1/256:u" ^ +channel ^ -channel G -fx "i%%16>=9?u+1/256:u" +channel ^ -channel B ^ -fx "i%%16>=2&&i%%16<=4?u+1/256:u" ^ -fx "i%%16>=7&&i%%16<=8?u+1/256:u" ^ -fx "i%%16>=11&&i%%16<=13?u+1/256:u" ^ +channel ^ -depth 8 ^ pg_clut.png
This CLUT has 1786 unique colours.
We can use it by applying it to any grayscale image with any number of bits/pixel. We must save the result with a depth of 8. For example:
magick ^ toes.png ^ -colorspace Gray ^ pg_clut.png ^ -clut ^ -depth 8 ^ toes_1786.png
The above commands are for Windows BAT. For bash, change line ends to backslash, don’t double the %%, and escape parentheses ( and ):
magick \ -size 4096x1 xc: \ -fx \(i-7\)/w \ -channel R \ -fx "i%16>=5&&i%16<=8?u+1/256:u" \ -fx "i%16>=14&&i%16<=15?u+1/256:u" \ +channel \ -channel G -fx "i%16>=9?u+1/256:u" +channel \ -channel B \ -fx "i%16>=2&&i%16<=4?u+1/256:u" \ -fx "i%16>=7&&i%16<=8?u+1/256:u" \ -fx "i%16>=11&&i%16<=13?u+1/256:u" \ +channel \ -depth 8 \ pg_clut.png magick \ toes.png \ -colorspace Gray \ pg_clut.png \ -clut \ -depth 8 \ toes_1786.png
Nursing a brain-addling cold, thinking through how do do this on 0.0-1.0 floating point. I believe 0.00390625 has something to do with it…
Whoops. Tabs confused and replied to the wrong thread
I find with some B&W there is benefit but I save jpg’s at 95%. Being ancient I used to regularly print 20x16 in B&W from 35mm and find digital has problems matching what I know that can do. When I hear mention of grain I get the impression people must have strange memories or maybe had everything done via the local chemists. Actually I feel that there are reason why film etc could do a better job that a pc screen.
Anyway, still no joy with the other version. Looking around on the web it looks like it may be down to scripting changes - NORMAL and others no longer defined. One suggestion was to replace all such with 0 but yet more errors.
So currently just hope some one can sort it out. Not so sure about the version in GMIC maybe because of the sliders and not knowing how these relate to the original version. It looks to be based on channel mixing but I’m only guessing.