To put it succinct; I’m wondering if G’MIC will ever update to allow for high-bitdepth PNG output options.
I think it’s a bit strange that only TIF has output option related to high-bitdepth output.
Not that I oppose TIF but PNG is simpler and more general and AFAIK is widely documented for developers isn’t it?
And since you recently said that G’MIC was reaching a stable end of development I find it odd that it is limited in output formats in both PNG and the ever expanding ‘current’ graphics formats like AVIF and WEBP and JPEG-XL and all those new one that pop up and not so new ones that are undergong updates and development.
Oh and not to mention that several of those fileformats also support animation, which can nice to play with.
So I wonder, will there be any addition in that regard ever for G’MIC? Or will we have to script around it and use external software to convert TIF files, which of course is always an option.
Are you talking about 16bits/channel PNG files ?
If so, G’MIC already support that:
$ gmic sp colorful mul 257 o png16.png
[gmic]./ Start G'MIC interpreter (v.3.5.0).
[gmic]./ Input sample image 'colorful' (1 image 800x800x1x3).
[gmic]./ Multiply image [0] by 257.
[gmic]./ Output image [0] as png file 'png16.png' (1 image 800x800x1x3).
[gmic]./ End G'MIC interpreter.
$ file png16.png
png16.png: PNG image data, 800 x 800, 16-bit/color RGB, non-interlaced
G’MIC is really not intended to support a wide variety of image formats (there is Imagemagick’s convert for that purpose). It is focused on processing data, and image formats are just ways to input/save arrays of values.
On linux, if you use G’MIC to load more “exotic” formats than the usual ones, then it actually tries to use ImageMagick’s convert to load the image data.
Weird, I tried to get a >8 bit output in the past and I failed, yet your example works fine
And yes I accept that it’s not the purpose of G’MIC to be something like XNView who are just busy all the time to keep up with the hundreds of formats, however since more and more people have monitors with bitdepths greater than 8bit (per channel) we have to accept there is a shift going on. Even when I too mostly use 24bit, if alone because regular jpeg is still so mainstream meaning we are still a good part in the 24bit realm. But I just forsee that we are going to end up in a 10bit per channel world eventually.
And of course if G’MIC works internally with high bitdepth calculations it seem a bit of a waste to be so 8bit-centric in output.
Anyway, I am surprised that I should be able to get that higher bitdepth PNG ging, even though when I tried to output such previously I failed. I just have to figure out what I did wrong before now.
(took me a while to even find out I had to use normalize for regular 8 bit output, G’MIC can be a bit hard to get a grip on in terms of just starting and the documentation which seem to be a bit thrown together haphazardly at times, with some command only to be found out about in the forums/changelog and the help site having some errors like the gmic.eu/oldtutorial/ help files having links that go 404 because the actual pages didn’t update to link to the proper /oldtutorial/ tutorials but try to go to /tutorials/ which does not exist anymore so you have to manually add ‘old’ before ‘tutorial’ in the url to get to the proper page.)
And although I’m happy to hear it should work and your answer I still think it’s a pity you can’t force a png’s output depth with an option, like you can with tif files. But meh. you can’t have everything.
