headers
Werner Benger | 3 Mar 22:06
Favicon
Gravatar

Writing a tiled Rgba image file with tiles given

Greetings,

  I found a limitation in the class TiledRgbaOutputFile as provided in the  
IlmImf
library, in that it seems to not allow writing a tile from a buffer that  
only
contains this tile. By default it assumes that the provided pointer is  
relative
to an absolute buffer that contains the entire image. However, the  
underlying
class "Slice" already supports such relative data, and it's straightforward
to just pass this parameter to the creation of such slices.

Here are the modifications I made to the library, as I did not find another
way to achieve the same. These changes seem to be simple and don't break  
any
existing code while it just works for me then.

Best regards,

	Werner

==========================
In file ImgTiledRgbaFile.h : 170

     void		setFrameBuffer (const Rgba *base,
					size_t xStride,
					size_t yStride,
					bool   relativeBase = false);
(Continue reading)

Permalink | Reply | 5 comments |
headers
Florian Kainz | 4 Mar 00:07

Re: Writing a tiled Rgba image file with tiles given

Hi Werner,

Thank you for your mail.

Class TiledRgbaOutputFile can already be used with a single-tile
buffer.  The base pointer in setFrameBuffer always points to the
memory location where pixel (0,0) would be if it existed.  If your
buffer contains only a single tile, and that tile does not include
pixel (0,0), then the base pointer just points outside the buffer.
This may seem weird, but it works.  For a more detailed explanation
please see section 2.2, Writing a Cropped Image, of this document:

     http://www.openexr.com/ReadingAndWritingImageFiles.pdf

Still, your library patch would make it possible to reduce the
number of setFrameBuffer calls when a file is read or written using
a single-tile frame buffer.

In its current form the patch is incomplete: the new flag has no
effect on YA (gray-scale + alpha) files.  Also, in order to be more
useful in conjunction with writeTiles (as opposed to writeTile),
setFrameBuffer should have separate "tile-relative coordinates"
flags for x and y.

Florian

Werner Benger wrote:
> Greetings,
> 
>  I found a limitation in the class TiledRgbaOutputFile as provided in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kevin Wheatley | 4 Mar 10:46
Picon

Re: Writing a tiled Rgba image file with tiles given

Florian Kainz wrote:
> memory location where pixel (0,0) would be if it existed.  If your
> buffer contains only a single tile, and that tile does not include
> pixel (0,0), then the base pointer just points outside the buffer.
> This may seem weird, but it works.  For a more detailed explanation

it is also relying on implementation defined/undefined behaviour in
the language standard - subtracting from the pointer results in a
location outside an allocated block of memory (give or take the one
past the end allowance) could result in all sorts of weird behaviour
depending on implementation by the compiler vendor.

I imagine on embedded systems your more likely to get problems or on
platforms where the address of the allocated memory block has a
smaller value vs the offset to base memory that the calculation
results in. This on some platforms could result in a calculation that
wraps to a very large memory address which could generare traps or
exceptions.

But this is a 'theory' rather than 'practice' statement on most
desktop platforms of course :-)

Kevin

--

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |
_________________________________________________________________________
Cinesite (Europe) Limited is a company registered in England and Wales
(Continue reading)

Permalink | Reply | 3 comments |
headers
Florian Kainz | 4 Mar 20:54

Re: Writing a tiled Rgba image file with tiles given

Hi Kevin,

I would agree with your statement about this being more of a
theoretical concern.  I don't know of any examples where the
pointer arithmetic for addressing pixels in the frame buffer
fails in practice.

As long as a C/C++ program runs in an environment that presents
applications with a linear address space, I don't see what kind
of compiler optimizations could affect the outcome of pointer
arithmetic.  At the machine code level pointers are just unsigned
integers with enough bits to uniquely identify any location in
the address space.  Adding to or subtracting from such an integer
always produces another integer, even though interpreting that
integer as a pointer may not yield the address of a valid object.

With large images it is possible that computing the base pointer
for setFrameBuffer produces a negative address.  However, actual
hardware performs unsigned integer arithmetic modulo 2^32 or 2^64
such that negative addresses wrap around to a large positive ones.
Later, the address calculations during during pixel reads or writes
will wrap around the other way and produce valid pointers to pixels.

It is true that the code relies on properties of pointer arithmetic
that are not guaranteed by the C++ standard.  But then, the
implementation of the "half" data type also relies on features
of the C++ implementation that are not guaranteed by the standard.

The C++ standard states that the results of certain pointer
subtractions and pointer comparisons are "unspecified."
(Continue reading)

Permalink | Reply | 2 comments |
headers
Werner Benger | 5 Mar 22:31
Favicon
Gravatar

Re: Writing a tiled Rgba image file with tiles given

Hi Florian,

  I was aware the sent in code was not comprehensive, but that could be
easily expanded, I can send in that code if it's of interest to be
added to the library. It seemed the underlying layer would just provide
some functionality that some higher-level API did not pass through.
Would easily fix those pointer arithmetic issues. This might also be
related to some other issue that I faced:

I had some problems with what I thought would be taken care of by
setting INCREASING_Y vs. DECREASING_Y in the header. I had expected
it to turn upside down an image, but neither exrdisplay, Photoshop
nor Irfanview did show a difference there. Instead, I'm setting up
the frame buffer with a call like this:

vector<Rgba> Pixels;
TiledRgbaOutputFile *Outfile;
	...
	Outfile->setFrameBuffer(&*Pixels.begin()+
				tileXSize*tileYSize-1,
				1,		        // xStride
				-tileXSize,		// yStride
				true		        // the pixels buffer is relative
				);

So it begins with the last row and advances backwards to the first
row. Is this the right way to do it? How would it be different from
INCREASING_Y vs. DECREASING_Y ?

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Florian Kainz | 6 Mar 20:34

Re: Writing a tiled Rgba image file with tiles given

Werner Benger wrote:

> I had some problems with what I thought would be taken care of by
> setting INCREASING_Y vs. DECREASING_Y in the header. I had expected
> it to turn upside down an image, but neither exrdisplay, Photoshop
> nor Irfanview did show a difference there. Instead, I'm setting up
> the frame buffer with a call like this:
> 
> vector<Rgba> Pixels;
> TiledRgbaOutputFile *Outfile;
>     ...
>     Outfile->setFrameBuffer(&*Pixels.begin()+
>                 tileXSize*tileYSize-1,
>                 1,                // xStride
>                 -tileXSize,        // yStride
>                 true                // the pixels buffer is relative
>                 );
> 
> 
> 
> So it begins with the last row and advances backwards to the first
> row. Is this the right way to do it? How would it be different from
> INCREASING_Y vs. DECREASING_Y ?
> 

Werner,

the lineOrder flag (INCREASING_Y or DECREASING_Y) does not change
the pixel coordinate system.  The flag affects only the order in
which the pixels are stored in the file.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J.C. Roberts | 9 Mar 00:06
Favicon

submitting patches?

Hello,

This is my first post to this mailing list, and I tried to RTFM for the
answer, but was unsuccessful. On neither savannah.nongnu.org nor
openexr.org  could I find out the preferred way to submit patches?

If you'd be so kind to drop-kick me towards the docs/faq on this topic,
it would be much appreciated.

Thanks.

--

-- 
J.C. Roberts
Permalink | Reply | 2 comments |
headers
Piotr Stanczyk | 9 Mar 22:45
Gravatar

Re: submitting patches?

J.C. Roberts wrote:
> Hello,
>
> This is my first post to this mailing list, and I tried to RTFM for the
> answer, but was unsuccessful. On neither savannah.nongnu.org nor
> openexr.org  could I find out the preferred way to submit patches?
>
> If you'd be so kind to drop-kick me towards the docs/faq on this topic,
> it would be much appreciated.
>
> Thanks.
>
>   
Hi.

You are welcome to send them to the administrators of the project; feel 
free to drop me a line.

Piotr
Permalink | Reply | 1 comment |
headers
J.C. Roberts | 10 Mar 04:18
Favicon

Re: submitting patches?

On Mon, 09 Mar 2009 14:45:08 -0700 Piotr Stanczyk <pstanczyk <at> ilm.com>
wrote:

> J.C. Roberts wrote:
> > Hello,
> >
> > This is my first post to this mailing list, and I tried to RTFM for
> > the answer, but was unsuccessful. On neither savannah.nongnu.org nor
> > openexr.org  could I find out the preferred way to submit patches?
> >
> > If you'd be so kind to drop-kick me towards the docs/faq on this
> > topic, it would be much appreciated.
> >
> > Thanks.
> >
> >   
> Hi.
> 
> You are welcome to send them to the administrators of the project;
> feel free to drop me a line.
> 
> Piotr
> 

Thank you. One of the OpenBSD developers suggested *explaining* the
reason for changes made by the patches. There is a very easy
work-around for the problem, so changing the OpenEXR code is entirely a
matter of correctness.

There are two main syntaxes for using the #include directive:
(Continue reading)

Permalink | Reply | 0 comments |
headers
J.C. Roberts | 12 Mar 12:35
Favicon

Re: submitting patches?

On Wed, 11 Mar 2009 22:20:28 -0700 Piotr Stanczyk <pstanczyk <at> ilm.com>
wrote:

> Hi  J.C.
> 
> Thanks for your time in addressing this issue. I wanted to sweep the 
> rest of the other modules to get an idea of how much work this would 
> entail.  This, from I can gather, has come up before in the context
> of building on windows and I've added it to our to do list.
> 
> We are currently at the end of identifying what outstanding work is
> to be done for the next release. A definite date has not been set for 
> release, but there is good momentum.
> 
> I'd like to download and archive the patches you mailed if that's
> fine with you.
> 
> Piotr

Hi Piotr,

The initial 45 patches in the archive on my server were done with the
typical filename.c <-> filename.c.orig method used for porting third
party software to all of the *BSD operating systems (i.e. software in
the "ports tree"). They will apply cleanly against OpenEXR 1.6.1, and
they will probably get them committed to the OpenBSD ports tree.

You can do whatever you like with my archive of initial patches, but I
think you might prefer if I pull the all current OpenEXR CVS modules,
and then diff against CVS?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane