RMagick jp2 problem

the following program:

~ > cat tiff2jp2
require ‘RMagick’
tiff = ARGV.shift
jp2 = ARGV.shift || tiff.gsub(%r/tiff?/o,‘jp2’)
img = Magick::Image.read(tiff).first
img.write jp2

results in quite a ‘lossy’ transformation even though the docs caim a default
compression type of lossless jp2. i’ve played with both quality and
compression settings and always lose data with this method

however, using this command:

tifftopnm image.tiff | jasper --input-format pnm --output-format jp2 > image.jp2

does NOT lose data so this shows that that jasper jp2 lib IS capable of doing
lossless compresion

any ideas on why this is?

-a

···

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
“640K ought to be enough for anybody.” - Bill Gates, 1981
===============================================================================

Ara, what release of ImageMagick are you using? What release of the jasper
library?

Do you get the same results from this command?

convert image.tiff image.jp2

···

On Tue, 18 May 2004 18:17:04 -0600, Ara.T.Howard wrote:

any ideas on why this is?

any ideas on why this is?

Ara, what release of ImageMagick are you using? What release of the jasper
library?

tim-

thanks for the reply.

/dmsp/reference/build/RMagick-1.5.0 > uname -srm
Linux 2.4.21-15.ELsmp i686

/dmsp/reference/build/RMagick-1.5.0 > cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 2)

/dmsp/reference/build/RMagick-1.5.0 > ruby -v
ruby 1.8.1 (2003-12-25) [i686-linux]

/dmsp/reference/build/RMagick-1.5.0 > Magick-config --version
6.0.1

/dmsp/reference/build/RMagick-1.5.0 > jasper --version
1.701.0
libjasper 1.701.0

/dmsp/reference/build/RMagick-1.5.0 > ruby -r RMagick -e ‘p Magick::Version’
“RMagick 1.5.0”

hopefully all the latest greatest

Do you get the same results from this command?

convert image.tiff image.jp2

yes. this worries me - it’s as if the ImageMagick binding to the jasper lib is
incorrectly dealing with compression/quality… as i said before, the jasper
binary handled perfectly and i get ZERO differences when comparing the bands of
a tiff image and one converted via tifftopnm/jasper…

perhaps a post the ImageMagick group would be more appropriate?

btw. the ruby bindings are really cool - good job.

cheers.

-a

···

On Wed, 19 May 2004, Tim Hunter wrote:

On Tue, 18 May 2004 18:17:04 -0600, Ara.T.Howard wrote:

===============================================================================
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
“640K ought to be enough for anybody.” - Bill Gates, 1981
===============================================================================

yes. this worries me - it’s as if the ImageMagick binding to the jasper
lib is incorrectly dealing with compression/quality… as i said before,
the jasper binary handled perfectly and i get ZERO differences when
comparing the bands of a tiff image and one converted via
tifftopnm/jasper…

Yes, this is almost certainly an IM<->jasper issue. I’ll be glad to send
your question to the ImageMagick developers this afternoon. I’ll let you
know what I find out.

btw. the ruby bindings are really cool - good job.

Thank you very much!

···

On Tue, 18 May 2004 21:04:26 -0600, Ara.T.Howard wrote:

thanks alot tim.

-a

···

On Wed, 19 May 2004, Tim Hunter wrote:

On Tue, 18 May 2004 21:04:26 -0600, Ara.T.Howard wrote:

yes. this worries me - it’s as if the ImageMagick binding to the jasper
lib is incorrectly dealing with compression/quality… as i said before,
the jasper binary handled perfectly and i get ZERO differences when
comparing the bands of a tiff image and one converted via
tifftopnm/jasper…

Yes, this is almost certainly an IM<->jasper issue. I’ll be glad to send
your question to the ImageMagick developers this afternoon. I’ll let you
know what I find out.

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
“640K ought to be enough for anybody.” - Bill Gates, 1981
===============================================================================

Ara, I received your email at my home address but my reply to your .gov
address bounced(?). Anyway, the ImageMagick developers say that

convert -quality 100 image.tif image.jp2

should do the trick. I see that you’ve already tried that with
GraphicsMagick, though. The two packages are not entirely identical, so
maybe it will work with ImageMagick.

If it doesn’t work then probably you’ll get faster & better answers by
posting directly to the magick-users@imagemagick.org mailing list. This is
one you have to join before you can post. The instructions are on the
ImageMagick web site. If you can get the convert command to work but the
conversion doesn’t work with RMagick give me a shout and I’ll investigate.

Please let me know if there’s anything else I can do to help!

···

On Wed, 19 May 2004 07:19:29 -0600, Ara.T.Howard wrote:

On Wed, 19 May 2004, Tim Hunter wrote:

On Tue, 18 May 2004 21:04:26 -0600, Ara.T.Howard wrote:

yes. this worries me - it’s as if the ImageMagick binding to the
jasper lib is incorrectly dealing with compression/quality… as i
said before, the jasper binary handled perfectly and i get ZERO
differences when comparing the bands of a tiff image and one converted
via tifftopnm/jasper…

(Yeah, I know I shouldn’t follow up my own posts.)

The RMagick version of this is

img.write(“image.jp2”) {self.quality = 100}

···

On Thu, 20 May 2004 00:02:42 +0000, Tim Hunter wrote:

convert -quality 100 image.tif image.jp2

yes - i’ve done this but can subseqently show a diff of the bands using envi
(rsi inc.) or imgcmp (which ships with jasper) - it’s bizarre: for the most
part the diff shows all zeros (no difference) but then 20 or 20 pixels will be
different… at this point this discussion is well off topic but i do have
ONE more RMagick specific question to ask:

what is the most effecient (we are dealing with HUGE images) to compare
the raw pixel values of two images using RMagick, eg (not efficient psuedo
code).

tiff_pixels = Image.get_pixels
jp2_pixels = Image.get_pixels

i = 0
tiff_pixels.each do |pixel|
raise "diff @ #{ i } " unless pixel = jp2_pixels[i]
i += 0
end

thanks again.

-a

···

On Thu, 20 May 2004, Tim Hunter wrote:

On Wed, 19 May 2004 07:19:29 -0600, Ara.T.Howard wrote:

On Wed, 19 May 2004, Tim Hunter wrote:

On Tue, 18 May 2004 21:04:26 -0600, Ara.T.Howard wrote:

yes. this worries me - it’s as if the ImageMagick binding to the
jasper lib is incorrectly dealing with compression/quality… as i
said before, the jasper binary handled perfectly and i get ZERO
differences when comparing the bands of a tiff image and one converted
via tifftopnm/jasper…

Ara, I received your email at my home address but my reply to your .gov
address bounced(?). Anyway, the ImageMagick developers say that

convert -quality 100 image.tif image.jp2

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
URL :: Solar-Terrestrial Physics Data | NCEI
“640K ought to be enough for anybody.” - Bill Gates, 1981
===============================================================================

Assuming you want to compare entire images and get a single result, you
can use the channel_compare method to compare individual channels or all
the channels at once.

Or possibly use the composite method with the DifferenceCompositeOp to
produce a difference image.

Any approach where you use Ruby to inspect individual pixels is
going to involve a lot of overhead, since RMagick has to convert each
pixel to a Pixel object. (And Pixel objects are heavier-weight than you’d
imagine.)

···

On Wed, 19 May 2004 20:15:24 -0600, Ara.T.Howard wrote:

what is the most effecient (we are dealing with HUGE images) to
compare the raw pixel values of two images using RMagick, eg (not
efficient psuedo code).