Return-Path: <tiff-bounces@lists.osgeo.org>
Delivered-To: even.rouault@spatialys.com
Received: from spool.mail.gandi.net (spool5.mail.gandi.net [217.70.178.214])
	by nmboxes134.sd4.0x35.net (Postfix) with ESMTP id EA7A560280
	for <even.rouault@spatialys.com>; Wed, 24 Apr 2019 15:52:03 +0000 (UTC)
Received: from lists.osgeo.org (osgeo6.osgeo.osuosl.org [140.211.15.3])
	by spool.mail.gandi.net (Postfix) with ESMTPS id 79C00D8019D
	for <even.rouault@spatialys.com>; Wed, 24 Apr 2019 15:52:03 +0000 (UTC)
Received: from osgeo6.osgeo.osuosl.org (localhost [127.0.0.1])
	by lists.osgeo.org (Postfix) with ESMTP id 45837610882B;
	Wed, 24 Apr 2019 08:52:00 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com
 (mail-oln040092010099.outbound.protection.outlook.com [40.92.10.99])
 by lists.osgeo.org (Postfix) with ESMTPS id 7DB0C6108827
 for <tiff@lists.osgeo.org>; Wed, 24 Apr 2019 08:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GW8ynd7mQ8ejBGlM52nKCZsu6dOwKNmSOUHkPNwUhZ8=;
 b=mgZ+NZc1UiVqUq0qX+fa4MhmDdL1fYUW3eScHakZWYyJEmXueq1IL4kCsRUP2IidBZmw0wW7GHA6Xq1ldZFnEMhRXU6TI/10ToWf5VcKZZfVRO4xC+oeLnZg1H7ADzMQCW6IXIOAf7Hv2ScroiKH7dgeE/I6hxykCrzVP4eyYLs3NBwefA1GVY4N5a4lcRTIDEu9INtT5PmauypYUuDLCKpUSZwibJNNbv3ul3uu399bKDBUsK+37idzFZdo0JDMxKTSVsesTRW6PfA9Eel1Wa1YJhAtpKBiWZB8x4WalLrr+qpZRiyNrY5RiR2UdJT2iP44s/SFbjpZNmaPQ4G0iQ==
Received: from CO1NAM04FT034.eop-NAM04.prod.protection.outlook.com
 (10.152.90.55) by CO1NAM04HT005.eop-NAM04.prod.protection.outlook.com
 (10.152.90.138) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16; Wed, 24 Apr
 2019 15:51:57 +0000
Received: from BN6PR18MB1476.namprd18.prod.outlook.com (10.152.90.55) by
 CO1NAM04FT034.mail.protection.outlook.com (10.152.90.119) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.20.1771.16 via Frontend Transport; Wed, 24 Apr 2019 15:51:57 +0000
Received: from BN6PR18MB1476.namprd18.prod.outlook.com
 ([fe80::e0de:6af6:1016:d183]) by BN6PR18MB1476.namprd18.prod.outlook.com
 ([fe80::e0de:6af6:1016:d183%2]) with mapi id 15.20.1813.017; Wed, 24 Apr 2019
 15:51:57 +0000
From: Paul Hemmer <paulhemmer@hotmail.com>
To: Tiff List <tiff@lists.osgeo.org>
Thread-Topic: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to
 disc?
Thread-Index: AQHU+gVH11EMQvmVk0akv2wXUpmu66ZKQdwAgADrF4iAAB/+AIAACUKGgAAbXQCAAAWlSA==
Date: Wed, 24 Apr 2019 15:51:57 +0000
Message-ID: <BN6PR18MB14762962206549C359CDE7D5DD3C0@BN6PR18MB1476.namprd18.prod.outlook.com>
References: <BN6PR18MB1476011F1763330A6A342322DD230@BN6PR18MB1476.namprd18.prod.outlook.com>,
 <alpine.GSO.2.20.1904231615000.21429@scrappy.simplesystems.org>
 <BN6PR18MB147667BAC10CD562A3FA9373DD3C0@BN6PR18MB1476.namprd18.prod.outlook.com>,
 <alpine.GSO.2.20.1904240805590.14882@freddy.simplesystems.org>
 <BN6PR18MB14766DF1AA3397B4FC661C35DD3C0@BN6PR18MB1476.namprd18.prod.outlook.com>,
 <alpine.GSO.2.20.1904241021220.29259@scrappy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.20.1904241021220.29259@scrappy.simplesystems.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:2D327EA49C01D26098729E331364D64FED1EC622A847A59EF65F6F9E254C8362;
 UpperCasedChecksum:4A020FBD29E49307367D098440D3A41718B97004913571C80E0634544AA19B57;
 SizeAsReceived:7182; Count:43
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [QRlKVF294IxO40NpgAbX3v6gjSZ0ijHk]
x-ms-publictraffictype: Email
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
 RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);
 SRVR:CO1NAM04HT005; 
x-ms-traffictypediagnostic: CO1NAM04HT005:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-message-info: hs3SX5RW4E/xmv37X9oXI6Kht+1vbPRynw+IRhbS2tOxkaKbVyPh6b/s1yaH2OINf/jVTbWRqoaX0ez+o05UhBBrtbjFN6HjysgxXGC2dg9/xhueOFBODXkAYham9YH+N/tYt28bRDnl3csA/IgE12Oy2/DcxnwLrFUhQtXTCi6JO4ed+6k0sClehBJyXoeP
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b4a32ce-7d37-4f10-65ac-08d6c8ccc83a
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 15:51:57.6757 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT005
Subject: Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to
 disc?
X-BeenThere: tiff@lists.osgeo.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.osgeo.org>
List-Unsubscribe: <https://lists.osgeo.org/mailman/options/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=unsubscribe>
List-Post: <mailto:tiff@lists.osgeo.org>
List-Help: <mailto:tiff-request@lists.osgeo.org?subject=help>
List-Subscribe: <https://lists.osgeo.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5602013336917693392=="
Errors-To: tiff-bounces@lists.osgeo.org
Sender: "Tiff" <tiff-bounces@lists.osgeo.org>
X-GND-Status: LEGIT

--===============5602013336917693392==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_BN6PR18MB14762962206549C359CDE7D5DD3C0BN6PR18MB1476namp_"

--_000_BN6PR18MB14762962206549C359CDE7D5DD3C0BN6PR18MB1476namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Interesting points. Thanks!


________________________________
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Sent: Wednesday, April 24, 2019 11:31 AM
To: Paul Hemmer
Cc: Tiff List
Subject: Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to d=
isc?

On Wed, 24 Apr 2019, Paul Hemmer wrote:

>
>> Why do you allocate a buffer using _TIFFmalloc() and use memcpy() if
>> you could just pass the address (myOpenCV.data + myOpenCV.step * y) as
>> 'buf' to TIFFWriteScanline()?
>
> Good question. I inherited this code.  No need for the intermediate buffe=
r.

I am thinking that you should investigate how OpenCV works.  This is
appears to be powerful C++ code which provides a wrapper for the
pixels.  Perhaps it is actually OpenCV which is allocating memory
based on your access request since the underlying pixel store might
not be compatible with simple linear byte access and so it needs to
allocate temporary memory.

Libtiff was primarily written a long time ago when computers provided
very little memory (most computers at the time did not provide more
than 640k of RAM) so its implementation tries to be memory-efficient,
although it was implemented on SGI workstations which offered much
more memory than a typical PC.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, https://apc01.safelinks.protection.outlook.co=
m/?url=3Dhttp%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2F&amp;data=
=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaa=
aaaaaaaa%7C1%7C0%7C636917167023437825&amp;sdata=3DFQS%2F43T%2F0i4abdvtGU8uY=
dyj%2BFdrqhaPhOi1%2BmITu08%3D&amp;reserved=3D0
GraphicsMagick Maintainer,    https://apc01.safelinks.protection.outlook.co=
m/?url=3Dhttp%3A%2F%2Fwww.GraphicsMagick.org%2F&amp;data=3D02%7C01%7C%7C7c7=
f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C=
636917167023437825&amp;sdata=3DJU%2B0148TeOjUtuXrrO%2F7W36uoBQk0ojJmtkyK8%2=
Bglgs%3D&amp;reserved=3D0
Public Key,     https://apc01.safelinks.protection.outlook.com/?url=3Dhttp%=
3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2Fpublic-key.txt&amp;data=
=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaa=
aaaaaaaa%7C1%7C0%7C636917167023447836&amp;sdata=3D34gcz4kbctjeZFGDAQZBVi7i%=
2F%2FmvsxI%2Bbj9ZPaszEeo%3D&amp;reserved=3D0

--_000_BN6PR18MB14762962206549C359CDE7D5DD3C0BN6PR18MB1476namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
Interesting points. Thanks!</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Bob Friesenhahn &lt;b=
friesen@simple.dallas.tx.us&gt;<br>
<b>Sent:</b> Wednesday, April 24, 2019 11:31 AM<br>
<b>To:</b> Paul Hemmer<br>
<b>Cc:</b> Tiff List<br>
<b>Subject:</b> Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushi=
ng to disc?</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">On Wed, 24 Apr 2019, Paul Hemmer wrote:<br>
<br>
&gt;<br>
&gt;&gt; Why do you allocate a buffer using _TIFFmalloc() and use memcpy() =
if<br>
&gt;&gt; you could just pass the address (myOpenCV.data &#43; myOpenCV.step=
 * y) as<br>
&gt;&gt; 'buf' to TIFFWriteScanline()?<br>
&gt;<br>
&gt; Good question. I inherited this code.&nbsp; No need for the intermedia=
te buffer.<br>
<br>
I am thinking that you should investigate how OpenCV works.&nbsp; This is <=
br>
appears to be powerful C&#43;&#43; code which provides a wrapper for the <b=
r>
pixels.&nbsp; Perhaps it is actually OpenCV which is allocating memory <br>
based on your access request since the underlying pixel store might <br>
not be compatible with simple linear byte access and so it needs to <br>
allocate temporary memory.<br>
<br>
Libtiff was primarily written a long time ago when computers provided <br>
very little memory (most computers at the time did not provide more <br>
than 640k of RAM) so its implementation tries to be memory-efficient, <br>
although it was implemented on SGI workstations which offered much <br>
more memory than a typical PC.<br>
<br>
Bob<br>
-- <br>
Bob Friesenhahn<br>
bfriesen@simple.dallas.tx.us, <a href=3D"https://apc01.safelinks.protection=
.outlook.com/?url=3Dhttp%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2=
F&amp;amp;data=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9=
f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023437825&amp;amp;sdata=3DFQS%2F4=
3T%2F0i4abdvtGU8uYdyj%2BFdrqhaPhOi1%2BmITu08%3D&amp;amp;reserved=3D0">
https://apc01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.simp=
lesystems.org%2Fusers%2Fbfriesen%2F&amp;amp;data=3D02%7C01%7C%7C7c7f1a0ff78=
94abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63691716=
7023437825&amp;amp;sdata=3DFQS%2F43T%2F0i4abdvtGU8uYdyj%2BFdrqhaPhOi1%2BmIT=
u08%3D&amp;amp;reserved=3D0</a><br>
GraphicsMagick Maintainer,&nbsp;&nbsp;&nbsp; <a href=3D"https://apc01.safel=
inks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.GraphicsMagick.org%2F&a=
mp;amp;data=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f64=
0afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023437825&amp;amp;sdata=3DJU%2B0148T=
eOjUtuXrrO%2F7W36uoBQk0ojJmtkyK8%2Bglgs%3D&amp;amp;reserved=3D0">
https://apc01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.Grap=
hicsMagick.org%2F&amp;amp;data=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f=
2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023437825&amp;amp=
;sdata=3DJU%2B0148TeOjUtuXrrO%2F7W36uoBQk0ojJmtkyK8%2Bglgs%3D&amp;amp;reser=
ved=3D0</a><br>
Public Key,&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://apc01.safelinks.prot=
ection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfri=
esen%2Fpublic-key.txt&amp;amp;data=3D02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c=
8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023447836&amp=
;amp;sdata=3D34gcz4kbctjeZFGDAQZBVi7i%2F%2FmvsxI%2Bbj9ZPaszEeo%3D&amp;amp;r=
eserved=3D0">
https://apc01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.simp=
lesystems.org%2Fusers%2Fbfriesen%2Fpublic-key.txt&amp;amp;data=3D02%7C01%7C=
%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%=
7C0%7C636917167023447836&amp;amp;sdata=3D34gcz4kbctjeZFGDAQZBVi7i%2F%2Fmvsx=
I%2Bbj9ZPaszEeo%3D&amp;amp;reserved=3D0</a><br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_BN6PR18MB14762962206549C359CDE7D5DD3C0BN6PR18MB1476namp_--

--===============5602013336917693392==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGlmZiBtYWls
aW5nIGxpc3QKVGlmZkBsaXN0cy5vc2dlby5vcmcKaHR0cHM6Ly9saXN0cy5vc2dlby5vcmcvbWFp
bG1hbi9saXN0aW5mby90aWZmCg==

--===============5602013336917693392==--

