Speed up “movie barcode” generation w/ IM

[fmw42]

FILES=($(find "${1}" -type f | egrep -i "\.bmp$" | sort))

if [[ ${3} == "crop" && -n ${4} ]]; then
for f in ${FILES[*]}; do
convert ${f} -resize ${src_frameheight}x\! -crop 0x1+0+${4} +repage miff:-
done |\
montage - -mode Concatenate -tile 1x ${2}.png
…
done

mogrify -rotate -90 -sample ${slicecount}x\! ${2}.png

The convert step is fine, though the loop may need to be done in a subshell to avoid miff getting overwritten for each image. The miff should contain all the cropped images. However, it would probably be better to use convert ... append rather than montage, unless you want the default (2 px?) spacing between the images that montage will add unless you specify -geometry +0+0. I do not think you need -mode concatenate, unless that overrides the default spacing. I have never used that option.

[killmoms]

The convert step is fine, though the loop may need to be done in a subshell to avoid miff getting overwritten for each image. The miff should contain all the cropped images. However, it would probably be better to use convert ... append rather than montage, unless you want the default (2 px?) spacing between the images that montage will add unless you specify -geometry +0+0. I do not think you need -mode concatenate, unless that overrides the default spacing. I have never used that option.

The Concatenate mode does override the default spacing. The issue wasn't with the original script not working—it worked perfectly (miff wasn't overwritten, the montage command combined all the slices correctly, the resulting barcodes looked great). The problem was that it is slow, especially when I'm trying to create 1920 barcodes. I'm looking for ways to make the script faster.

[fmw42]

Again I am not an expert, but I do not see any way to improve speed using IM other than using Q8 IM compile and as many threads as possible (multicore hardware) with OpenMP enabled. I am not sure about whether convert append would be faster than montage. I suspect it might be slightly faster, but I have not tested that. Do you have enough memory to hold any single image and the temps needed to do the convert step to resize and crop? Otherwise, IM will use disk for temp space. Is your IM tmp directory large enough to hold all the data? You could replace -resize by -scale for speed, but you might be trading quality. You could also use -filter point before -resize (or -filter point -interpolate bilinear).

If you input images are just jpeg, you could use the jpeg hint for reading images to make that faster. See http://www.imagemagick.org/Usage/formats/#jpg_read

Also you might try -strip to avoid large profiles, unless you need the meta data.

I believe in the next version, there may be a -define for stripping meta data before reading in the input image. There was talk of that not too long ago. You could search the forum for that.

[fmw42]

Does it make sense to you to just scale to 1 pixel for each frame and then expand vertically to get 1 column? So in your loop use this

convert ${f} -scale 1x1! -scale 1xH! miff:-

where H is the desired height for each column. This would then look something like my script colorspectrum (though that gives a barcode for all the unique colors in one image).

This would be faster and give you a representation of the color of each frame as a bar code for the whole video. Of course you are giving up the variation in color in the vertical direction. But it would likely be much faster.

[killmoms]

Yeah, I did some initial tests (before I wrote the script) with methods that'd choose a single average color per frame, but I was dissatisfied with the results from a aesthetic perspective. For the resize mode, I'd like to continue compressing the frame horizontally so there's vertical variation to the coloring. That said, the resize mode only ever generates a single barcode for a movie, so I don't mind that one taking a little longer. The issue is how long the crop method takes, because that's the method I'm using to iteratively generate many barcodes to create an animation.

One thing I'm considering for the crop mode is resizing the dumped frames to their proper display height during the dump process (within ffmpeg) so there's no resizing necessary during the cropping stage. Maybe that would help a bit? In any case, I was just hoping there was a faster way to crop out a specific row/column of pixels than "convert -crop" seems to be, since the crop mode takes between 1 - 2 minutes per barcode currently. Since every frame shares the same geometry, I was hoping there might be some way to just read a specific row/column of pixels without having to load the entire image into memory and concatenate them.

[fmw42]

Did you test any of my suggestions in my previous message to the last one? You could try using -scale rather than -resize in your code.

Are you sure the time issue is not with -resize. I would think by the time the image has been resized, it would not take long to crop the image.

I am not sure this would be faster, but there is another way to crop using -distort SRT and its -define viewport

see
http://www.imagemagick.org/Usage/distor ... t_viewport

[killmoms]

Yeah, I'm gonna do a test where I pre-resize all frames (as part of ffmpeg's export, since I only have to do that *once*) so the crop mode doesn't have to resize during the loop, just crop. We'll see if that helps at all.

Do you think the JPEG hint would help more than using an uncompressed format for the dumped frames? I'm wondering if it's worth the disk space hit to just use something like BMP over JPEG, if some of the slowdown is reading in a compressed format.

Do you have enough memory to hold any single image and the temps needed to do the convert step to resize and crop? Otherwise, IM will use disk for temp space. Is your IM tmp directory large enough to hold all the data?

I'm a little unclear on what you mean here. By any single image do you mean a single frame? Or do you mean ALL the frames? Because loading 1920 6.2MB files (24-bit 1920x1080 bitmaps) into RAM is something my machine, with only 8GB of the stuff, probably will complain about. (Actually, I KNOW it will complain about it, because I almost killed it last night trying just that ).

Also you might try -strip to avoid large profiles, unless you need the meta data.

Will strip affect anything functionally in terms of processing the images? Because I don't think I need any meta-data, but I don't really know for sure (e.g. if meta-data is being used in the background somehow). Sorry for being inexperienced.

A custom compile of ImageMagick is a bit beyond my ken (I got it by using Macports, so if I can port update with that option, maybe…?).

[fmw42]

You can also use -extent to crop

convert image -extent WxH+X+Y result

though I am not sure if that is faster than -crop.

[fmw42]

I do not see how pre-resizing would help the overall speed. You still have to resize.

If your images are JPG, then using the hint would read the files faster.

I meant just one frame.

Stripping the data would only affect the color if there were color profiles. It is only useful if you have a large amount of meta data. If the meta data is small relative to your image data, then it won't help much.

I do not know about changing the compile options using MacPorts. Though I think it can be done. But I have not found any documentation how to do it.

I use MacPorts to install all my delegate libraries, but compile IM from source. That seems to work well to be able to keep up with the latest changes to IM. If you want to try that, let me know, I can send you my ./configure command and show you what is important. I do that so I can have multiple versions of IM on my system and hdri versions if I want or different Q levels.

[killmoms]

I do not see how pre-resizing would help the overall speed. You still have to resize.

Yes, but I only dump the frames once. In animation mode, I crop thousands (actually, with the frame/barcode sizes I'm doing, (1923*1920) times). Eliminating a resize step from that process, it seems to me, would be a net win.

If your images are JPG, then using the hint would read the files faster.

Faster than just using BMPs for the source frames?

[snibgo]

Another possibility: resizing with an ffmpeg option, creating the frames, may be faster than doing it with IM.

[killmoms]

Right, that's one of the things I'm going to try—like I said above, I dump the frames once, I use IM to crop thousands and thousands of times, so.

[snibgo]

If your desired output is a video, I expect you can do the entire process in ffmpeg. This may also be massively faster. See http://ffmpeg.org/ffmpeg-filters.html

[killmoms]

I don't think so, mostly because the "video" I'm looking to end up with basically swaps the spatiality and temporality of the original video. ffmpeg is designed to take one temporally linear source and convert it, after a number of optional filters, to another temporally linear destination.

It takes between 3 and 15 minutes to dump 1920 frames from my source videos (depending on their resolution and duration), and I don't think it has a way during conversions to create new frames (temporally) from a (spatial) sampling of frames from throughout the original video. The length of time ffmpeg takes is related to the need to essentially faster-than-realtime decode the ENTIRE video in order to extract a given number of non-sequential frames from it.

Basically, since I'm trying to sample from ALL frames (the full length of the video) to create ONE frame of the output—and then do so iteratively for the length of the output, I don't think ffmpeg will be able to help. It's kind of the opposite use case of what ffmpeg (or, really, any video conversion utility) was designed to do.

[snibgo]

I'm not an expert at ffmpeg. It can split a video into streams, crop, apply time-offsets and merge video streams. I don't know if it could cope with 1920 streams, and some critical functionality may be missing.