-scene option of convert command does not work properly
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
I do have a simple patch which fixes this but I am kind of scared to produce a release with it since I don't know what the side-effects might be. Side-effects might be caused by file formats which store a scene value. I will attach the patch.
Patch so that image frames are written out named according to scene number.
Hello Bob,
I am having the same issue as well. My command I am using is:
gm convert 0.tiff -scene 1 +adjoin file-%d.JPEG
The output file is not incorporating the scene number and the file outputting is file-0.JPEG
Has this issue been fixed already?
On Thu, 16 Feb 2017, Gbath wrote:
It does not seem like it.
The origin of the scene id is not recorded. The scene id could come
from the file which was read, or it could be added/over-ridden using
-scene.
From the documentation ("This option sets the scene number of an image
or the first image in an image sequence."), it is not clear if -scene
should be specified before the file to be read, or after the file to
be read.
Are you comfortable with a possibly random/uncontrolled scene
number originating from within the file determining the output file
name?
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Thanks Bob for your quick reply. So I have tired playing around with moving the scene parameter around, and it does not change the output. I am working on an enterprise level application switching from using ImageMagick to GraphicsMagick, The reason the scene number is so important is due to the fact that application is set to look for file names starting at 1 not 0, changing this breaks many other things.
I am looking at some possible ways on my end to change the file output, is there a fix for this in the pipeline? Thank you for all your help.
On Fri, 17 Feb 2017, Gbath wrote:
From what I can tell, the scene id is actually applied but the problem
is that the mode is not engaged when there is only one scene. This is
easy verified by using two input files (each with its own scene id)
rather than one.
I will look into the problem.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
I looked at this some more. It turns out that the scene id is never
used to form the filename. This is in spite of the documentation
saying "In order to include the scene number in the filename, it is
necessary to include a printf-style %d format specification in the
file name and use the +adjoin option.". What is actually being done
is that the frame sequence number (position in list of images) is
being used.
Some file formats store and produce scene ids. The produced scene ids
could be any value and might even be duplicated.
When using the convert commane like
the internally generated scene ids (from reading each file) are all
zero and so the files will overwrite each other
If we were do to
then we would have a problem since "file2.mng" is able to produce its
own unique scene ids and so we might have 0, 0, 1, 2, 3, 0 and again
we have an issue with duplicate or unpredictable scene ids.
I see that ImageMagick's convert works differently and does produce
sequential ids as well as form the filename based on scene id.
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Thanks Bob for your guidance on the scene param. Without being able to set the scene number, I have started to change other code to compensate. I appreciate all your help.
On Wed, 22 Feb 2017, Gbath wrote:
Sorry that this issue is not fixed. It is very easy to produce the
output you desire for this specific case but it is likely that many
other things would break. GraphicsMagick prides itself on stability.
Perhaps a new option could be added to use the scene id instead of the
frame number.
Bob
Hi Bob,
I would appreciate of you could post the instructions to apply this patch
Thanks
I use GNU patch like:
~~~~~~~~~~~~~~~~~~~~
cd GraphicsMagick
patch -p 1 < /path/to/scene.patch
~~~~~~~~~~~~~~~~~~~~~
In the above, 'GraphicsMagick' is directory for the top of the source tree. The patch needs to be saved somewhere and you must specify the path to read it from.
Thanks Bob,
Now i do:
./configure --enable-gprof --with-tiff --with-png --with-jpeg
$ gm convert -size 300x300 IOE0901220642-3016131453250-part1.tif -resize 120x120 +profile "*" thumbnail.jpg
gm convert: No decode delegate for this image format (IOE0901220642-3016131453250-part1.tif).
[ec2-user@el2-ft117-app1 ~]$
so the tif delegate is not getting compiled, even though i specifically mention it on the command line.
i have tried with --with-tif also , same results
Any help would be appreciated.
Thanks
On Tue, 14 Mar 2017, Kamal Ahmed wrote:
You did not mention what operating system you are using.
If you are using some Linux type system, then it may be that you need
to install '-dev' versions of the required libraries using a package
manager. The requirements depend on your OS distribution. Some of
them do not use separate development packages.
The default for almost all configure options is 'yes'.
Why did you specify
--enable-gprof? This option is for advancedusers (developers) wanting to measure how much time each internal
function took.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
nm, the ./configure --prefix=/usr/local --with-modules=yes with-libtiff --with-jpeg --with-gslib, make make install worked once i manually build tif and jpeg on the host, and did an ldconfig /usr/local/lib
Hi Bob,
Could the following be due to the patch ?
$ gm convert -density 300x300 -verbose TESTIO.pdf +adjoin k%d.JPEG
Error: /ioerror in --showpage--
Operand stack:
1 true
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1983 1 3 %oparray_pop 1982 1 3 %oparray_pop 1966 1 3 %oparray_pop --nostringval-- --nostringval-- 24 1 95 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1858 0 9 %oparray_pop --nostringval-- --nostringval--
Dictionary stack:
--dict:1205/1684(ro)(G)-- --dict:1/20(G)-- --dict:84/200(L)-- --dict:84/200(L)-- --dict:135/256(ro)(G)-- --dict:292/300(ro)(G)-- --dict:32/32(L)-- --dict:6/9(L)-- --dict:24/40(L)--
Current allocation mode is local
Last OS error: No space left on device
GPL Ghostscript 9.20: Unrecoverable error, exit code 1
gm convert: "gs" "-q" "-dBATCH" "-dSAFER" "-dMaxBitmap=50000000" "-dNOPAUSE" "-sDEVICE=pnmraw" "-dTextAlphaBits=4" "-dGraphicsAlphaBits=4" "-r300x300" "-sOutputFile=/tmp/gmIyJf7t" "--" "/tmp/gmAmJZQl" "-c" "quit".
gm convert: Unexpected end-of-file (/tmp/gmIyJf7t).
as for space on device :
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 64G 8.3G 53G 14% /
tmpfs 16G 0 16G 0% /dev/shm
/dev/xvdf 30G 1.4G 27G 5% /home
/dev/xvdg 9.8G 23M 9.2G 1% /tmp
/dev/xvdh 9.8G 3.4G 5.9G 37% /var
/dev/xvdi 9.8G 300M 9.0G 4% /var/log
/dev/xvdj 9.8G 443M 8.8G 5% /var/log/audit
/dev/xvdc 25G 81M 24G 1% /logs
/dev/xvdb 50G 3.4G 44G 8% /data
I am using GraphicsMagick 1.3.25 with your patch, and ghostscript-9.20, jpeg-9b and tiff-4.0.7, which i manually build on the host.
Here is GraphicsMagick Configuration:
$ gm -version
GraphicsMagick 1.3.25 2016-09-05 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2016 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.
Feature Support:
Native Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP no
DPS no
FlashPix no
FreeType no
Ghostscript (Library) no
JBIG no
JPEG-2000 no
JPEG yes
Little CMS no
Loadable Modules no
OpenMP yes (200805)
PNG no
TIFF no
TRIO no
UMEM no
WebP no
WMF no
X11 no
XML no
ZLIB no
Host type: x86_64-unknown-linux-gnu
Configured using the command:
./configure '--prefix=/usr/local' 'LDFLAGS=-L/usr/local/libjpeg/lib -L/usr/local/share/ghostscript/9.20/lib -L/usr/local/libtiff/lib' '--with-tiff' '--with-jpeg' '--with-gslib' '--enable-shared'
Final Build Parameters:
CC = gcc -std=gnu99
CFLAGS = -fopenmp -g -O2 -Wall -pthread
CPPFLAGS =
CXX = g++
CXXFLAGS = -pthread
LDFLAGS = -L/usr/local/libjpeg/lib -L/usr/local/share/ghostscript/9.20/lib -L/usr/local/libtiff/lib
LIBS = -ljpeg -lm -lgomp -lpthread
On Thu, 16 Mar 2017, Kamal Ahmed wrote:
No, I don't think so.
Ghostscript says that it is out of disk space. How many pages are in
your PDF file and what is its page size (e.g. "Letter" or "A4", or
"A0")? Are the pages pure black/white, grayscale, or full color?
If the pages are pure black/white or grayscale, there are tricks to
make Ghostscript use much less space.
The above seems like a lot of space. 9.2G is not much though given
that today's disk drives have terrabytes of space. There is also the
problem that Ghostscript is being requested to write in an
uncompressed format.
The configuration looks fine.
GraphicsMagick has a weakness in that it must read all of its input,
do some optional processing, and then write its output. When
Ghostscript is involved, it inspects the PDF file, then invokes
Ghostscript to write the pages to a sequence of files (a file per
page), and then reads those files in its own representation, and
finally writing the output.
Try
gm convert -density 300x300 -verbose 'TESTIO.pdf[0-19]' +adjoin k%d.JPEG
and see if you then get the first 20 pages of output. If this works,
you could request to convert a number of ranges of pages until it is
all done.
If you are able to use a much larger disk area for temporary files,
then you might not need to repeat for page sequences as shown above.
You can set the MAGICK_TMPDIR environment variable to use a larger
temporary space like
sudo mkdir /data/tmp
sudo chown $LOGNAME:$LOGNAME /data/tmp
env MAGICK_TMPDIR=/data/tmp gm convert -density 300x300 -verbose TESTIO.pdf +adjoin k%d.JPEG
and then maybe it will work for all the pages.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Hi Bob,
I am trying to make an RPM with this patch, and trying to install it on Redhat 6.8 taking the following steps:
./configure '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-shared' '--disable-static' '--docdir=/usr/share/doc/GraphicsMagick-1.3.25' '--with-lcms2' '--with-magick_plus_plus' '--with-modules' '--with-threads' '--with-wmf' '--with-x' '--with-xml' '--with-dps' '--with-gslib' '--with-gs-font-dir=/usr/share/fonts/default/Type1' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4'
make
make DESTDIR=/home/ec2-user/GM/tmp/project/ install
fpm -s dir -t rpm -C tmp/project --name GraphicsMagick --version 1.3.25 --iteration 5 --description "GraphicsMagick 1.3.25 on redhat 6.8" .
Then, install this RPM on a clean redhat 6.8 VM, but after rpm -ivh GraphicsMagick-1.3.25-5.x86_64.rpm, i get error:
$ gm -version
gm: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory
[ec2-user@el2-ft133-app1 ~]$
plus the /usr/bin/gm does not have the correct permissions
I would really appreciate Any help in this regard.
now as far as shared libraries: libtiff.so.5, i could only find an rpm for it on Centos 7.x in libtiff 4.0.3
Thanks,
-Kamal.
On Thu, 30 Mar 2017, Kamal Ahmed wrote:
This would be due to GraphicsMagick not being built against the
libtiff version which comes with the system, or libtiff is not
installed on the system.
I have seen mention that there are issues with the RPM package I
build. In particular, I heard that my own identity ended up being
encoded into the RPM rules.
It is perhaps wrong for GraphicsMagick to distribute a RPM source
package at all since some aspects need to be changed depending on the
OS distribution.
You need to compile against libtiff version offered for the system. If
you don't do this, then you would need to create your own libtiff
package for the version you used. There is a possibility to static
link with libtiff, in which case a shared library does not need to be
present at all.
To have the best opportunity for success, I suggest finding the RPM
recipe (supportive source code such as the spec file) that the OS
distribution uses to prepare its own GraphicsMagick package (if it
does) and use it for your own GraphicsMagick package.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/