RMagick -- TIF to PDF

Ruby
1

This works:

require ‘RMagick’
img_array = Magick::Image.read(‘C:/test.tif’)
imgs = Magick::ImageList.new
for image in img_array
image = image.negate
image.compression= Magick::LZWCompression
imgs<<image
end

imgs.write(‘C:/testImg1.pdf’)

but it seems like the long way around the barn. Anyone care to suggest
improvements?

Especially:

image = image.negate.

If that isn’t in there, the PDF comes out the negative of the TIF,
but it seems like it ought to be unnecessary. Is it a bug, or did I do
something silly?

Ron

2

On Jul 16, 12:47 pm, paron [email protected] wrote:

image = image.negate.

If that isn’t in there, the PDF comes out the negative of the TIF,
but it seems like it ought to be unnecessary. Is it a bug, or did I do
something silly?

I’m not a big TIFF user, but I think you’re seeing an instance of the
condition discussed here:
may I continue post here if it is now a request for feature? - Legacy ImageMagick Discussions Archive.

You can use the Image::Info#[]= method to define format-specific
options, assuming you have a version of ImageMagick that supports the
option. I’m not at a place where I can test it, but it woudl be
something like this

imgs = Magick::Image.read(‘C:/test.tif’) {self[“tiff”,
“quantum:polarity”] = “min-is-black”}

3

image = image.negate.

If that isn’t in there, the PDF comes out the negative of the TIF,
but it seems like it ought to be unnecessary. Is it a bug, or did I do
something silly?

I’m not a big TIFF user, but I think you’re seeing an instance of the
condition discussed here:may I continue post here if it is now a request for feature? - Legacy ImageMagick Discussions Archive…

Well, just to close out the thread, it turns out that it’s not a bug,
and I didn’t do anything silly. The TIF specification does not set a
default for the “Photometric” tag, which tells whether min is black or
min is white.

In fact, the tag doesn’t have to be present at all. Our scanner
produces TIF files without a “Photometric” tag. Since there’s also no
default value called out in the spec, it’s a coin-toss whether the
image renders properly or not in a viewer. That explains why most TIF-
oriented viewers have an ‘invert image’ button!

Anyway, I don’t think much of that part of the spec. Instead of
setting a meaningful standard, they apparently just legitimized the
bag of worms that existed when they wrote it.

If traffic engineers couldn’t agree on whether green or red meant
“go,” so they just agreed that you could choose either one, that would
be foolish. If they compounded the problem by deciding that you don’t
have to tell anyone which option you chose, that is insane.

Ron