<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Any chance to fix this bug for 5.3?</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">The following would still be a functional workaround:</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><img size="33318" id="x_img117185" tabindex="0" style="max-width:99.9%" src="cid:fd67b6ba-ce69-44a3-94d8-362b808bcc7e"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">(</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Reminder: The bug can be reproduced using</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div><b>"Example 3"</b></div>
<div><b>f := Form extent: 1 asPoint depth: 16.</b></div>
<div><b>f colorAt: 0 @ 0 put: Color red.</b></div>
<div><b>g := f asFormOfDepth: 32.</b></div>
<div><b>g colorAt: 0 @ 0</b></div>
<div>Expected: Color red</div>
<div>Actual: <span>(Color r: 0.973 g: 0.0 b: 0.0)</span></div>
<div><span>)</span></div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Montag, 9. September 2019 16:56:03<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
> On 09.09.2019, at 15:53, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> <br>
> Hi Tobias,<br>
> <br>
> oops, I mistook the depth with the number of bits per channel. Sorry and many thanks for your explanations!<br>
> <br>
> 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?<br>
> <br>
No, that part is only for cross-conversion of Forms and ColorForms<br>
-t<br>
<br>
> Best,<br>
> Christoph<br>
> <br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
> Gesendet: Montag, 9. September 2019 14:56 Uhr<br>
> An: The general-purpose Squeak developers list<br>
> Betreff: Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?<br>
> <br>
> Hi Christoph,<br>
> <br>
> > On 09.09.2019, at 13:25, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> > <br>
> > Hi all,<br>
> > <br>
> > consider the following example (print it):<br>
> > <br>
> > "Example 1"<br>
> > f := Form extent: 1 asPoint depth: 1.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 2.<br>
> > g colorAt: 0 @ 0<br>
> > <br>
> > Expected output: Color red.<br>
> > Actual output: Color black!<br>
> <br>
> No, Forms of depth 1 are black and white, and of depth2 are gray.<br>
> <br>
> > <br>
> > Other examples:<br>
> > <br>
> > "Example 2"<br>
> > f := Form extent: 1 asPoint depth: 1.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 32.<br>
> > g colorAt: 0 @ 0 "--> (Color r: 0.0 g: 0.0 b: 0.004)"<br>
> <br>
> yes, because you go from black/white to 32bit. I would have expected r0g0b0, but there might some rounding go on.<br>
> <br>
> > <br>
> > "Example 3"<br>
> > f := Form extent: 1 asPoint depth: 16.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 32.<br>
> > g colorAt: 0 @ 0 "--> (Color r: 0.973 g: 0.0 b: 0.0)"<br>
> <br>
> <br>
> <br>
> Something's wonky here!<br>
> If we do <br>
> <br>
> (((Form extent: 1 asPoint depth: 16)<br>
> colorAt: 0 @ 0 put: Color red)<br>
> asFormOfDepth: 32)<br>
> pixelValueAt: 0@0<br>
> <br>
> we get <br>
> 4294443008 (aka 0xFFF80000) which is a 32bit value.<br>
> But the meaning is <br>
> <br>
> 11111111 11111000 00000000 00000000<br>
> ^ alpha ^ r ^ g ^ b<br>
> <br>
> which means that the r component is not "upscaled" during the #asFormOfDepth: process o.O (see PS)<br>
> <br>
> <br>
> <br>
> <br>
> > <br>
> > 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?<br>
> <br>
> No, the first bit depth to support red is 4 bit.<br>
> <br>
> Have a look at Color class>>colorFromPixelValue: p depth: d<br>
> <br>
> 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…<br>
> <br>
> <br>
> Best regards<br>
> -Tobias<br>
> <br>
> > <br>
> > (I came across to this when performing #collectColors: on an 8 bit ColorForm loaded from disk, which did not work as expected.)<br>
> > <br>
> > Best,<br>
> > Christoph<br>
> <br>
> PS: PS:<br>
> Color red is r:1.0 g:0.0 b:0.0 but stored in a different fashion:<br>
> <br>
> Color comment:<br>
> "<br>
> Think of Color's instance variables as:<br>
> r amount of red, a Float between 0.0 and 1.0.<br>
> g amount of green, a Float between 0.0 and 1.0.<br>
> b amount of blue, a Float between 0.0 and 1.0.<br>
> (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.)<br>
> "<br>
> that means "Color red" is stored as 0x3FF00000 or, <br>
> <br>
> 1111111111 0000000000 0000000000<br>
> ^ red ^ green ^ blue<br>
> <br>
> that makes 10 bit per component.<br>
> <br>
> However, in the 16 bit form we have only 5 bit per component, so, <br>
> <br>
> f := Form extent: 1 asPoint depth: 16.<br>
> f colorAt: 0 @ 0 put: Color red.<br>
> f pixelValueAt: 0@0.<br>
> <br>
> yields 0x7C00 aka<br>
> <br>
> 11111 00000 00000<br>
> ^ r ^ g ^ b<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>