TIF/JPeg reading with LeadTools

[mvanrijnen]

Hi,

When we create TIFF/JPG files with GDPicture, we have troubles reading them with another application which uses leadtools.
Somehow it's impossible to read these files ?

[SamiKharma]

Hi,

Are those files being read by windows? If so, I would contact Leadtools.
If they are not read by windows, please provide a sample.

Best,
Sami

[mvanrijnen]

Files are displayed NOT displayed with Windows XP.
With Windows 7 they are displayed.
Sample i have to prepare, coming tomorrow.

[Loïc]

Hello,

My bet is the TIFF decoder of leadtools supports only 24-bit JPEG compressed page in TIFF with YCBCR color space while RGB can be used...
The next minor version of GdPicture will produce TIFF page in YCBCR color space when JPEG compression will be used. This should hep to maximize compatibility with the leadtools codec and also reduces the produced page size.

That said, let me suggest to use GdPicture instead of Leadtools

With best regards,

Loïc

[mvanrijnen]

We use LT in a product where we just simply can change to gdpicture (various reasons).
Thats the reason, we have to have this backwards compatibility.

[LTSupport]

My name is Mohamed and I am a LEADTOOLS support agent.
Like SamiKharma suggested, I recommend contacting us by sending a message to support@leadtools.com. We usually respond the same day and almost never exceed 2 business days.
If the JPEG that doesn't load with our toolkit appears to be a valid image file, please include it in the email and we will check it.
Our library support almost all JPEG and TIFF variations, including some sub-types not supported by the vast majority of other viewers, such as lossless JPEG or TIFF with JPEG2000 or JBIG compression.
If your file happens to be unsupported at the moment, we would gladly submit a feature request to our engineers.

[Loïc]

Hello Mohamed,

Thank you for promoting LeadTools here...

You can find 2 attached TIFF/JPEG images (gdpicture1.tif and gdpicture2.tif). My bet is one of the two is not correctly decoded by LeadTools. I've wrote a clue in the userComment tag to help your engineers

Original file (PNG)

TIFF/JPEG

gdpicture1.tif (72.22 KiB) Viewed 10270 times

gdpicture2.tif (67.11 KiB) Viewed 10270 times

With best regards,

Loïc

[mvanrijnen]

[Cosmin]

[gbruninx]

Hello Loïc,

you are correct that one of the tiffs (gdpicture1.tif) is not 'readable' with leadtools. Is it also possible to have an output from gdpicture like in gdpicture2.tif (if so, how) or is that one incorrect (could you tell us why)?

[I'm working for the same company as mvanrijnen.]

[gbruninx]

Hello Loïc,

Is it correct to think that this snippet below from the 10.1 release notes , has a correlation with this topic. If so, could you provide me some extra pointers (or an example) to what we need to do to change that tag.

Added support to determine if TIFF/JPEG codec must produce image including quantization tables and or Huffman tables (by altering the JpegTablesMode exif tag).

[Loïc]

Hi,

You can try a workaround: Before producing the file you can use this line of code.

Code: Select all

gdPictureImaging.TagSetValueString(ImageID, Tags.TagJPEGTablesMode, TagType.TagTypeByte, "1");

That said, it would be great if you could check with Leadtools support issues about they SDK. As mohamed said: "We usually respond the same day and almost never exceed 2 business days".

With best regards,

Loïc

[gbruninx]

Thanks for that tip. It becomes readable with jpegtablesmode 2 and 3.
What is the risk/downside in using that tag? Will there be problems with that tiff? Is that tiff "incorrect"?


JPEGTABLESMODE=0/1/2/3: (From GDAL 2.0) Configure how and where JPEG quantization and Huffman tables are written in the TIFF JpegTables tag and strip/tile. Default to 1.

0: JpegTables is not written. Each strip/tile contains its own quantization tables and use optimized Huffman coding.
1: JpegTables is written with only the quantization tables. Each strip/tile refers to those quantized tables and use optimized Huffman coding. This is generally the optimal choice for smallest file size, and consequently is the default.
2: JpegTables is written with only the default Huffman tables. Each strip/tile refers to those Huffman tables (thus no optimized Huffman coding) and contains its own quantization tables (identical). This option has no anticipated practical value.
3: JpegTables is written with the quantization and default Huffman tables. Each strip/tile refers to those tables (thus no optimized Huffman coding). This option could perhaps with some data be more efficient than 1, but this should only occur in rare circumstances.

[Loïc]

I don't see any risk. All options produce valid documents.
GdPicture use 1 as default.

Kind regards,

Loïc