On the AROS-Dev mailing list I've made a proposal to extend the AmigaOS (Clone) API with support - i.e. a corresponding PIX/PBAFMT - for 48/64 bit bitmaps.

I'd appreciate everyone interested to participate in the discussion thread there - it would be important to sync this API extension among AOS4/MOS and AROS anyway.

As a short summary - the idea is to add the following:

16:16:16 RGB (48 bit)
16:16:16: RGBA (64 bit)

in addition to the conventional:

8:8:8 RGB (24 bit)
8:8:8:8 RGBA (32 bit)

This is supported already today by PNG and TIFF and required for professional image processing / video editing systems - even though you won't find any conventional framebuffers which directly support it.

Still it would be helpful, if not the application but the OS would take care how to render/convert this "high data range" bitmap data.

Quote:

But exactly because of this what would be the point? There would be no benefit, and only extra overhead involved in conversion back and forth...

Besides, there's far more interesting floating-point formats which atleast are displayable with most recentish gfxcards .. either way, all these HDR formats are mainly suitable for editing, and as such I can't say I see the big use in OS handling of them, most of the time you are doing highly specialized tasks with them anyway...


- CISC

From the CyberGraphX documentation: Many of this pixel formats are device specific and should not be used, recommended formats are PIXFMT_LUT8, PIXFMT_RGB16, PIXFMT_RGB24 and PIXFMT_ARGB32.

Then you are wrong supporting RGBA, ARGB is recommended as device independent intermediate format. As Reggae will be an integral part of forthcoming MorphOS 1.5/2.0, it will incrementally replace datatypes, as it gets more decoders. Reggae uses ARGB32 as processing format (so called "common" format), and is prepared to support ARGB64 as well. ARGB64 will appear in Reggae when the first image format supporting 16 bits per component will be added, it is expected to be PNG.

Quote:

Mmmm...

BBRV already have announced MorphOS 2.0 here, so why are you surprised?

Quote:

The term "mmm" does not mean surprise, it's more like... er...

GIMME GIMME!

48bit??! Does it really makes a difference to the eye from a 32bit picture?

48bit??! Does it really makes a difference to the eye from a 32bit picture?

There is no such thing like 32-bit picture. It is 24-bit one with 8 bits just ignored or used for transparency, but still you have 8 bits per RGB component. And what is the difference between 24 and 48? You can probably see it only on intentionally prepared images (like some slow changing gradients). The difference is in processing, if you do a lot of operations on 24-bit data, rounding errors (and other errors caused by integer arithmetic) accumulate, and the quality degrades. So possibility to process image in 48 bit (+ optional 16-bit transparency) is an advantage, you get better quality, of course at a price of processing speed. For the same reason recording studios process sound in 24 bits (in spite you can't "hear" the difference between 16 and 24 anyway).

Krashan + CISC

Just wanted to say glad you guys are in the community! Very interesting thread.

magnetic

BTW you can call is "1.5" "2.0" "OS5" or "XrayAlphaOmega8" if you want but when the hell is it going to come out?

Quote:

Let me try... , when its done? .

Quote:


Wait wait wait, i have another one:

Both mos 1.5 and OS4 will come on efika


hmmmm....

(Both mos 1.5 and OS4 will come on efika)

Well, then I?ll purchase 1.5 Efikas of course !!

Quote:

wait .........

i hope mos 1.5/2.0 will work on x86 machines :P:P

And now the mantra is completed!

If you use 48bit internally for processing then yes, it does make a lot of difference. (that's obviously a HDR made out of 3 24bit raws)

Actual scanners use 48 bits technology.
So let see what will happen