I tried both removing <image-loading> as well as just keeping the second line. It did not have an observable effect.
Based on these cases, the conclusion appears to be that if I have an RGB tiff image, the PDF renderer will work fine, but if non-RGB is used (16-bit in my case), then it will not render correctly in pdf output. === ADDITIONS === I tried one last variant, version [4], save as from ImageJ with RGB selected. That displays correctly in the pdf output. 4. Tiff data when LeadTools tiff image (from step 1.) is opened in ImageJ, then choose type > RGB, then Save as. SubFileType (1 Long): Zero ImageWidth (1 Long): 1396 ImageLength (1 Long): 460 BitsPerSample (3 Short): 8, 8, 8 Photometric (1 Short): RGB ImageDescription (14 ASCII): ImageJ=1.47v StripOffsets (1 Long): 154 SamplesPerPixel (1 Short): 3 RowsPerStrip (1 Short): 460 StripByteCounts (1 Long): 1926480 2014-01-29 Luis Bernardo <lmpmberna...@gmail.com> > Remove the <image-loading> section from fop.xconf, or at least the first > line (the second line can stay and may even be necessary). The way you have > it you may be giving preference to ImageLoaderImageIO (which is indeed the > "default" unless there is a native) over the twelvemonkeys image loader. > > > On Wed, Jan 29, 2014 at 3:11 PM, Valentina Cupac <valentina.cu...@tp.rs>wrote: > >> The following is the image data, obtained with >> http://www.awaresystems.be/imaging/tiff/astifftagviewer.html >> >> ========================================== >> >> PART A. Tiff data >> >> 1. Original tiff data of Tiff image exported from LeadTools >> >> SubFileType (1 Long): Zero >> ImageWidth (1 Long): 1396 >> ImageLength (1 Long): 460 >> BitsPerSample (1 Short): 16 >> Compression (1 Short): Uncompressed >> Photometric (1 Short): MinIsBlack >> StripOffsets (2 Long): 238, 1047238 >> Orientation (1 Short): TopLeft >> SamplesPerPixel (1 Short): 1 >> RowsPerStrip (1 Long): 375 >> StripByteCounts (2 Long): 1047000, 237320 >> PlanarConfig (1 Short): Contig >> PageNumber (2 Short): 0, 0 >> >> 2. Tiff data when LeadTools image is opened in Paint.NET, then did Save >> as in Paint.NET >> >> SubFileType (1 Long): Zero >> ImageWidth (1 Long): 1396 >> ImageLength (1 Long): 460 >> BitsPerSample (4 Short): 8, 8, 8, 8 >> Compression (1 Short): LZW >> Photometric (1 Short): RGB >> StripOffsets (1 Long): 8 >> SamplesPerPixel (1 Short): 4 >> RowsPerStrip (1 Long): 460 >> StripByteCounts (1 Long): 1015503 >> XResolution (1 Rational): 96 >> YResolution (1 Rational): 96 >> PlanarConfig (1 Short): Contig >> ResolutionUnit (1 Short): Inch >> PageNumber (2 Short): 0, 0 >> Software (18 ASCII): Paint.NET v3.5.10 >> Predictor (1 Short): 2 >> ExtraSamples (1 Short): 2 >> >> 3. Tiff data when LeadTools image is opened in ImageJ, then did Save as >> from Image J. >> >> SubFileType (1 Long): Zero >> ImageWidth (1 Long): 1396 >> ImageLength (1 Long): 460 >> BitsPerSample (1 Short): 16 >> Photometric (1 Short): MinIsBlack >> ImageDescription (34 ASCII): ImageJ=1.47v min=0.0 max=65535.0 >> StripOffsets (1 Long): 168 >> SamplesPerPixel (1 Short): 1 >> RowsPerStrip (1 Short): 460 >> StripByteCounts (1 Long): 1284320 >> >> =============================== >> >> PART B. Effects >> >> Within the Windows image viewer program, all those images appear the same. >> >> However, when generating pdf with FOP, this is what happens: >> * Image [1] renders incorrectly >> * Image [2] renders correctly ***** >> * Image [3] renders incorrectly >> >> >> Also I have these settings: >> >> <image-loading> >> <penalty value="-1000" >> class="org.apache.xmlgraphics.image.loader.impl.imageio.ImageLoaderImageIO"/> >> <penalty value="INFINITE" >> class="org.apache.xmlgraphics.image.loader.impl.ImageLoaderRawCCITTFax"/> >> </image-loading> >> >> So this means it's using the default Java image loader as far as I know. >> >> >> >> 2014-01-29 Luis Bernardo <lmpmberna...@gmail.com> >> >> If you can share the image send it to this mailing list. Otherwise you >>> can send it to me and I can take a look. It is possible that the default >>> image loader is still being used, or something else is at play, but we will >>> need the image to check. >>> >>> >>> On Wed, Jan 29, 2014 at 1:07 PM, Valentina <valent...@tp.rs> wrote: >>> >>>> I compiled the library. >>>> >>>> Inside the lib directory, I now have the following: >>>> >>>> avalon-framework >>>> batik-all >>>> commons-io >>>> commons-logging >>>> seralizer >>>> twelvemonkeys-common-image >>>> twelvemonkeys-common-io >>>> twelvemonkeys-common-lang >>>> twelvemonkeys-imageio-core >>>> twelvemonkeys-imageio-jpeg >>>> twelvemonkeys-imageio-metadata >>>> twelvemonkeys-common-image >>>> twelvemonkeys-common-io >>>> twelvemonkeys-common-tiff >>>> xalan >>>> xercesImpl >>>> xml-apis >>>> xml-apis-ext >>>> xmlgraphics-commons >>>> >>>> I run the command fop template.fo report.pdf >>>> >>>> I do not see difference before/after twelvemonkeys was added. >>>> Was there anything else that I should have done? >>>> >>>> >>>> 2014-01-29 Luis Bernardo <lmpmberna...@gmail.com> >>>> >>>> TIFF can use JPEG compression, so it is likely that the issue is with >>>>> JPEG image handling even though it is a TIFF. But TwelveMonkeys also has >>>>> an >>>>> imageio-tiff component so you can try both. Get the source from github, >>>>> build it (mvn clean install, I think) and place the needed jars in the FOP >>>>> lib directory. The fop.xconf does not need to be modified. >>>>> >>>>> >>>>> On Wed, Jan 29, 2014 at 7:12 AM, Valentina Cupac < >>>>> valentina.cu...@tp.rs> wrote: >>>>> >>>>>> That is what I would like to do ---- to preserving the original image. >>>>>> >>>>>> Just to clarify, you mentioned JDK JPEG image handling, is that what >>>>>> needs to be used for Tiff image handling (in my report I have just Tiff >>>>>> images), and if so, do any settings need to modified in the fop.xconf >>>>>> file? >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Luis Bernardo <lmpmberna...@gmail.com> >>>>>> Date: 2014-01-29 >>>>>> Subject: Re: Tiff image - color distortion >>>>>> To: fop-users@xmlgraphics.apache.org >>>>>> >>>>>> >>>>>> >>>>>> Two questions about CMYK on the same day! >>>>>> >>>>>> The JDK JPEG image handling functions cannot handle CMYK. If the >>>>>> images include a color profile then FOP can convert the images to RGB. To >>>>>> get FOP generate a PDF with images that preserve the CMYK colors you need >>>>>> to use a ImageIO library like TwelveMonkeys. Get it, compile it and place >>>>>> the JPEG related jar in the FOP lib directory (note that you will also >>>>>> need >>>>>> to add some of the core jars). >>>>>> >>>>>> >>>>>> On 1/28/14, 5:12 PM, Valentina wrote: >>>>>> >>>>>>> Hi I am including Tiff image in Pdf output. >>>>>>> >>>>>>> The problem is that it is not rendering the image correctly. For >>>>>>> example, the original Tiff image has much stronger contrast (i.e. some >>>>>>> very >>>>>>> dark sections, some very light sections), whilst the pdf output image >>>>>>> appears more greyish and noisy. >>>>>>> >>>>>>> Is this a known issue? >>>>>>> >>>>>>> Also I looked here: >>>>>>> http://xmlgraphics.apache.org/fop/1.1/graphics.html#tiff >>>>>>> >>>>>>> "FOP can embed TIFF images without decompression into PDF, >>>>>>> PostScript and AFP if they have either CCITT T.4, CCITT T.6, or JPEG >>>>>>> compression. Otherwise, a TIFF-capable Image I/O codec is necessary for >>>>>>> decoding the image. >>>>>>> >>>>>>> There may be some limitation concerning images in the CMYK color >>>>>>> space." >>>>>>> >>>>>>> Could someone explain the meaning of those sentences. Thanks. >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org >>>>>> For additional commands, e-mail: fop-users-help@xmlgraphics. >>>>>> apache.org >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
