AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2006.04.07 07:34 "[Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by yourpattern
2006.04.07 09:01 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Joris
2006.04.07 10:05 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTable s.", by yourpattern
2006.04.10 14:21 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Gerben Vos
2006.04.11 06:45 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTabl es.", by yourpattern
2006.04.11 08:33 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Joris
2006.04.11 09:54 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Gerben Vos
2006.04.11 10:12 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Joris

2006.04.07 09:01 "Re: [Tiff] LibTiff Suggestion, Need help to support application supplied JPEGTables.", by Joris

   Currently, whether in "tif_ojpeg.c" or "tif_jpeg.c" we can a comment like this:

/* We do not support application-supplied JPEG tables, so mark

the field not present */

tif_ojpeg.c is a read-only codec. I don't see how this makes sense in a read-only codec, the only JPEG tables relevant in tif_ojpeg.c are the ones read from the data.

In new-style JPEG compression, there's an option to supply JPEG tables in a dedicated tag. This enables skipping the tables in the strips/tiles, if the tables are exactly the same in all strips/tiles, so as to save some space.

I think the current rationale behind tif_jpeg.c is that it's using default tables anyway, so all tables are exactly the same in all strips/tiles, so it makes sense to use that JPEG tables tag to indeed save some space...

The only other sensible options the writing end of tif_jpeg.c could provide, is

  1. using per-strile (per strip or per tile) optimized JPEG tables instead of the default ones, not writing the JPEG tables tag.
  2. using per-image optimized JPEG tables instead of the default one, writing the JPEG tables tag.
  3. using per-strile application supplied JPEG tables, not writing the JPEG tables tag.
  4. using per-image application supplied JPEG tables, writing these to the JPEG tables tag.
  5. Option b) is not really an option. It would require two passes through the complete image data. LibTiff is build to deal with one strip/tile at the time.

It's quit useful if the use can specified it's own quantization tables for JPEG compression.

You seem to be asking for support for option d), though I'm not quite sure... (your message are real. hard to read.)

Can you confirm option d) is what you're after?

Also, can you please tell me why you think it is useful? I've missed the part where you explain why your custom supplied tables are a significant improvement over the default tables in your particular application.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html