Hello
Are there any plans to include JPEG2000 compression (OpenJPEG, for example)?
Thank you.
___
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff
> > I am really unclear on whether there will be fallout from tools removal.
> I have scripts that use tiff2ps. ImageMagick can convert tiffs to ps, but
some versions of ImageMagick shift or scale the image. tiff2ps works.
> I think that with a ps-based workflow, tiff2ps is the best tools to
>> William - are you (and others) still working with a PS-based workflow?
Why not move ot something more modern (aka PDF)?
I may even agree with that somewhat, but tiff2pdf was also deprecated. And
don't point me to ImageMagick and such like, it's not the same thing, some
of the
Is 4.4.0 or 4.5.0 the current release of LibTIFF?
This page http://www.simplesystems.org/libtiff/ says:
LibTIFF 4.5.0 documentation
(.)
Latest Stable Release v4.4.0
The following repo files contain conflicting information:
VERSION --> 4.4.0
configure.ac -->
Of course this:
if(WEBP_SUPPORT)
target_link_libraries(tiff PRIVATE WebP::WebP)
string(APPEND tiff_requires_private " libwebp")
target_link_libraries(${PROJECT_NAME} PRIVATE "C:/build/lib/libsharpyuv.lib")
endif()
can be simplified to this:
if(WEBP_SUPPORT)
Salutations to all
Due to some recent changes in the WEBP source code, building the dynamic
libtiff library with WEBP support started giving the following error messages:
libwebp.lib(picture_csp_enc.obj) : error LNK2001: unresolved external symbol
SharpYuvConvert
I found a temporary way of doing this without editing the source.
On cmake command line:
-DCMAKE_PROJECT_INCLUDE=my_include_file
‘my_include_file’ has the following contents:
link_libraries("C:/build/lib/libsharpyuv.lib")
This is not very elegant, because it inserts the library
> Based on the error you're getting, I assume you're building against
> static WebP? Otherwise it should stay happily hidden behind the DLL façade.
Yes, I am building against static WebP.
___
Tiff mailing list
Tiff@lists.osgeo.org
While trying to compress any TIFF with JPEG compression, using either tiffcp or
tiffcrop, the following error messages appear:
JPEGSetupEncode: RowsPerStrip must be multiple of 8 for JPEG
JPEGSetupEncode: RowsPerStrip must be multiple of 16 for JPEG
(this depends on whether we want a RGB
> I'm leaning towards releasing 4.5.1, with the current state of master, as the
> last version shipping with tiffcrop, tiff2pdf and tiff2ps
> being built with autoconf/cmake, with a warning in the release notes noting
> they will be moved into archive/tools for 4.6.0.
If that is indeed the
> tiff2ps and tiff2pdf seem to be also good candidates for moving into archive
> as they have a number of reported security related issues and a significant
> code size. Their functionality is (at least mostly) covered by the convert
> utility of ImageMagick.
We use tiff2pdf and tiff2ps
The tiffcrop is inverting RGB and YCbCr output when using jpeg compression.
The stated YCbCr default (no format specified) works correctly:
'tiffcrop -c jpeg infile.tiff outfile.tif' the output is a YCbCr
file (default behavior)
'tiffinfo outfile.tif'
> A quick check tells me tiffcp does suffer from this bug:
I don't think so. tiffcp's default is YCbCr and the "r" option specifies RGB,
which is exactly what 'tiffinfo' is showing.
-c jpeg[:opts] compress output with JPEG encoding
#set compression quality level (0-100,
> There should be no reason for tiff2ps in 2024
.but I agree that having a
high quality, open source, TIFF->PDF solution benefits everyone.
I can agree with that and I think that the effort should be on tiff2pdf.
> Given the advances in PDF since the last time that tool was touched, it
would
> (...) It would be beneficial for his project (and others) if
> the deprecated/removed libtiff utilities are restored (with security
> fixes), if even as a different project from libtiff itself.
I strongly agree, in particular the 'tiff2ps' and 'tiff2pdf' tools. They are
immensely useful in
>> I am absolutely not keen on getting tiffcrop back.
Neither am I. I don't think it is really necessary.
>> My proposal will be to reactivate and maintain only the tools needed by
>> someone, especially those mentioned by you (fax2ps, tiff2bw, tiffdither,
>> tiff2ps, tiff2pdf, tiffcp).
I
>> I tested the YCbCr output cases and cannot reproduce the problem regarding
>> wrong colors, so I conclude that was fixed already.
>> I did not test the RGB output cases as those did not seem to be at issue
>> (other than the documentation part).
I would like to test it again but every
17 matches
Mail list logo
