Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001800 [Squeak] Graphics minor always 09-16-05 02:48 02-07-06 08:53
Reporter wiz View Status public  
Assigned To andreas
Priority normal Resolution reopened  
Status feedback   Product Version
Summary 0001800: [Fix] Manifying a color form would change its colors.
Description When colorforms and in particular the ImageMorph default form was magnified its colors were modified in the process. This provides the basic fix for that at least when smoothing = 1.
Additional Information This works somewhat for smoothings of 2 and 3 but the smoothing mechanism is judging smooth without knowing the true color map so the smoothing doesn't really look smoother. I haven't had a chance to look into that furthur. This seems to work great for smoothing=1.

The method is a direct variant of what ColorForm does for 'flipBy: centeredAt:'

Attached Files  ScaleColorFormFix-wiz.1.cs [^] (848 bytes) 09-16-05 02:48
 PopupThumbnails-wiz.4.cs [^] (12,946 bytes) 09-19-05 05:27
 ColorFormScaleRotFix-wiz.1.cs [^] (2,014 bytes) 10-12-05 04:38
 FormFlagsNFixes-wiz.3.cs [^] (4,692 bytes) 01-22-06 08:25
 FormMagnaRotaFix-wiz.1.cs [^] (3,683 bytes) 02-07-06 08:50

- Relationships

- Notes
(0002690 - 31 - 31 - 31 - 31 - 31 - 31)
ducasse
09-17-05 20:20

How can I reproduce the bug....
 
(0002703 - 286 - 310 - 310 - 310 - 310 - 310)
wiz
09-19-05 05:33

Hi Stef,

The easiest way to check it out is to load the cs I was working on when I needed to fix it. I've uploaded  PopupThumbnails-wiz.4.cs . If you try this on the ImageMorph default form it doesn't look much like the default imageMorph until the fix cs is loaded.

Cheers --Jer
 
(0002830 - 387 - 435 - 435 - 435 - 435 - 435)
wiz
10-12-05 04:42

Uploaded ColorFormScaleRotFix-wiz.1.cs .

This corrects the rest of the methods that needed correction.

From the preamble:

This is a fix up to allow color forms to be scaled and rotated w/o losing their class or their colors.

This follows the pattern set by filpBy:centeredAt: (ar 1999). We fix the main methods (the ones that call warpbit) and leave the feeder methods alone.
 
(0002963 - 330 - 330 - 330 - 330 - 330 - 330)
andreas
10-25-05 07:42

I have fixed the problem in the latest version but in a rather different way, by making such ColorForms return 32bit deep forms. Contrary to your solution this will always work at the expense of some memory being wasted. This seems to be a safer way of going about this issue - it leaves us room for optimizing for memory use now.
 
(0002995 - 730 - 776 - 776 - 776 - 776 - 776)
wiz
10-27-05 06:57

Arrrgh. (What's the emoticon for a wounded sigh?) A 32bit deep form is still a form and not a colorForm. What if the end result that you want is the colorForm? ColorForms are more important to elegant graphics than squeak acknowledges or is aware of. You sometimes want to paint by numbers with a limited pallette.

The space needed might not be a "small amount" in all applications. You might want space savings of a colorForm when doing animation stuff.

My larger unhappiness is with the loss of flexibility of the one way mapping of the Colorform into the Form.

Also could you explain when what you did with 'filpBy:centeredAt:' and I did with the other methods won't work? You must be seeing something I don't.
 
(0002996 - 1991 - 2103 - 2103 - 2103 - 2103 - 2103)
andreas
10-27-05 07:24

wiz - First I'm going to resolve this bug again, since (as far as I could reproduce it) the bug has been fixed. If you think the bug has not been fixed, please provide some evidence to the contrary.

Second, as to how the bug was fixed, it was fixed in the most general way possible, by converting the form into a 32 bit form (which is not lossy if you accept 8bit color components). Note that this leaves a client with a variety of possibilities if you care about, for example, you can just do a #colorReduced on the result of the magnification, e.g., "(aForm magnifyBy: 2) colorReduced" will preserve the colors just nicely.

Third, as for why it doesn't work in the general case, try:
  ((ImageMorph classPool at: #DefaultForm) magnifyBy: 0.5) colorsUsed size
You will notice that the colors used in the resulting (32bit) form (574) are more than can be represented by a ColorForm (limited to 256 colors). In the general case, due to supersampling you have to assume that all colors can possibly be constructed, there is absolutely no guarantuee that the set of colors is limited to the ones you're inputting.

Fourth, you can limit the number of colors by restricting the "cellSize" to one, e.g., disable the supersampling done by WarpBlt. However, that is a severe restriction, and I see no good reason why we should disallow super-sampling on ColorForms, in particular because the methods in question can be given the "cellSize" as an extra argument (so if you care use a cellSize of 1). Which ultimately brings us to...

Fifth, if you wish to preserve the ColorForm'ness in those special cases where it is indeed possible to preserve it, please submit code that does so. I'll happily integrate it.

Right now I see the situation as: The bug is fixed and if you need a ColorForm you can use #colorReduced, so everything else is a mere space optimization. If you need this optimization I'll be happy to integrate it, just submit a feature request with the code that does it.
 
(0003515 - 694 - 850 - 850 - 850 - 850 - 850)
wiz
01-16-06 21:17

Hi Andreas,

I am reopening the issue again. (Sigh)

In the lastest 3.9a (6713) the problem is still evident.

In a workspace evaluate:

-----

[ :m | m image: (m image magnify: m image boundingBox by: 2 ). m changed ]

value: (ImageMorph new openInWorld center: Display center )

----

this will get a color mangled copy of magnified image morph.

I realize you probably have a fix and it has not gotten into 3.9a yet.

I can't offer any patches until I see at least what you have done.

Could you upload your fixes to this report? (And get the release team what they need to update 3.9a?)

Sorry for the bother. Thanx for your help.

Your is service, -- Jerome Peace
 
(0003518 - 245 - 256 - 402 - 402 - 402 - 402)
andreas
01-17-06 01:03

Did you try this with the latest version in the repository http://source.squeakfoundation.org/Graphics.html [^]
 ? I haven't pushed the latest version over to the 3.9 inbox so it is quite possible that the current 3.9 doesn't include that fix yet.
 
(0003538 - 121 - 145 - 145 - 145 - 145 - 145)
wiz
01-18-06 21:04

Hi Andreas,

The most recent release I found was Graphics-ar.25.mcz. I'll try working w/ that.

Thanx -- Jeome Peace
 
(0003593 - 617 - 701 - 701 - 701 - 701 - 701)
wiz
01-22-06 08:23
edited on: 01-22-06 08:27

Hi Andreas, I looked thru the code and did some tests.

I found a couple of the scale parameters that were being passed were the reciprocal of what they were supposed to be.

I'm uploading a checkpoint changeset (FormFlagsNFixes-wiz.3.cs) that has the fixes along with some other stuff. Use it as a guide not a final say.

I've also seen a lot of code that looks like it could be the source of some of the rounding bugs I've been hunting. Some of the flags are in this checkpoint.

Please look at the preamble. The testing doits for the rotations are there.

Cheers,

Yours in service, -- Jerome Peace

 
(0003707 - 83 - 83 - 83 - 83 - 83 - 83)
wiz
02-07-06 08:53

Uploaded  FormMagnaRotaFix-wiz.1.cs which are the fixes for the reciprocal ratios.
 

- Issue History
Date Modified Username Field Change
09-16-05 02:48 wiz New Issue
09-16-05 02:48 wiz File Added: ScaleColorFormFix-wiz.1.cs
09-17-05 20:20 ducasse Note Added: 0002690
09-19-05 05:27 wiz File Added: PopupThumbnails-wiz.4.cs
09-19-05 05:33 wiz Note Added: 0002703
10-12-05 04:38 wiz File Added: ColorFormScaleRotFix-wiz.1.cs
10-12-05 04:42 wiz Note Added: 0002830
10-25-05 07:42 andreas Status new => resolved
10-25-05 07:42 andreas Fixed in Version  => 3.9
10-25-05 07:42 andreas Resolution open => fixed
10-25-05 07:42 andreas Assigned To  => andreas
10-25-05 07:42 andreas Note Added: 0002963
10-27-05 06:57 wiz Status resolved => feedback
10-27-05 06:57 wiz Resolution fixed => reopened
10-27-05 06:57 wiz Note Added: 0002995
10-27-05 07:24 andreas Note Added: 0002996
10-27-05 07:24 andreas Status feedback => resolved
10-27-05 07:24 andreas Resolution reopened => fixed
01-16-06 21:17 wiz Status resolved => feedback
01-16-06 21:17 wiz Resolution fixed => reopened
01-16-06 21:17 wiz Note Added: 0003515
01-17-06 01:03 andreas Note Added: 0003518
01-18-06 21:04 wiz Note Added: 0003538
01-22-06 08:23 wiz Note Added: 0003593
01-22-06 08:25 wiz File Added: FormFlagsNFixes-wiz.3.cs
01-22-06 08:27 wiz Note Edited: 0003593
02-07-06 08:50 wiz File Added: FormMagnaRotaFix-wiz.1.cs
02-07-06 08:53 wiz Note Added: 0003707


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
96 total queries executed.
52 unique queries executed.
Powered by Mantis Bugtracker