On Feb 20, 2015, at 12:45 PM, Elle Stone wrote:
I'm involved with GIMP development as it pertains to ICC profile color
management. GIMP is primarily used for processing photographic images and for
creating digital art.
As Lars said, I've been writing EXR files with ICC profiles from After
On Nov 12, 2014, at 4:36 PM, Peter Hillman wrote:
By analogy, there is a convention of how to store RGBA in a regular EXR and
what those values mean. You are permitted to store anything you like instead,
but there are no conventions.
I guess he's saying he wants there to be a convention so
At one time or another there has been some talk on the OpenEXR lists of making
an EXR-like movie format. Well, some friends and I are putting together a
project to try and do it:
http://www.indiegogo.com/projects/mox-file-format/
If you read some of the articles that quote me, you will see
On Aug 16, 2014, at 11:35 PM, Sean Y Chen wrote:
In Brendan Bolles's demo video, it seems that 10 is the limit for a
couple of the images, though one of them goes to 25 before reaching file
size 1.
Here's the code for the little program I wrote to generate those sequences.
I'm
On Aug 9, 2014, at 8:57 AM, Karl Rasche wrote:
I'd try starting at 85, and play around to see what an acceptable level might
be for the situation at hand. If the frame isn't going to undergo heavy
magnification, you might be able to push it higher. 200 might be find for
vacation photos,
On Aug 9, 2014, at 8:57 AM, Karl Rasche wrote:
The article says it's patented. Can we assume that the patents will be
available for free use in perpetuity, etc?
See PATENTS.
So it says in there, This grant does not include use of DreamWorks Lossy
Compression outside of the OpenEXR
On Jun 27, 2014, at 9:04 AM, Gonzalo Garramuno wrote:
xy x2y2 w h x yx2 y2 wh
displayWindow=(-100,-100 - -100,-100) [0-0] dataWindow=(0,0 - 399,299)
[399-299]
and thus no pixel or image at all.
Also t01.exr says it should have the
On Jun 17, 2014, at 7:37 AM, Nick wrote:
Instead of making a Windows branch, why don't we make an EXR 2.1 branch, and
note that one of the main features is the development of a cross platform Iex?
It seems to me like this is the whole point of writing an open source project
with git and
On Jun 14, 2014, at 2:07 PM, Nicholas Yue wrote:
I started the CMake configuration of OpenEXR base on the initial 1.X code and
recall the visual studio 6 solution having some post build command which does
that and I was mimicking that.
I might have understood those commands wrongly or
On Jun 14, 2014, at 7:57 AM, Nicholas Yue wrote:
The file b44ExpLogTable.h is generated from the executable b44ExpLogTable
Actually, it's in the repo. Is that intentional?
https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/b44ExpLogTable.h
Brendan
On May 30, 2014, at 7:52 AM, Paul Miller wrote:
I'm trying to build ilmbase 2.0.1 on Windows (visual studio 2008 SP1) and
there are numerous problems - the project files are there but they seem to be
incomplete. So far I've made these changes:
I've made some projects that I use when
On May 29, 2014, at 12:14 PM, Christopher Horvath wrote:
I'm compiling OpenEXR with exceptions, but the libraries that I am required
to link to beneath OpenEXR have the exception behavior disabled
(inconsistently).
I'm happy with the results that 2.1.0 passes all the regular tests for all
On May 21, 2014, at 1:59 PM, Richard Hadsell wrote:
No, there are several quantities that we want to track. A time stamp is just
one that can't fit into 32 bits. The others probably fit into 32 bits for
the near future, but it would be wise to allow for 64-bit integers just in
case.
I'm reading into an image buffer where the lines are ordered from bottom to
top, so I'm using a negative yStride like so:
frameBuffer.insert(name,
Slice(Imf::FLOAT,
last_line_ptr,
xStride,
On Apr 17, 2014, at 9:41 AM, Gonzalo Garramuno wrote:
I played with the farPlane but nothing changed. I uploaded the deep exr
image to:
http://www.datafilehost.com/d/c18914c3
Let me know if you can see the deep data with a tree shape or if the file is
broken.
Looks like this file
On Jul 17, 2013, at 8:31 PM, Lars Borg wrote:
An advantage of using XMP as the native metadata format, is that you can move
the entire XMP blob into other file formats that support XMP.
But do any non-Adobe programs use XMP? We could also embed the binary EXIF
data (possibly zipped) as an
On Jul 18, 2013, at 12:27 AM, Peter Hillman wrote:
Also, using zipped attributes to store chunks of XML does make the header
objects much lighter in memory, and is certainly far better than a whole heap
of separate attributes.
Although I believe Adobe After Effects and Adobe Premiere have
On Jul 18, 2013, at 3:08 PM, Larry Gritz wrote:
If you think any of these are supposed to represent the same data, you can
get into problems when an app reads the EXR file, just copies XMP to output,
but changes one of the related OpenEXR fields. Then you end up with an output
file that
On Jul 18, 2013, at 5:58 PM, Peter Hillman wrote:
What extra info do you get from the ICC profile?
Allowing ICC profiles worries me. Aren't EXRs supposed to store pixel values
in input scene referred linear-light encoded with the chromaticities
specified? That means images must be
In the insertChannels() function in ImfRgbaFile.cpp, the RY and BY channels are
added with pLinear set to true.
I wonder, should the Alpha channel get the same treatment? And maybe when I
add alpha channels to a header myself, should I also set pLinear to true?
I think this parameter is only
On May 1, 2013, at 2:04 PM, Dalai Felinto wrote:
[*] I actually had some linking problems with your Xcode solution (I don't
have cg here, and didn't want to get it), and in the end it made more sense
for me to look deeper in my problem instead of wasting time with linking
issues.
Yeah,
On Apr 30, 2013, at 10:54 AM, Dalai Felinto wrote:
Any help is appreciated. I'm implementing support for MultiPart in an
application and I can really use a reliable viewer (in oppose to use
exrmultipart -separate to check my results in old viewers).
If you just want to get exrdisplay built
On Apr 25, 2013, at 1:51 PM, Piotr Stanczyk wrote:
Please check across branches if the master does not have anything obvious in
them
https://github.com/openexr/openexr-images/tree/v2_beta.1/v2
Since 2.0 has been released and merged into the main branch, should we do the
same with
On Apr 3, 2013, at 9:17 AM, Christopher Horvath wrote:
I think it should be a config-level decision. People who (god-forbid) need to
maintain different thread-capable installations could then have their
packaging system deal with exr_omp, exr_posix, exr_cxx11, exr_tbb.
Right, it seems like
On Jan 15, 2013, at 7:41 AM, Pascal Jette (Contingent) wrote:
Why did you think that ChannelList being a subclass of IIFOptimizable was
odd? If this is a question of class name (a channel list is not, in itself,
optimizable), then yes, I think we could change the name of IIFOptimizable.
On Dec 27, 2012, at 2:19 PM, Morten Mikkelsen wrote:
Do you know of any reliable tool that will allow me to query
an openexr image? In regards to compression type and whether or not it's data
was half or full floats.
ProEXR for Photoshop will tell you which format your channels are in and
A colleague of mine ran some tests using playexr. He had one EXR sequence
containing just the regular RGB channels and another with 43 additional
channels added.
Maybe it will come as no surprise that the multi-channel files play much
slower, by a factor of 8 in this case.
Is this the
On Nov 14, 2012, at 11:47 AM, Florian Kainz wrote:
- All text strings are to be interpreted as Unicode, encoded as UTF-8.
Good discussion. I went ahead and quietly added UTF-8 support to my ProEXR
plug-ins for Photoshop and After Effects. Better to let the user read and
write everything
In OpenEXR 2.0, how about coming up with a formal position as to whether
channel names and string attributes are considered UTF-8?
If we want to do as little as possible, I think it'd be good to at least
include something in the docs like use UTF-8 at your own risk or maybe take a
tougher
On Aug 9, 2012, at 6:31 PM, Peter Hillman wrote:
ImfPartType.h defines static variables for the names of all known types, so
you can (and should) use Imf::DEEPSCANLINE instead of deepscanline
Ah, so it does! The code for exrdisplay, exrbuild, and exrmaketiled isn't
using them, and that's
I've started experimenting using v2 with my ProEXR plug-ins. So far so good -
just swapping in the new library with my old code lets me read the new files
with multi-part and deep data handled for me.
One thing that strikes me as a little odd is that the way to determine if an
image uses deep
On Oct 22, 2010, at 4:21 AM, Ronny Spiegel wrote:
char *tmpBuf = new char[width * height *
getPixelSize(channel.channel().type) * 2];
buffers.push_back(tmpBuf);
// calculate the address of pixel (0,0)
char *base = tmpBuf +
On Nov 24, 2009, at 2:56 AM, David wrote:
i've got two little questions:
I'm developping a c++-tool to convert OpenExr-images from Maya to
OpenExr-images which are optimized for Nuke (the tool creates a
data window and converts the images into scanline-mode with piz
compression).
Hey
On Dec 11, 2009, at 3:31 PM, Florian Kainz wrote:
I don't know how Nuke works, but if it reads scan lines top-to-
bottom or
bottom-to-top (as opposed to accessing the scan lines in random
order),
then reading chunks of 16 lines might actually be faster than reading
individual lines. Also,
On Jun 24, 2009, at 11:37 AM, Jonathan Litt wrote:
One can work around it with strings, or a series of scalars, but it
would be great if down the road double were directly available.
Or write your own attribute type, but I agree it should be part of
the standard distribution.
On Jan 24, 2007, at 4:30 PM, Florian Kainz wrote:
There is no particularly efficient way to read a single channel.
The channels in the file are interleaved per scan line or per tile.
This allows efficient random access to individual scan lines or tiles,
as well as sequential reading of the
36 matches
Mail list logo
