On 21 Feb 2011, at 23:49, Ken Thomases wrote:
> What makes you think the data copy is "extra"?
>
> If you read that AppKit release note, you'll see that NSImage may not be
> decoding the file contents right off the bat. For example, it mentions that
> "[i]f you initialize a NSImage from a JPEG
On Mon, Feb 21, 2011 at 3:49 PM, Ken Thomases wrote:
> On Feb 21, 2011, at 5:07 PM, Jonathan Taylor wrote:
>
> > So as far as my situation goes, what I'm after is an efficient way of
> starting from a path to some sort of raster image and obtaining a raw pixel
> buffer I can read. [Obviously if a
On Feb 21, 2011, at 15:07, Jonathan Taylor wrote:
> So as far as my situation goes, what I'm after is an efficient way of
> starting from a path to some sort of raster image and obtaining a raw pixel
> buffer I can read. [Obviously if actually reading from disk then the disk
> will be the bottl
On Feb 21, 2011, at 5:07 PM, Jonathan Taylor wrote:
> So as far as my situation goes, what I'm after is an efficient way of
> starting from a path to some sort of raster image and obtaining a raw pixel
> buffer I can read. [Obviously if actually reading from disk then the disk
> will be the bot
> I too have ran into this issue recently, with an old project that is
> half-resurrected.
>
> Performance was good in 10.5, but now horrible in 10.6. I'm not sure
> what to do instead.
>
> The CIImage docs say "Core Image images are immutable", and indeed I
> don't see any method like bitmapDat
On Mon, 21 Feb 2011 14:27:39 -0800, Quincey Morris said:
>OK, what I was *trying* to say is that NSBitmapImageRep in SnowLeopard
>is basically an immutable object pretending to be mutable. My suggestion
>was to use a really mutable object instead. I actually don't know if
>CGImage counts as mutabl
On Feb 21, 2011, at 13:53, Jonathan Taylor wrote:
> I'm actually doing a fair amount of work with the pixel data, but
> nevertheless this one copy (specifically the zero fills as well as memcpy) at
> the start takes considerably longer than the analysis itself.
I recently ran into this problem
On Feb 21, 2011, at 3:53 PM, Jonathan Taylor wrote:
> On 21 Feb 2011, at 21:29, Quincey Morris wrote:
>> 3. Use something else, such as CGImage, instead.
>
> Thanks. In this case I need to access every single pixel value unfortunately.
> I was using NSImages for convenience since I do display so
On 21 Feb 2011, at 21:29, Quincey Morris wrote:
> On Feb 21, 2011, at 13:19, Jonny Taylor wrote:
>
>> So do I understand it correctly that there is no way at all of peeking (read
>> only) at the pixels of a NSBitmapImageRep without triggering a copy? That's
>> a bit of a shame if so - guess I'll
On Feb 21, 2011, at 13:19, Jonny Taylor wrote:
> So do I understand it correctly that there is no way at all of peeking (read
> only) at the pixels of a NSBitmapImageRep without triggering a copy? That's a
> bit of a shame if so - guess I'll have to look into CoreImage.
If I understand the rele
>> I am looking at the performance of my code, and have found that rather a lot
>> of time is spent in [NSBitmapImageRep getBitmapDataPlanes]. This is rather
>> disappointing because I had assumed this was a 'trivial' way of getting a
>> pointer to the actual data store itself in the case of ras
On Feb 21, 2011, at 03:56, Jonathan Taylor wrote:
> I am looking at the performance of my code, and have found that rather a lot
> of time is spent in [NSBitmapImageRep getBitmapDataPlanes]. This is rather
> disappointing because I had assumed this was a 'trivial' way of getting a
> pointer to
I am looking at the performance of my code, and have found that rather a lot of
time is spent in [NSBitmapImageRep getBitmapDataPlanes]. This is rather
disappointing because I had assumed this was a 'trivial' way of getting a
pointer to the actual data store itself in the case of raster data.
I
13 matches
Mail list logo
