+- Gimp-Forum.net (https://www.gimp-forum.net)
+-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP)
+--- Forum: Other graphics software (https://www.gimp-forum.net/Forum-Other-graphics-software)
+--- Thread: ImageMagick Question (/Thread-ImageMagick-Question)
Pages:
1
2
ImageMagick Question - Tas_mania - 01-21-2019
Problem. I'm using software that outputs many JPGs and alpha JPGs like this:
[attachment=2521]
Using this ImageMagick command I can combine the 2 JPGs into a 1 transparent PNG:
composite -compose copy_opacity frame_0000000_alpha.jpg frame_0000000.jpg 0000000.png
That works perfectly but I want to do hundreds or thousands of PNGs.
I tried this:
composite -compose copy_opacity frame_*_alpha.jpg frame_*.jpg *.png
It looks like the output filename doesn't work. Does anyone know how to convert these combined JPGs to PNG's?
Is there another Open Source method to achieve this?
RE: ImageMagick Question - Ofnuts - 01-21-2019
More a shell question. Your file pattern makes one singe call to compose see all the files. There is a specific syntax in IM to tell it to loop over files but this is complicated and in Linux (if I trust your profile) its a lot simpler to use the regular shell syntax. Try something like:
Code:
for f in *alpha.jpg; do b=$(basename $f _alpha.jpg); composite -compose $b.jpg ${b}_alpha.jpg $b.png;done(one-liner for a command line, or in a script:
Code:
for f in *alpha.jpg
do
b=$(basename $f _alpha.jpg)
composite -compose $b.jpg ${b}_alpha.jpg $b.png
doneIn slo-mo:
- for f in *alpha.jpg: will loop over all the *alpha files. Looping on the others is complicated because the simple pattern frame*.jpg will include both the "plain" files and the "alpha" ones.
- b=$(basename $f _alpha.jpg) extracts the base name of the file, and drops the _alpha.jpg termination if present, so tiu are left with frame_000000xxx.
- composite -compose $b.jpg ${b}_alpha.jpg $b.png calls the command, and $b or ${b} is replaced by the frame_000000xxx obtained above. ${b} is necessary when appending _alpha because with $b_alpha the shell would be looking for a variable named $b_alpha since the underscore can be used in variable names.
RE: ImageMagick Question - Tas_mania - 01-21-2019
Thanks immensely Ofnuts, as is often the case you were right onto the solution.
Many people don't know that by including an alpha mask file it's possible to have JPGs with transparency. The reason for my 'problem' is that it takes many hours to render over 4,000 PNGs without having a render farm. It's much faster to render JPGs with their Alpha JPGs. Then converting them into a series of alpha channel PNGs means they can be opened with Gimp or even video editors. The only cost is more disk space but this only temporary.
I experimented with your code and used this which works on Ubuntu 18.04:
for f in *_alpha.jpg; do b=$(basename $f _alpha.jpg); composite -compose copy_opacity ${b}_alpha.jpg $b.jpg $b.png;done
The output program (Mandelbulber2) uses particular filenames and ImageMagick 'compose' wants the alpha.jpg before the standard jpg.
All I have to do is purge the JPG's and I can 'open as layers' in Gimp. Opening in Gimp is memory dependent and with 12Gb ram I can open about 500 layers at a time.
Again, thank you very much I am so happy you solved my problem in 2 hours
RE: ImageMagick Question - Ofnuts - 01-21-2019
(01-21-2019, 10:45 AM)Tas_mania Wrote: It takes many hours to render over 4,000 PNGs without having a render farm. It's much faster to render JPGs with their Alpha JPGs.
The PNG compression isn't very quick if the image cannot be optimized (plasma)...
However, if you get PNG at the end you are going to do this PNG export at some point, so you are mostly adding a JPG encoding the process? If your final image as a significant ratio of transparency it should encode fairly quickly as a PNG?
RE: ImageMagick Question - Tas_mania - 01-22-2019
"If your final image as a significant ratio of transparency it should encode fairly quickly as a PNG?"
I've noticed that is true, more transparency = faster render.
I'm pretty sure Paigan0 found that alpha JPGs were faster to render than PNG:
https://www.deviantart.com/paigan0/status/12526993
He made the worlds first 8K fractal music video (7680X4320px). I don't have enough internet bandwidth to watch a video at that resolution.
Increasing the image size makes slower render times. PNGs are not the final product. I open them as layers in Gimp where I can do compositing tasks and output as AVI video with Gimp-GAP. Then it's a much more manageable size than thousands of PNGs.
Soon I will test the command on 1800 frames that are 1920X1080.
RE: ImageMagick Question - Tas_mania - 01-23-2019
I'm happy to report this command script worked
perfectly.Working on 1890 Jpegs and their alpha pairs at HD video size 1920X1080, the script converted them flawlessly to transparent PNGs.
The script took about 15 minutes to convert the frames. The 'before' folder size was 2.3Gb and the 'after' folder size (just PNGs) was 3.1Gb.
I used this command to purge the JPGs: find . -type f -iname \*.jpg -delete
The fractal render took 14 hours because of the image size and because I ticked some optimisations like anti-aliasing. I assume a PNG render would have taken considerably longer. The purpose of the script is simply to reduce render time because the software can render PNGs.
Thanks again Ofnuts and also Gimp-Forum.net
RE: ImageMagick Question - Tas_mania - 01-28-2019
Here is my first use of the Alpha-JPGs to PNG script.
RE: ImageMagick Question - Ofnuts - 01-29-2019
Maxiter: is that the limit on a loop in the generating code?
RE: ImageMagick Question - Tas_mania - 01-29-2019
(01-29-2019, 01:03 AM)Ofnuts Wrote: Maxiter: is that the limit on a loop in the generating code?
Yes it is. From the manual -
"termination conditions are applied to ensure the formula does not iterate to infinity. The most common conditions used are called Bailout and Maxiter".
I should not have called that spiny thing maxiter but it seemed like a joke. I come across other conditions while trying to improve 3d animations. Applying a G'MIC filter can take hours to complete while other Gimp-dependent commands can be fast. I think its the qtlibs that slow down G'MIC while working on 500 layers at 1080p.
Other options are to import straight to video editor. I would like to investigate the OpenCL capability in Gimp 2.10x. How this has been implemented in Gimp would be interesting. Do all scripts and plugins have the ability to use graphics cards for rendering or not?
Cheers.
RE: ImageMagick Question - Ofnuts - 01-29-2019
(01-29-2019, 10:32 PM)Tas_mania Wrote: Do all scripts and plugins have the ability to use graphics cards for rendering or not?
Hard to tell. On the other hand, the GEGL ops are described as being usable directly from the command line (some gegl command, but I don't know where to find it) and AFAIK GEGL is the but that can use graphics card in Gimp. So that would be the first place to look for me.