Hi Christoph,

this looks performance critical. Take a look at BalloonEngine >> #bitBlt:. A color map is slower than computing the target value, according to Tim (tfel).

This issue is not that critical for the release, is it?

Btw, you can easily try out different display depth via the world menu:



Best,
Marcel
Am 15.12.2019 12:15:41 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Any chance to fix this bug for 5.3?

The following would still be a functional workaround:


(
Reminder: The bug can be reproduced using
"Example 3"
f := Form extent: 1 asPoint depth: 16.
f colorAt: 0 @ 0 put: Color red.
g := f asFormOfDepth: 32.
g colorAt: 0 @ 0
Expected: Color red
Actual: (Color r: 0.973 g: 0.0 b: 0.0)
)

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
Gesendet: Montag, 9. September 2019 16:56:03
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?
 

> On 09.09.2019, at 15:53, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>
> Hi Tobias,
>
> oops, I mistook the depth with the number of bits per channel. Sorry and many thanks for your explanations!
>
> How would one fix the upscaling issue? Form>>#colormapIfNeededFor: returns nil in example 3, the comment in Color>>#colorMapIfNeededFrom:to: states this task is delegated to BitBlt. Is this comment wrong or is the defect in the primitive called that is in BitBlt>>#copyBits?
>
No, that part is only for cross-conversion of Forms and ColorForms
-t

> Best,
> Christoph
>
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
> Gesendet: Montag, 9. September 2019 14:56 Uhr
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?
> 
> Hi Christoph,
>
> > On 09.09.2019, at 13:25, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> >
> > Hi all,
> >
> > consider the following example (print it):
> >
> > "Example 1"
> > f := Form extent: 1 asPoint depth: 1.
> > f colorAt: 0 @ 0 put: Color red.
> > g := f asFormOfDepth: 2.
> > g colorAt: 0 @ 0
> >
> > Expected output: Color red.
> > Actual output: Color black!
>
> No, Forms of depth 1 are black and white, and of depth2 are gray.
>
> >
> > Other examples:
> >
> > "Example 2"
> > f := Form extent: 1 asPoint depth: 1.
> > f colorAt: 0 @ 0 put: Color red.
> > g := f asFormOfDepth: 32.
> > g colorAt: 0 @ 0 "--> (Color r: 0.0 g: 0.0 b: 0.004)"
>
> yes, because you go from black/white to 32bit. I would have expected r0g0b0, but there might some rounding go on.
>
> >
> > "Example 3"
> > f := Form extent: 1 asPoint depth: 16.
> > f colorAt: 0 @ 0 put: Color red.
> > g := f asFormOfDepth: 32.
> > g colorAt: 0 @ 0 "--> (Color r: 0.973 g: 0.0 b: 0.0)"
>
>
>
> Something's wonky here!
> If we do
>
>         (((Form extent: 1 asPoint depth: 16)
>                 colorAt: 0 @ 0 put: Color red)
>                 asFormOfDepth: 32)
>         pixelValueAt: 0 at 0
>
> we get
>         4294443008 (aka 0xFFF80000)  which is a 32bit value.
> But the meaning is
>
>         11111111 11111000 00000000 00000000
>         ^ alpha  ^ r      ^ g      ^ b
>
> which means that the r component is not  "upscaled" during the #asFormOfDepth: process o.O (see PS)
>
>
>
>
> >
> > I am not familiar with color depths, but afaik Color red could be stored exactly using only 1 bit? Do I misunderstand the concept or is this really a bad output?
>
> No, the first bit depth to support red is 4 bit.
>
> Have a look at Color class>>colorFromPixelValue: p depth: d
>
> BTW: You can use a ColorForm to work with your own palette, so that you can have for example a 1-bit form with 1=yellow & 0=red…
>
>
> Best regards
>         -Tobias
>
> >
> > (I came across to this when performing #collectColors: on an 8 bit ColorForm loaded from disk, which did not work as expected.)
> >
> > Best,
> > Christoph
>
> PS: PS:
> Color red is r:1.0 g:0.0 b:0.0 but stored in a different fashion:
>
> Color comment:
> "
> Think of Color's instance variables as:
>         r       amount of red, a Float between 0.0 and 1.0.
>         g       amount of green, a Float between 0.0 and 1.0.
>         b       amount of blue, a Float between 0.0 and 1.0.
> (But, in fact, the three are encoded as values from 0 to 1023 and combined in a single integer, rgb.  The user does not need to know this.)
> "
> that means "Color red" is stored as 0x3FF00000 or,
>
> 1111111111 0000000000 0000000000
> ^ red      ^ green    ^ blue
>
> that makes 10 bit per component.
>
> However, in the 16 bit form we have only 5 bit per component, so,
>
>         f := Form extent: 1 asPoint depth: 16.
>         f colorAt: 0 @ 0 put: Color red.
>         f pixelValueAt: 0 at 0.
>
> yields 0x7C00 aka
>
> 11111 00000 00000
> ^ r   ^ g   ^ b



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191219/bbac3ec4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 53539 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191219/bbac3ec4/attachment-0001.png>