View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014284 | ParaView | (No Category) | public | 2013-09-17 14:21 | 2015-01-11 08:23 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Utkarsh Ayachit | ||||||||
Priority | high | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | git-master | ||||||||
Target Version | 4.1 | Fixed in Version | 4.1 | ||||||
Summary | 0014284: Creating mid range buttons in the mapping data, color editor is wrong. | ||||||||
Description | Master, Linux, local server. Wavelet. Apply. Color by RTData. Color Editor. Enable opacity mapping for surfaces. Update. Now, on the horizontal bar in the Mapping data, click about 1/4 from the right side. Without moving this button, nothing should happen. But, the colors all shift! Update. The image changes. This is a bug. | ||||||||
Tags | No tags attached. | ||||||||
Project | Sandia | ||||||||
Topic Name | 0014284_fix_color_map | ||||||||
Type | incorrect functionality | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0031616) Ken Moreland (manager) 2013-09-24 13:53 |
First, I want to clarify that as far as I can tell, this bug really has nothing to do with the "Enable opacity mapping for surfaces" option. I get the described behavior regardless of whether that is enabled when clicking in the color bar, and I see no problem when adding a control point to the transparency area. Now, the problem, as properly diagnosed by Utkarsh in a previous email, is that the diverging color map will place a white point between any two control points of sufficiently different hue and strong enough saturation. Thus, when you add the control point at the 75% mark, the white point shifts from the 50% mark (between 0% and 100%) to about the 37% mark (between 0% and 75%). I don't think it is a good idea to change the behavior of the diverging interpolation. However, there is a trick that I think will basically solve the problem. If a control point has a sufficiently low saturation, it will be treated as the white point. Thus, if you add a control point at the 50% mark, it will hold the white point there when you add control points to its left or right. Incidentally, the white point should not be totally white (that will cause problems with the interpolation of the colors). The appropriate color to add to the 50% mark is [0.865,0.865,0.865] (or [221,221,221] if defined in unsigned char), not [1.0,1.0,1.0]. |
(0031617) Alan Scott (manager) 2013-09-24 15:07 |
Adding a note from Ken, explaining why to go to 221, 221, 221. The interpolation happens in polar coordinates with the axis of singularity along the black-grey-white axis. The point is to create a smooth arc at the white point rather than a point. The problem is that the color gamut of RGB space is a point there, so the curve leaves the color gamut if you go all the way to pure white. |
(0031640) Utkarsh Ayachit (administrator) 2013-09-26 16:28 |
commit 4276a9822d85847bf40a7f8b5a930d4c5a7b135e Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com> Date: Thu Sep 26 13:59:26 2013 -0400 BUG 0014284: Fixing LUT with white point in middle. As discussed on the bug report, adding a white-point in the middle of the default lookup table to overcome the shifting whitepoint problem as user added new control points. Change-Id: I49525d55a497d2b499d7cac63eee9911a9aa8793 |
(0031661) Utkarsh Ayachit (administrator) 2013-09-30 09:21 |
SUMMARY --------------------------------------------- Topics merged into master: 0014284_fix_color_map 13797_fix_chart_sizes 14287_fix_proxy_delete 14289_fix_extent_issues 14299_fix_contour_panel 14309-chart-selection-buggy fix_python_windows_coprocessing (VTK) forward-to-vtk-master (VTK) parallel-surface-lic-pv sqtk-fix-some-issues |
(0031793) Alan Scott (manager) 2013-10-30 22:35 |
Tested local server, Linux, using CAM data. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2013-09-17 14:21 | Alan Scott | New Issue | |
2013-09-17 16:52 | Utkarsh Ayachit | Assigned To | => Utkarsh Ayachit |
2013-09-17 16:53 | Utkarsh Ayachit | Target Version | => 4.1 |
2013-09-24 13:53 | Ken Moreland | Note Added: 0031616 | |
2013-09-24 15:07 | Alan Scott | Note Added: 0031617 | |
2013-09-26 13:59 | Utkarsh Ayachit | Topic Name | => 0014284_fix_color_map |
2013-09-26 16:28 | Utkarsh Ayachit | Note Added: 0031640 | |
2013-09-26 16:28 | Utkarsh Ayachit | Status | backlog => gatekeeper review |
2013-09-26 16:28 | Utkarsh Ayachit | Fixed in Version | => git-next |
2013-09-26 16:28 | Utkarsh Ayachit | Resolution | open => fixed |
2013-09-30 09:21 | Utkarsh Ayachit | Status | gatekeeper review => customer review |
2013-09-30 09:21 | Utkarsh Ayachit | Note Added: 0031661 | |
2013-10-21 08:16 | Utkarsh Ayachit | Fixed in Version | git-next => git-master |
2013-10-30 22:35 | Alan Scott | Note Added: 0031793 | |
2013-10-30 22:35 | Alan Scott | Status | customer review => closed |
2013-11-01 13:17 | Utkarsh Ayachit | Fixed in Version | git-master => 4.1 |
2015-01-11 08:23 | Utkarsh Ayachit | Source_changeset_attached | => ParaView master b3b25d0a |
2015-01-11 08:23 | Utkarsh Ayachit | Source_changeset_attached | => ParaView master 4276a982 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |