Request support for 16-bit TIFF (=compile with --with-quantum-depth=16)

Bug #696215 reported by Vesa K on 2011-01-01
68
This bug affects 15 people
Affects Status Importance Assigned to Milestone
graphicsmagick (Debian)
Fix Released
Unknown
graphicsmagick (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: graphicsmagick

Can you compile graphicsmagick-imagemagick-compat --with-quantum-depth=16 parameter?

graphicsmagick comment:
http://sourceforge.net/tracker/index.php?func=detail&aid=2942292&group_id=73485&atid=537937

Then Octave should support 16-bit TIFF too.
Octave bug: http://savannah.gnu.org/bugs/index.php?30715

maverick (10.10)

$ identify Pictures/3007.tif
Pictures/3007.tif TIFF 3514x2340 3514x2340+0+0 16-bit DirectClass 49.37MB 0.000u 0:00.000
$ gm identify Pictures/3007.tif
Pictures/3007.tif TIFF 3514x2340+0+0 DirectClass 8-bit 47.1M 0.000u 0:01

Thanks.

Vesa K (j2007jokunen) wrote :

Sorry not graphicsmagick-imagemagick-compat (I not even use this)

but compile these --with-quantum-depth=16 parameter
libgraphicsmagick++3: format-independent image processing - C++ shared library
libgraphicsmagick3: format-independent image processing - C shared library

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in graphicsmagick (Ubuntu):
status: New → Confirmed
Carnë Draug (carandraug) wrote :

Actually, could this maybe be compiled with 32 instead? Or maybe with both?

Until not far ago, it was not simple to have multiple istances of the Magick++ library but this has changed. It is now possible to enable modules when compiling GraphicsMagick. See the new configure option:

--with-modules Image coders and process modules are built as loadable modules which are installed under the directory [prefix]/lib/GraphicsMagick-X.X.X/modules-QN (where 'N' equals 8, 16, or 32 depending on the quantum depth) in the subdirectories 'coders' and 'filters' respectively. The modules build option is only available in conjunction with --enable-shared.

Changed in graphicsmagick (Debian):
status: Unknown → New
Brian the Lion (rossabri) wrote :

Bump? There has been no movement on this issue upstream in quite some time. Can we get it moving again?

This is affecting image processing in Octave, and is forcing to use MATLAB instead; driving away from FOSS. Can the graphicsmagick be compiled with 16 bit to work with octave?

I see a lot of recommendations in the forums from the developer of graphicsmagick to use 16 bit. Is there any strong reason not to go for 16 bit?

Faekynn (jkornprobst) wrote :

It woudl really be great, if this could be done!

Changed in graphicsmagick (Debian):
status: New → Fix Released
Logan Rosen (logan) wrote :

This bug was fixed in the package graphicsmagick - 1.3.20-4

---------------
graphicsmagick (1.3.20-4) experimental; urgency=low

  * Test build with QuantumDepth 16 (closes: #557879).
  * Update Standards-Version to 3.9.6 .

 -- Laszlo Boszormenyi (GCS) <email address hidden> Wed, 28 Jan 2015 17:56:41 +0000

Changed in graphicsmagick (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.