Hi Matt,
Just for the record, the TIFF tools are also distributed to the MS4W
users as well, on the web mapping side of things ha (I use them often,
so when I find something useful I try to distribute them).
https://ms4w.com Cheers from the far east side.
-jeff
On 2022-01-18 12:41 p.m.,
> On Jan 18, 2022, at 9:28 AM, Kemeter, Mathias via gdal-dev
> wrote:
>
> Hi Even,
>
> thanks for the feedback.
>
> Let me briefly elaborate on the distinction between corporate and
> non-corporate contributors (…which I did not intend in the first place):
> As an individual, I can very w
Never mind! Paying attention to the version numbers answers the Q: Conda is
built from libtiff 4.x while GnuWin32 libtiff is back on version 3.x.
I’ll see if I can find a contact at libtiff.org about adding a line about the
library and tools being available via Conda as well as the other sources
A little off topic for this list but people here might know: I see Tiff Tools
for Windows binaries[0] haven’t been updated since 2006. Conda has Windows
libtiff packages which include the tiff tools executables.[1] Is the conda
variant actually newer than 2006 or is it just current packaging?
[
Thank you Frank and Even.
As is so often the case on this list, I now have answers, and an education. I
have been peripherally aware of the tiff tools from libtiff, but not enough so
that they came to mind when seeking to puzzle out things. I’m now updated. ;-)
-Matt
___
Hi Even,
thanks for the feedback.
Let me briefly elaborate on the distinction between corporate and non-corporate
contributors (…which I did not intend in the first place):
* As an individual, I can very well live with the general message and
‘sign’ the policy based on trust. As written be
Another comment is about "complicated registration process". I
sympathize but I don't really understand that. So it might be good to
say what's acceptable, which could be one of:
The SDK must be downloadable by a URL with no user interaction
It's ok to have a form which requires a na
Mathias,
Hi Even, hi everyone,
As we (SAP) are probably one of the triggers for formalizing this
policy, let me take a first stab from the perspective of a new
contributor trying to make a substantial contribution:
(My personal position is that a first contribution that is a substantial
on
Even Rouault writes:
> Greg,
>
> I will not respond point by point, but the message here is: "CMake
> support is available and believed to be in good shape into master
> based on our manual tests and initial CI configuration exercising it,
> it will replace autotools+nmake soon, be ready for it
Greg,
I will not respond point by point, but the message here is: "CMake
support is available and believed to be in good shape into master based
on our manual tests and initial CI configuration exercising it, it will
replace autotools+nmake soon, be ready for it and help polishing it".
There
Hi,
Greg Troxel wrote:
> If that is meant to apply mainly to drivers with proprietary SDKs, it
> looks fine. It's a little hard to tell which things apply to drivers
> that don't have proprietary dependencies.
I think that even drivers with no proprietary dependencies require a thorough
unders
unsubscribe
-Original Message-
From: gdal-dev On Behalf Of Greg Troxel
Sent: Tuesday, January 18, 2022 8:14 AM
To: Even Rouault
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding
substantial code additions
If that is meant to apply mai
If that is meant to apply mainly to drivers with proprietary SDKs, it
looks fine. It's a little hard to tell which things apply to drivers
that don't have proprietary dependencies.
For example:
Drivers require a designated responsible contact.
seems perhaps a bit much, perhaps not, for some
Even Rouault writes:
> The new CMake build system
> (https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent
> progress, and I believe that it should be in a production ready state
> on time for GDAL 3.5.0 (~ May). It is already very close to it
> according to a checklist I had cre
Hi Even, hi everyone,
As we (SAP) are probably one of the triggers for formalizing this policy, let
me take a first stab from the perspective of a new contributor trying to make a
substantial contribution:
* Having such a policy greatly increases transparency on what has to be
done to mak
Working link is https://github.com/OSGeo/gdal/pull/5128
Rob :)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
Please find in https://github.com/OSGeo/gdal/pull/3855a RFC
thatdescribes the policies that the GDAL project will apply to assess
substantial code additions, typically new drivers, in particular coming
for new contributors to the project.
Best regards,
Even
--
http://www.spatialys.com
> I find that if I do:
tiffcp sample-no-mask.tif,0 x0.tif
I get an "x0.tif" with just the jpeg image, and not the mask. That may
be helpful for you (without uncompressing the jpeg image).
tiffcp doesn't use the raw interface of libtiff, hence JPEG
decompression&recompression will occur.
t
18 matches
Mail list logo
