her
> case. There’s a couple of paths that lead to hitting zlib, and the channel
> naming should tell us which that is.
>
> My guess is there’s some degenerate case in the buffer sizing logic.
>
> Karl
>
> On Tue, Nov 20, 2018 at 9:49 PM Larry Gritz <mailto:l...@larrygrit
the specific combination of 1 channel
images + dwaa/dwab compression + tile size < 16.
Anybody have any insight, or has this bug been reported before?
Here's the OIIO issue if anyone wants to follow up there or reference it:
https://github.com/OpenImageIO/oiio/issues/1844
--
Larry Gritz
l..
p a bigger tab, or to make sure we know to check with you for
sponsorship next year.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
ling == sobbing in terror in the corner as the shambling revenant
>> shadow of CMake 2 groans and lurches forward belching broken features and ad
>> hoc syntax
>>
>>
>>
>> From: Openexr-devel > <mailto:openexr-devel-bounces+meshula=hotmail@nongnu.org>> on b
ax
>
>
> From: Openexr-devel <mailto:openexr-devel-bounces+meshula=hotmail....@nongnu.org>> on behalf of
> Larry Gritz mailto:l...@larrygritz.com>>
> Sent: Friday, July 13, 2018 11:47 AM
> To: openexr-devel@nongnu.org <mailto:openexr-devel@nongnu.org>
&g
ide the right -std=c++XX flags.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
with gcc -std=c++17.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
but likely cleaner than option
> a).
>
> Does the community have any strong positions on this either way?
> Francois.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
om> wrote:
>
> Are there any vendors for whom this would cause an issue? Else, I would vote
> for moving things forward
>
>
> On 10 August 2017 at 10:18, Larry Gritz <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
> Ugh, so it's worse than I thought.
>
C++17. Major C++ libraries such as QT are
> using C++11 nowadays, so it seems pretty safe to go beyond C++03 for modern
> applications, a lot of things are indeed much easier.
>
> Werner
>
>
> On 10.08.2017 00:20, Larry Gritz wrote:
>> In a test compile with gcc 7, I
2016 and 2017, and will be
C++14 for 2018.
-- lg
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
and --failpercent 0.1 are working
> well to address LSB error for my automated tests. For anyone new to oiiotool,
> --fail and --failpercent must go before —diff.
>
> Thank you,
> Ryan
>
>
>> On 31 May 2017, at 5:07 am, Larry Gritz <l...@larrygritz.com
>>
ng process,
but you nonetheless want the partially-written file to be as up to date as
possible so the process can be relaunched and more or less pick up where it
left off.
Anybody else run into this or have suggestions? Is there a way to force a flush
that I have not noticed?
--
Larry Gritz
o methods (EXR must be
> doing some operations with pixel data).
> outputFile.setFrameBuffer(pixelData.data(), 1, imageWidth);
> outputFile.writePixels(imageHeight);
>
> To sum up my problem – is this the correct way to pass image data to OpenEXR
> and retrieve the same image (but in EXR format)? I really don’t know why the
> color problem appears.
>
> Another question I’d like to ask is that I got the idea that the compression
> is done in writePixels method. Is that’s right? If it’s true, is there any
> possibility to compress image in memory without writing it to file?
>
> Thank you for your help!
>
> David
>
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
>
>
>
>
> --
> conrad gaunt
>
> www.cheapredhire.com <http://www.cheapredhire.com/>
> tel.07835915253
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
gt; submitting bugs and pull requests as long as the register keyword is there,
> I'm inclined to go ahead and remove the keyword anyway. If anybody is that
> concerned about a performance regression on the order of a few percent in the
> half-from-float constructor, speak now or forever hold
which is what the compressor
> fills during decode.
>
> This *should* just be a tile per thread, but it does look like it's held over
> the lifetime of the ImfTiledInputFile.
>
>
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
that internally it can use the provided application
> buffers;
>
> I am going to work on it when I get time and will notify you Larry if we get
> significant performance gains.
>
>> On 16 Sep 2016, at 19:12, Larry Gritz <l...@larrygritz.com
>> <mailto:l
quested.
>
> That avoids things like tons of extra decodes of a scanline strip of you are
> walking it scanline by scanline. But in the context of texturing, where
> you're always reading a full tile into cache, it's just overhead. There might
> be a sneaky way to flush that b
MB per texture. Even if it's caching all 1957 texture handles at once that's
> still an extra 1.98 MB per texture.
>
> On Fri, Sep 16, 2016 at 5:56 PM, Larry Gritz <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
> See how there were 1957 unique textures, b
; Images : 1957 unique
>>ImageInputs : 133168 created, 100 current, 771 peak
>>Total size of all images referenced : 166.0 GB
>>Read from disk : 55.5 GB
>>File I/O time : 6h 15m 42.1s (15m 1.7s average per thread)
>>File open time only : 1m 22.5s
>>
>>
pen time only : 1m 22.5s
>
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
ino <mesh...@hotmail.com> wrote:
>
> Such a PR would be great :)
>
>
>
>
>
> On Fri, Apr 15, 2016 at 10:15 AM -0700, "Larry Gritz" <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
>
> Thanks. I actually got it working o
able to get rid of this step (and move it to the unit tests if
> need be) from what I can remember.
>
> On 14 April 2016 at 13:51, Larry Gritz <l...@larrygritz.com
> <mailto:l...@larrygritz.com>> wrote:
> Thanks, Nick.
>
> Well, I *think* I'm doing approximately the same
EXR\\IlmImf\\Release\" /s /y
> xcopy \"$(MKVFX_BUILD_ROOT)\\IlmBase\\Iex\\Release\\*.dll\"
> \"$(MKVFX_BUILD_ROOT)\\OpenEXR\\IlmImf\\Release\" /s /y
> xcopy \"$(MKVFX_BUILD_ROOT)\\IlmBase\\IlmThread\\Release\\*.dll\"
> \"$(MKVFX_BUILD_ROOT)\\OpenEXR\\IlmI
ckage
> for more info on this (about half way down the page).
>
>
> I encourage you to read the documentation on packages if you want to know
> more: https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html
>
> Sorry, I know that was quite big for an ELI5 answer but I
for anything using
CMake?
> On Feb 15, 2016, at 5:26 AM, Ashley Whetter <ash...@awhetter.co.uk> wrote:
>
> If there aren't any comments on this then could it be merged?
>
> Ashley
> From: Ashley Whetter <mailto:ash...@awhetter.co.uk>
> Sent: 08/02/2016
and so on. I note that every large organization I've seen (such as
> Google, Facebook) just ports the builds to their proprietary build tools,
> rather than using autoconf or cmake.
>
> Am I alone in my failure to get CMake to work the way it is intended?
>
> Chris
>
> On
standard version.
>
> Ashley
> From: Piotr Stanczyk <mailto:piotr.stanc...@gmail.com>
> Sent: 23/01/2016 07:19
> To: Larry Gritz <mailto:l...@larrygritz.com>
> Cc: openexr-devel@nongnu.org openexr-devel@nongnu.org
> <mailto:Openexr-devel@nongnu.org>
>
gliest one that I've found yet, I'm embarrassed to say,
and I'd like to replace it and pretend my current one never existed.)
It would be great if a particularly good one was incorporated into the
ilmbase/openexr distribution itself as the canonical one that everybody could
use.
--
Lar
interchange without incurring pipelining - ie,
> tracking of originating scale and destination scale, and generating
> intermediates.
>
> Thanks,
> Jason
>
> PS. I have the same question poised for Alembic :)
>
>
>
>
> On Thu, Jan 14, 2016 at 11
I believe the following should fix this:
https://github.com/openexr/openexr/pull/170
> On Oct 27, 2015, at 2:08 PM, Larry Gritz <l...@larrygritz.com> wrote:
>
> https://github.com/openexr/openexr/blob/91015147e5a6a1914bcb16b12886aede9e1ed065/IlmBase/IlmThread/IlmThre
hin the stop of the Lock. Therefore multiple threads each reading
OpenEXR files under this condition will block against each other and refuse to
read exr files concurrently.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-de
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
this internally at The Foundry when I saw your pull request on oiio
a week or so back.
If anyone really wants it email our support and refer to this id: Bug 47739
- Add half float support to Tiff
On Friday, February 27, 2015, Larry Gritz l...@larrygritz.com wrote:
TIFF spec addenda may support
?
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr
single file exr for
these and have no reliable way to checkpoint your renders?
On 25 February 2015 at 16:27, Larry Gritz l...@larrygritz.com wrote:
Well, if a render job gets killed, we end up with a partial file. We can then
resume by starting a new render which takes an inventory of which
containing only
integer values?
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
implementation
deliberately does not enforce any naming conventions. If you have control
over all the tools which will read and write that data you are free to do
what you like. Don't expect it to work with any third party tools, though.
--
Larry Gritz
l...@larrygritz.com
an app to the dwaCompressionLevel in an analogous way.
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
in the system area but be speculatively building 2.2 or a
development branch somewhere else. The build system should look to the local
build for libraries before any system areas without having to mess with system
files, env variables, or special configure arguments.
--
Larry Gritz
l
16, 2014, at 10:55 AM, Piotr Stanczyk piotr.stanc...@gmail.com wrote:
That doesn't sound so good, Is this coming from the tarballs or the github
repo?
Let me take a look at it on a 10.10 box
Piotr
On 16 August 2014 10:41, Larry Gritz l...@larrygritz.com wrote:
I found compiling
:
Exemple: If I write a 640 * 360 image with a 10% overscan on each side, my
visible window is {0,0,640,360}, and the data window is {-64,-36, 704, 396 }.
Using 64x64 tiles, the image seems corrupt because the data window starts in
the middle of the first row of tiles.
--
Larry Gritz
l
-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Peregrine Labs
Pixar Animation Studios
Sebastian Sylwan
SolidAngle SL
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital
Please direct questions to: l...@imageworks.com
--
Larry Gritz
l...@larrygritz.com
___
Openexr
___
Oiio-dev mailing list
oiio-...@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman
)
for the native depth channels in deep exr 2.0 files, which seems an admission
that the old way is just legacy at this point.
My $.02: no harm in asking 3delight to add an option for this.
On Friday, May 30, 2014 12:21 PM, Larry Gritz l...@larrygritz.com wrote:
depth (aka Z) always
one more confusing
thing that can go subtly wrong when moving data between renderers.
-Daniel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
is
unsigned. So instead of a modest negative number, the debugger shows it as a
huge unsigned integer.
It seems to work fine, but I find it a little off-putting. Should I be
worried?
Brendan
--
Larry Gritz
l...@larrygritz.com
. You can deliver
scanlines out of order: they'll be buffered before writing.
With tiled images, you can write tiles in any order, but you must set
RANDOM_Y to allow it write without buffering.
On 11/04/14 12:02, Larry Gritz wrote:
Uh oh.
I knew about RANDOM_Y for scanline images
would not have done
the buffering without RANDOM_Y lineOrder. Was I just always wrong about this?
-- lg
On Apr 11, 2014, at 10:13 AM, Larry Gritz l...@larrygritz.com wrote:
OK, so let me restate it to make sure I have it right:
For scanline files, storage in the file is either
multithreading
enabled it is best to write the entire image in one call to writeTiles or
writePixels.
On 2014-04-12 06:35, Piotr Stanczyk wrote:
I am not sure about that ... let me check
Piotr
On 11 April 2014 10:19, Larry Gritz l...@larrygritz.com wrote:
Was it always like
/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
enough cluster into a
single deep sample with Z ZBack that span the depth range of the opaque
samples?
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
Borg b...@adobe.com wrote:
When will XMP be available in EXR?
One top-level attribute for lots of attributes.
Less speed penalty.
Lars
-Original Message-
From: Piotr Stanczyk pstanc...@ilm.com
Date: Tuesday, November 19, 2013 7:34 AM
To: Larry Gritz l...@larrygritz.com, Blecher
solve that problem as well.)
And image access speed is usually a greater concern.
Lars
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
in a single pixel are explicitly allowed to be unsorted
and overlapping. The previous version assumed that samples always
had to be sorted and non-overlapping, but that is not how deep
images are used in practice.
--
Larry Gritz
l...@larrygritz.com
a performant code sample which will tidy and
merge samples, one that can be used by client applications, is this a major
concern?
Chris
On Tue, Oct 29, 2013 at 4:38 PM, Larry Gritz l...@larrygritz.com wrote:
Can you elaborate on why the new document puts it on the head of the reader
.pdf___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
A from an image which
didn't have one stored.
On 25/10/13 20:12, Larry Gritz wrote:
Very helpful document, Florian, thanks.
I have some questions about the meanings of deep images (mostly from the
point of view of writing software to manipulate them).
Is the One True Accepted
something for Z. Or should flatten imply dropping the Z
channel entirely?
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
, 2013, at 4:31 PM, Piotr Stanczyk wrote:
really? I wasn't aware / there.
This is the only one I could find- which i think should be fixed
https://github.com/openexr/openexr/pull/62
- Piotr
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel
Is there any imposed size limit on OpenEXR 2.0 metadata? String length or
otherwise? Could you shove a truly huge string, or a big binary blob of some
sort into exr metadata?
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
it if the OpenEXR library were to make it standard.
Brendan
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com
I know that libIlmImf is reentrant/threadsafe with two threads reading from
separate open files. But is it known to be safe, or not, for two threads to be
simultaneously do a readTiles() or readPixels() from the same open inputPart?
--
Larry Gritz
l...@larrygritz.com
, the fastest way to read EXRs is to read as much of the file as
possible in a single call, and let the EXR library manage its own threads.
Ha ha, yeah, until you have 2 TB of image files you're accessing incoherently.
--
Larry Gritz
l...@larrygritz.com
'
'U' 'V'
- separated with a dot; the Pass name, like AO, Color, Diffuse.
- separated with a dot: the Layer name, like Backdrop or Characters
Or, share info here about your product's conventions, then we can try to get
things compatible a bit :)
Thanks,
-Ton-
--
Larry Gritz
l
should be outside the scope of OpenEXR.
- Jim
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l
reproduce your steps in a moment. In the meantime, could I ask to see if
running bootstrap before the configure 'fixes' the installation issue?
Piotr
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https
a clean compile.
Here are the files I think are missed:
ImathExport.h
IexForward.h
IexMacros.h
IlmThreadExport.h
IlmThreadNamespace.h
IexExport.h
ImathNamespace.h
IexNamespace.h
Does this ring a bell for anybody?
--
Larry Gritz
l...@larrygritz.com
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
/composited.exr
There are multipart deep files alongside it, though they have very few
samples to keep the size down.
On 20/07/12 12:23, Larry Gritz wrote:
Maybe I'm overlooking something obvious, but are there any publicly
available OpenEXR deep and multi-part files that I can use to validate
reader
it?
Peter
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
time it
came up?
--
Larry Gritz
l...@larrygritz.com
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
to have a compilation of resolutions that
look suspect? ...
Piotr
--
Larry Gritz
[EMAIL PROTECTED]
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Ugh, sorry everybody. My bad. In conversing with Piotr, I discovered
that the problem was entirely my fault -- a path through the app where
the TiledOutputFile * was never freed, so its destructor was never called.
--
Larry Gritz
[EMAIL PROTECTED
77 matches
Mail list logo
