Provide access to data offset in WritableRaster in Java 9

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Provide access to data offset in WritableRaster in Java 9

Peter A
Apologies since this probably not the correct list, but I was referenced here from another Java list. I've actually been getting bounced around to a few mailing lists. I'm hopeful that this is the right now!

Background: 
The high level API in a BufferedImage is very very very slow.  To get around that problem, in previous versions of Java, the internal rasters which were defined in sun.awt.image were accessed.   Doing so enabled real-time computer vision in Java. 

Problem:
Accessing the low level Rasters is no longer practical in Java 9.  After this problem was reported by one of my users I looked into it and *almost* found a work around  Unfortunately the higher level WritableRaster does not provide access to the offset inside its internal data array.   This makes processing of subimages impossible.  My suspicion is that it is most likely an oversight because it provides access to every other piece of information needed and the raw data.    It would be great if getDataOffset() could be moved into WritableRaster or one of its parents instead of being hidden in children of WritableRaster which are no longer accessible.

Just to clarify the raw arrays are stored inside of a DataBuffer and that data structure contains an offset. This offset is always set to zero and the offset inside of WritableRaster is what is needed, e.g. IntegerInterleavedRaster.getDataOffsets().

Thanks,
- Peter

--
"Now, now my good man, this is no time for making enemies."    — Voltaire (1694-1778), on his deathbed in response to a priest asking that he renounce Satan.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Provide access to data offset in WritableRaster in Java 9

Philip Race
Hello,

Yes this is the right list, and my reply on jigsaw-dev stands  :-

Sounds like you were accessing jdk internals and found that you
mostly can do away with that except for sub-images.

What you should really do is file an issue at bugs.java.com as
client-libs/2d for cat/subcat.

If this had been raised earlier in JDK 9 development - we could have
looked into
it in time. Now it will have to wait for a follow on release.

-phil.

On 7/13/2017 12:13 PM, Peter A wrote:

> Apologies since this probably not the correct list, but I was
> referenced here from another Java list. I've actually been getting
> bounced around to a few mailing lists. I'm hopeful that this is the
> right now!
>
> Background:
> The high level API in a BufferedImage is very very very slow.  To get
> around that problem, in previous versions of Java, the internal
> rasters which were defined in sun.awt.image were accessed.   Doing so
> enabled real-time computer vision in Java.
>
> Problem:
> Accessing the low level Rasters is no longer practical in Java 9.  
> After this problem was reported by one of my users I looked into it
> and *almost* found a work around  Unfortunately the higher level
> WritableRaster does not provide access to the offset inside its
> internal data array.   This makes processing of subimages impossible.  
> My suspicion is that it is most likely an oversight because it
> provides access to every other piece of information needed and the raw
> data.    It would be great if getDataOffset() could be moved into
> WritableRaster or one of its parents instead of being hidden in
> children of WritableRaster which are no longer accessible.
>
> Just to clarify the raw arrays are stored inside of a DataBuffer and
> that data structure contains an offset. This offset is always set to
> zero and the offset inside of WritableRaster is what is needed,
> e.g. IntegerInterleavedRaster.getDataOffsets().
>
> Thanks,
> - Peter
>
> --
> "Now, now my good man, this is no time for making enemies."    —
> Voltaire (1694-1778), on his deathbed in response to a priest asking
> that he renounce Satan.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Provide access to data offset in WritableRaster in Java 9

Philip Race
PS when filing the bug a self-contained (fully compilable) code example
showing what you would are trying to do will help.
Yes .. I guess you will need to use the internal API in that case but
it is a lot easier to unambigiously convey reqiurements with code if
possible.


-phil.

On 07/13/2017 12:18 PM, Phil Race wrote:

> Hello,
>
> Yes this is the right list, and my reply on jigsaw-dev stands  :-
>
> Sounds like you were accessing jdk internals and found that you
> mostly can do away with that except for sub-images.
>
> What you should really do is file an issue at bugs.java.com as
> client-libs/2d for cat/subcat.
>
> If this had been raised earlier in JDK 9 development - we could have
> looked into
> it in time. Now it will have to wait for a follow on release.
>
> -phil.
>
> On 7/13/2017 12:13 PM, Peter A wrote:
>> Apologies since this probably not the correct list, but I was
>> referenced here from another Java list. I've actually been getting
>> bounced around to a few mailing lists. I'm hopeful that this is the
>> right now!
>>
>> Background:
>> The high level API in a BufferedImage is very very very slow. To get
>> around that problem, in previous versions of Java, the internal
>> rasters which were defined in sun.awt.image were accessed.   Doing so
>> enabled real-time computer vision in Java.
>>
>> Problem:
>> Accessing the low level Rasters is no longer practical in Java 9.  
>> After this problem was reported by one of my users I looked into it
>> and *almost* found a work around  Unfortunately the higher level
>> WritableRaster does not provide access to the offset inside its
>> internal data array.   This makes processing of subimages
>> impossible.  My suspicion is that it is most likely an oversight
>> because it provides access to every other piece of information needed
>> and the raw data.    It would be great if getDataOffset() could be
>> moved into WritableRaster or one of its parents instead of being
>> hidden in children of WritableRaster which are no longer accessible.
>>
>> Just to clarify the raw arrays are stored inside of a DataBuffer and
>> that data structure contains an offset. This offset is always set to
>> zero and the offset inside of WritableRaster is what is needed, e.g.
>> IntegerInterleavedRaster.getDataOffsets().
>>
>> Thanks,
>> - Peter
>>
>> --
>> "Now, now my good man, this is no time for making enemies."    —
>> Voltaire (1694-1778), on his deathbed in response to a priest asking
>> that he renounce Satan.
>
>

Loading...