Re: Relieving memory pressure
Re: Relieving memory pressure
- Subject: Re: Relieving memory pressure
- From: "Gary L. Wade via Cocoa-dev" <email@hidden>
- Date: Sun, 7 Jun 2020 06:40:22 -0700
The vast majority of data used by a CGImageRef for any sufficiently
representable image is going to be its bitmap data (a 1x1 pixel image
wouldn’t), and you can calculate that by using CGImageGetBytesPerRow and its
neighbor APIs. If I recall from your previous posts, you are showing very
detailed scans of artwork. I believe NASA has a similar conundrum with their
telescope data; perhaps there’s some open source solutions there that might
help with your particular needs? Just a thought. Another thing I’d consider
(which I haven’t personally done) is looking at what Metal can provide; you
might have to drop down to that level for your needs. And it may be just as
important if you have a system with multiple large-format screens with so much
data.
--
Gary L. Wade
http://www.garywade.com/ <http://www.garywade.com/>
> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev
> <email@hidden> wrote:
>
> Good question.
>
> Well, some users want to feed my app with image files of 100 MB, even up to
> 400 MB (mostly jpeg compressed).
> Those images have resolutions of over 8k, sometimes over 10k.
>
> The slideshow app needs to be able to zoom into those images with at least a
> factor 2x scaling.
>
> So I figured that if someone has a 4k monitor, creating thumbnails with 8k
> resolution maximum should be sufficient.
>
> An 8k x 8k image needs at least 200 MB (1 byte per channel).
> I don't know how CGImage stores the uncompressed images internally,
> but my experience seems to indicate that it uses significantly more memory
> than that.
> (maybe it uses two bytes per channel, or even floats, or there is some other
> aux data)
>
>
>>
>> What do you need a 1GB thumbnail for? There is no screen that can display
>> that. For a slideshow app you could scale your thumbnails at creation time
>> to the users biggest screen pixel size, don’t you think?
>>
>> Christos Konidaris
>>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden