« Return to Thread: On-the-fly color space conversions
Re: On-the-fly color space conversions
by Lorne Laliberte
::
Rate this Message:
On Fri, Nov 28, 2008 at 11:07 AM, Stephan Assmus <superstippi@...> wrote:
>> Can you convert the images to RGB colorspace when they're loaded? Or
>> do you need to remain in their colorspace during processing?
>
> Yes. I am implementing an API which offers to store and use images in different format. Since there are no functions to directly access image data, but only for importing/exporting data, I could possibly fake the whole thing and pretend to be storing images in the requested format while I really only have one internal format. But I am guessing the whole point of offering different color spaces is to keep the memory requirements in check, so I better honor the requested formats.
That does bring up a good question -- is the goal to just be
compatible with loading/saving those kinds of images, or is the goal
to actually operate in their colorspace? If it's the latter,
converting on the fly might not be enough (except for when you're
converting "up" to a more detailed colorspace). It depends whether the
users want the detail (e.g. more bits per channel) to be preserved
during processing.
>> I wonder if it could be done using an adaptor, sort of along the lines
>> of agg_pixfmt_amask_adaptor.h or agg_pixfmt_transposer.h?
>
> I looked at agg_pixfmt_transposer.h, but that seems to be for changing the attached buffer at runtime only (because later classes in the pipeline take references to pixel format objects, which cannot be changed once intantiated).
>
> But I'll take another look at agg_pixfmt_amask_adaptor.h.
Ah, they're both pretty similar. I meant more that the conversion
could be done in an adaptor like that. I imagined it containing a
reference to the buffer containing the image in the other colorspace,
and then converting the spans on the fly into some temporary storage
for the span (scanline_storage_bin perhaps?).
>> What colorspaces do you need to convert from?
>
> Oh, these are different ones... 16 bit RGB spaces with and without differently sized alpha channels and 32 bit RGB with different channel order and all that multiplied with linear and sRGB versions. As well as luminance, grayscale images and even black and white bitmaps. :-)
Ouch, that's a lot of formats.
If you want to fake it, I won't tell... :)
- Lorne Laliberte
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>> Can you convert the images to RGB colorspace when they're loaded? Or
>> do you need to remain in their colorspace during processing?
>
> Yes. I am implementing an API which offers to store and use images in different format. Since there are no functions to directly access image data, but only for importing/exporting data, I could possibly fake the whole thing and pretend to be storing images in the requested format while I really only have one internal format. But I am guessing the whole point of offering different color spaces is to keep the memory requirements in check, so I better honor the requested formats.
That does bring up a good question -- is the goal to just be
compatible with loading/saving those kinds of images, or is the goal
to actually operate in their colorspace? If it's the latter,
converting on the fly might not be enough (except for when you're
converting "up" to a more detailed colorspace). It depends whether the
users want the detail (e.g. more bits per channel) to be preserved
during processing.
>> I wonder if it could be done using an adaptor, sort of along the lines
>> of agg_pixfmt_amask_adaptor.h or agg_pixfmt_transposer.h?
>
> I looked at agg_pixfmt_transposer.h, but that seems to be for changing the attached buffer at runtime only (because later classes in the pipeline take references to pixel format objects, which cannot be changed once intantiated).
>
> But I'll take another look at agg_pixfmt_amask_adaptor.h.
Ah, they're both pretty similar. I meant more that the conversion
could be done in an adaptor like that. I imagined it containing a
reference to the buffer containing the image in the other colorspace,
and then converting the spans on the fly into some temporary storage
for the span (scanline_storage_bin perhaps?).
>> What colorspaces do you need to convert from?
>
> Oh, these are different ones... 16 bit RGB spaces with and without differently sized alpha channels and 32 bit RGB with different channel order and all that multiplied with linear and sRGB versions. As well as luminance, grayscale images and even black and white bitmaps. :-)
Ouch, that's a lot of formats.
If you want to fake it, I won't tell... :)
- Lorne Laliberte
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general
« Return to Thread: On-the-fly color space conversions
| Free embeddable forum powered by Nabble | Forum Help |
