Colour history bug

If you grab a colour out of your history, then alter it the new colour isn't saved to the history. As the colorpicker has been removed (very annoying), it makes it almost impossible to recreate a colour created in this way. Can this get fixed (or better, bring back the picker)

Hi,
I have tried to reproduce this behavior but cannot reproduce this problem. After picking a color, changing it through the "Color Wheel", and making some strokes in the canvas, I can see the new color in the "Color History", please see attachment :
Thanks,
Jose

Similar Messages

Colour Profile Bug in CS4 32 bpc Mode?

This has been confirmed on both Mac and PC by different users
(this topic was confirmed on another list before posting here).
One may be working on an image that has a different colour profile
than set as default in colour settings. For example, colour settings
has Adobe RGB while the current document is in ProPhoto RGB. If the
ProPhoto RGB (16 bpc) file is taken to 32 bpc mode, the status message
reports that the file is in a modified linear space based on the input
profile. One may then perform USM, for example and then return to 16
bpc or 8 bpc mode.
Here is the bug: Once the ProPhoto RGB file is returned to 16 or 8
bpc, it now has the working RGB space tagged of Adobe RGB, rather than
the original ProPhoto RGB as input before 32 bpc conversion. This is
not just a tagging issue, the numbers have been converted to working
RGB rather than the input ICC that was tagged to the image prior to
entering 32 bpc mode.
ICC tagged image operations have been divorced from colour settings
since version 6, the document can reside in a space that is
independent of colour settings. I can't recall other operations that
change the files colour space and tag without user intention.
If using 32 bpc edits, to preserve the input space, one either has to
change their colour settings to match the document or convert the
document to working RGB.
So why this reversion to working RGB and not the document RGB - bug or
design feature/limitation? Did CS3 work this way, is it only my
version of CS4?
I have searched the help notes, this forum and other Adobe support docs,
however I could not find this issue documented.
Sincerely,
Stephen Marsh

Can anyone post a supporting argument for the current behaviour (design or bug). While in 32 bpc Photoshop "knows" what the original profile is (it is listed as being in a linear state), while on default conversion to lower bit depth the data is converted to working RGB, rather than the document RGB prior to conversion (if different to working RGB). Am I missing something - is this a good thing, should this be behaviour be changed?
OK, topic drift it is!
Buko/progress, it is not so much bit depth in this case, it is gamma encoding - or lack thereof. 32 bpc mode processes in linear gamma, which can have an effect on some operations for certain receptive image content (tonal moves, USM, interpolation etc).
As one example, some links to linear resampling can be found in the comments at this blog:
http://forensicphotoshop.blogspot.com/2008/11/resize-smaller-part-2.html
I prefer the 32 bpc route to linear processing rather than the alternative, which is 16 bpc and a hacked custom RGB profile set to gamma 1.0.
I don't like linear USM for output sharpening (nasty dark halo artifacts). However, for subtle capture/acquisition sharpening linear USM may be preferred for certain images. I generally sharpen with blend if sliders limiting the intensity of the light halo, which comes close to one aspect of linear sharpening (light halo reduction). This can also be achieved by blending the USM in two separate layers, set to darken and lighten blending with reduced opacity.
While on USM and gamma, there are some L* based RGB working spaces such as L*RGB or the new ECI RGB which behave the same way as Lab mode Lightness channel sharpening (when set to Luminosity blend). As the response of the Lightness channel is different to linear gamma and standard gamma encoded spaces, for some image content one may be preferred over the other as the processing space.
I would still like to explore the original topic/post before submitting a bug report. How do you think things should work?
Regards,
Stephen Marsh

File History Bug - Retains Only Last Version of Each File

I've just discovered what I believe to be a serious bug in File History on Windows 8.1. Here's what's happening:
My files are backed up using File History on a 1TB external USB hard drive with 17.5GB free. Currently 9GB of selected documents, etc., is being backed up and the aforementioned free space is what is available after 9GB has been backed up. My
File History settings are pretty normal / default. It backs up every hour. However, I've set it to keep saved versions 'until space is needed'. I noticed recently that, despite having plenty of free space, File History has only been retaining
the last copy of each of my backed up files. It didn't communicate this to me, e.g., via an error. I just happened to look to see how many versions were being retained.
I've played around with it a bit to investigate. First I blew away my FileHistory folder on the external drive and also the FileHistory folder from my user profile cache then set File History up again from scratch. I then ran a completely fresh
backup and changed some files and ran File History again. This did not fix the bug. File History was still retaining only the last file version and not notifying me of why or of any problem. I checked the FileHistory-Core and FileHistory-Engine
logs and, of course, no relevant errors were logged (typical for Windows event logs by the way).
I then tried changing the retention setting from 'until space is needed' to '1 year' and tested again by changing files and running File History. It appears to be retaining earlier versions and working now.
This definitely looks like a bug to me. Have Microsoft confirmed this and are they working on a fix ?
It makes me wonder if File History keeps a large free space threshold when you specify 'until space is needed', e.g., 10GB or 1% of drive size. When free space drops below this value, only one backup copy (the last one) is retained for each file. Is
this the case ? Why doesn't it communicate this to the user ?
Details:
O/S: Windows 8.1 Pro x64 (upgraded in-place from 8.0)
HDD: Western Digital MyBook 1TB (no 3rd party software installed for this).
"Keep a cool head and always carry a lightbulb."

Hi,
Windows use this following API to determine if previous retention should be deleted:
FH_RETENTION_TYPES which specifies under what conditions previous versions of files and folders can be deleted from a backup target
The operating system deletes previous versions from a backup target only when the target is full.
According to your description, your external drive should be less than 10% free space, this is a low disk space warning in system.
Above, this is just my hypothesis, I did some test in my environment, when the disk free space is more than 10%, I can see multiple versions of file history, but when it is less than 10%, it would just keep the latest modification version.
Alex Zhao
TechNet Community Support
Thanks for clarifying this Alex. I still consider this a bug / design flaw in Windows as it is pruning backups long before the drive is actually full. If there is, as you say, a large 10% low space threshold, the system should communicate to the
user that it is pruning all but one copy of backup files. Could this be logged as a bug please ?
"Keep a cool head and always carry a lightbulb."

IE History bug

In short:
I have an .aspx page that contains a flash object, using
swfobject, that communicates with the page via javascript. When
clicking the back button in IE it takes me two pages back, and not
to the previous page.
Details:
We use eclipse with FDT plugin to develop our flash apps in
AS2. I’m sitting with a problem when I’m communicating
a lot with IE using javascript. In normal scenarios the old getURL
is sufficient, but we’ve discovered that when you have a lot
of calls IE doesn’t handle it to well. So we use a queue
solution with the setinterval to give it a short breather, and it
works like a charm.
The scenario on the page is a search button….the search
brings back the results in href style and the user can then browse
to the relevant answer. If he doesn’t like it he will push
the Back Button on the IE browser. Now it jumps back two pages, so
you have to type in the search criteria again. If you push it
again, it goes to the page it should have gone to!
It seems that the history stack goes funny in IE as soon as
we have a flash component that does a lot of talking. If we remove
the flash object it works fine. There is no bug in the code as we
use this getURL() everyday…it’s just when we have a lot
of JS communication.
Have any of you come across something like this?
If so…solution?
Or any ideas?
Thanks!
PS: Firefox works 100%

Hello,
Make the MCUF_layout_11.gif 627px wide instead of 637px wide.
Just change the width in the properties window for this
temporary test.
Does it still drop now?
If so, how about 617px...
Take care,
Tim
"liveonnoevil" <[email protected]> wrote in
message
news:g23njm$dlo$[email protected]..
>I am having a problem in ie 6 and i cant figure out which
bug it is. can
> anyone help point me to the right place to start
looking? heres a link to
> the
> site;
>
>
http://www.mcuf.org/test/index.html
>
> heres a link to images of how it looks in ie7;
>
>
http://www.mcuf.org/test/example_ie7.jpg
>
> ie 6;
>
>
http://www.mcuf.org/test/example_ie6.jpg
>
>
>
http://www.mcuf.org/test/base_style.css
>
> any suggestions??
>

Colour pallet bug? - changes colour but then goes back to original colour.

This seemed to happen randomly. It is on a blue colour and when I click on a new colour, e.g red, it selects it and you can see it is selected if you use brush tool you can draw in red, but the colour panel shows the original blue colour.. so it is difficult/confusing to choose the colour you want. Is this a bug or a simple mistake? Is there a fix? Thanks.

WINDOWLENE??
Yikes!
Cleaning Apple products:
http://support.apple.com/kb/HT3226

H.264 videos washed out colours/gamma bug. Does this really fix it?

Yea, that old chestnut. Having come up with this topic: http://discussions.apple.com/thread.jspa?threadID=1358418&start=0&tstart=0 where someone claimed to fix the problem by using the third party x264encoder for Mac and setting nclc atom to 6-1-6 and making sure the gamma 2.2 setting was unchecked. Although no one else apparently confirmed his solution worked and the topic eventually died.
I later found however after following a link someone posted this article: http://byteful.com/blog/2010/07/how-to-fix-the-h264-gamma-brightness-bug-in-quic ktime/
In it he apparently recommends the same course of action except he (judging by the screen shot) left it at the default of no nclc atom but made sure the gamma 2.2 setting was checked. Some comments seem to confirm it works.
The x264encoder is available for QuickTime from here: http://www.apple.com/downloads/macosx/video/x264encoder.html
I cannot test it currently. But added to my problem is I usually do my encoding on Windows anyway, and I use Handbrake to do the encodes and I get the same issues. So can anyone with the issue test these methods and see if one or the other works?
Either that or does anyone have another definitive fix for this problem?

I don't know why I bother.

Lightroom 2.1 History Bug with Edited File

I downloaded Lightroom 2.1 and now when I edit a file in Photoshop and then it comes back into Lightroom, if I click on one of the Presets, such as a B&W preset, then there is no way to get back to the edited file in color. The first entry in the History is the B&W preset, and I can't undo past that point to return to the color version of the edited file.
Seems like it's not making a "edit in photoshop" history item that allows me to return to the original.

I'm back trying to sort this problem out (got distracted for a couple of days by trying to get my monitor calibrated).
Rearranging the folder structure didn't help. But I now have a better organized catalog, so that's ok :)
What I did find is that if I import files into lightroom using the "file/import photos from device", then I can edit them normally afterwards (that is, when I save the file in photoshop cs3, the new file gets picked up correctly by lightroom and gets correctly stacked with the original). This is true even if the new files get added into the same directory structure that I'm having troubles with.
So it looks like the directory structure is a red herring. It looks like the problem is in the catalog, with the way that lightroom originally imported my files. I created my original catalog by allowing lightroom to read my elements 6 catalog.
It seems that I have this edit problem with all catalog entries that were imported from elements 6, but I don't have any problem with catalog entries that lightroom brings in directly (either through "import photos from device" or by adding a new folder to the lightroom catalog).
So right now it looks like there is a problem with the elements catalog conversion.
Is this a problem that anybody else has seen? Any suggestions for getting around it?
Doug

Flash Colour Management Bug?

Can anyone get the Flash application in the following link to return anything other than "Color Correction is not supported."
http://www.adobe.com/devnet/flash/quickstart/color_correction_as3.html
Does this mean that Colour management is Broken in Flash Player?
I have tried a bunch of browsers, Windows and Mac operating systems and tried using several different display profiles but cannot get this to return the correct value...
I have also configured my firefox about:config with the correct profile path (trying several different profiles)...
am i missing something?
Thanks!

The feature was browser independent. It even worked in IE < 9 which had never heard of color management. If I understand it correctly FlashPlayer gets the current primary display profile from the system not the browser and works with it. The browser independence was the most innovative part of this.
Anyway, whether color management works in Flash Player today or not is somehow intertwined with the wmode in use. Only wmode="window" works anymore. "opaque", "transparent", "gpu" and "direct" always give the stage.colorCorrectionSupport: unsupported status. Chrome's built in Flash player always gives that, too which makes sense considering what I wrote above. I have tested this on OS X, Win XP and Win7 64-bit today. On the latter I could not get it to work at all - might accessing the system's display profile be different on 64 bit windows or could it be a problem of having multiple screens on that machine? For testing I used the same ICC v2 display profile on all systems. I am very confident that in the past this worked with wmode="opaque" which I need to allow other things like lightboxes to be displayed above Flash elements.
The example http://www.adobe.com/devnet/flash/quickstart/color_correction_as3.html also uses wmode="opaque" so it fails today. Publishing the downlodable source files and viewing them with wmode="window" makes the feature work again. Could your team please fix this for the other wmodes - especially "opaque"?

Illustrator Colour Management Bug

Hello,
When I load in a CSF in illustrator CS 5.5 whose "CMYK profile" is not installed on a Mac, Illustrator Changes the CMYK profile to something else without changing the "settings" pull down menu to "custom...".
When i do the same in InDesign & Photoshop, the correct profiles are used as (i'm assuming) they are contained within the CSF file itself?
This means that i can have synchronized colour settings with totally inconsistent results because the ICC profiles are different from Mac to Mac & CS app to CS app etc.
Can you please fix this to work the same as Photoshop and InDesign?
Thanks!
Matt

The feature was browser independent. It even worked in IE < 9 which had never heard of color management. If I understand it correctly FlashPlayer gets the current primary display profile from the system not the browser and works with it. The browser independence was the most innovative part of this.
Anyway, whether color management works in Flash Player today or not is somehow intertwined with the wmode in use. Only wmode="window" works anymore. "opaque", "transparent", "gpu" and "direct" always give the stage.colorCorrectionSupport: unsupported status. Chrome's built in Flash player always gives that, too which makes sense considering what I wrote above. I have tested this on OS X, Win XP and Win7 64-bit today. On the latter I could not get it to work at all - might accessing the system's display profile be different on 64 bit windows or could it be a problem of having multiple screens on that machine? For testing I used the same ICC v2 display profile on all systems. I am very confident that in the past this worked with wmode="opaque" which I need to allow other things like lightboxes to be displayed above Flash elements.
The example http://www.adobe.com/devnet/flash/quickstart/color_correction_as3.html also uses wmode="opaque" so it fails today. Publishing the downlodable source files and viewing them with wmode="window" makes the feature work again. Could your team please fix this for the other wmodes - especially "opaque"?

Layer colour tagging bug

If I assign a colour to a layer and then change the layer to a Smart Object the colour tag is lost.
1) Open image
2) Duplicate (Ctrl+J) Background to create a Layer (Layer 1)
3) Right-click on the Layer 1 'Eye' icon and choose a colour (Red)
4) Right-click on Layer 1 and choose " Convert to Smart Object
5) The Red colour that was assigned in step 3 will now disappear.
Expected Result: Layers that have been assigned a colour should keep that colour even when converted to a Smart Object.
PS6 Build: m.415
Confirmed on both Windows7-64 and Vista64
Motherboard: Asus P6X58D-E
CPU: Intel Core i7- 960 (Not overclocked)
RAM: 24GB
Video: ATI Radeon HD5700
HD: OCZ-Vetiex2 120GB SSD (OS/Apps)
HD: WD600GLFS (Data)
HD: WD300GLFS PS (Scratch)
(This error has also confirmed by someone else using a Mac)
Russell

That might be what's going on behind the scenes. But I'm not sure most users will understand why adding a colour tag to a layer cannot be maintained when all they're doing is choosing to apply a layer option.
In my case I was organizing 20 small images on the canvas and found the colour tags very useful in that I could view and align/distribute various groups as per their assigned colour. I then decided that resizing was needed so I changed them all to SO's and that's when all the work I did assigning colours was lost. If the colour tag is being offered as a layer organization feature then it should be maintained when a common layer operation is performed.
Your explanation sounds as if converting a layer to a SO should also cause it to lose any name we've given that layer. But a layer name is not lost and remains intact. So why not the colour?
Russell

Gradient Map - CMYK colour change - Bug?

Hola all, I'm using a gradient map to make faux duotones for a project.
Some pages have a straightforward 'flat' 3 stop gradient applied (Darkpoint: 100, 95, 0, 45. Midpoint: 100, 75, 0, 0. Lightpoint: 75, 0, 0, 0.)
On other pages I have various images which I want to colour match to the gradient pages. So on the uppermost layer I've added a gradient map with the same CMYK values.
So far so good - everything looks pretty much as expected. HOWEVER - when I looked at the channels I notice a LOT of yellow was present in the images (I had expected none).
Sure enough, when I looked at the gradient map the CMYK values in the color stops had changed dramatically. I re-set them but the values will not stay 'locked'.
Whats going on?
PS. Changes to the underlying layers don't seem to effect the problem. I had thought this may be an Issue with the FOGRA 39 profile, but I have untagged and resaved the image to no avail. I'm working in CMYK in CS4 (11.0.2). Mac OSX 10.6.8

My take is that you are simply seeing the lossy conversion between CMYK and RGB. The values in the color picker appear to be fundamentally RGB based.
If I check the gradient color stops in the color picker by reopening the gradient dialog immediately after creating the gradient the CMYK values are preserved. If, however, I do any other operation, say click on the base layer, and then open the gradient, the values have changed. So it appears that once the gradient is incorporated into the work flow the CMYK - RGB conversions take place giving the results you see.
Paulo

History bug in Safari with latest update? (10.4.8)

It seems Safari is only remembering a day or two worth of history since the latest upgrade (10.4.8). I've cleared the cache, deleted the Safari preferences, etc... No good. This was never an issue prior to the upgrade.
Any ideas? It's really driving me nuts.

My History shows 5 days of activity. Have not seen any post on this board since the update describing a similar problem to Safari's History.
Have you modified the History parameters (number/days etc.) using a 3rd party application such as Safari Enhancer?
iMac G5 Rev C 20" 2.5gb RAM 250 gb HD/iBook G4 1.33 ghz 1.5gb RAM 40 gb HD Mac OS X (10.4.8) LaCie 160gb d2 HD Canon i960 printer

Safari 6.0 Colour refresh bugs

Hi just installed Mountain Lion and noticed some odd colour refreshing.
Take a look at www.plbconstruction.ca
it's an older site we made for a client. See the drop shadows under the house picture near the bottom of the page?
We usually make PNG's for that now, but back then we used JPG's. It use to work great with the older version of safari.
What's going on now?
Please help.

STILL HAVING THIS ISSUE only on OSX 10.8.4, Safari 6.0.5, on two MacBook Pros (2011)
do not have it on two Mac pros running 10.6x and 10.7x (or in any other web browser i've tested, including those running under 10.8.4)
on apapas.com I just completely tore the home page apart, colored Table (vs Cells), removed content from each Cell one by one and problem persists...

Graphics issues since latest 10.8.2 update

Last Friday, I applied the latest update to 10.8 (10.8.2?). Since then I have noticed a couple of issues, both of which appear to be graphics related. FWIW, my hardware is an early 2011, 15-inch MBP with discrete graphics (Radeon 6750M).
1. In one instance, I attached an external display to the Thunderbolt port (DVI adapter). The system switched to discrete graphics, and my onboard display suddenly had a very slight blue shade. The external display displayed color properly, only the onboard was affected. Unplugging the external display (and switching back to integrated graphics) fixed the onboard colors. Re-plugging the external yielded the same result. After a reboot, the issue has not re-occurred (~24hrs). Some searching of Google indicates that this is not an isolated issue. Is there a known cause (and solution), to prevent further interruptions?
2. In a number of occurances, I have seen the Terminal application become exremely slow to respond, as in 10+ second keypress responses. The entire application appears affected, including opening new terminal tabs and the cursor switching from I-beam to pointer (as I move it from the terminal space to the tab bar). After some amount of time (several minutes?), terminal function returns to normal. The system.log file shows the following message repeated during the event.
Oct 16 09:38:34 raar.example.com Terminal[242]: Unable to simultaneously satisfy constraints:
        "<NSLayoutConstraint:0x7fc50b6bbf10 H:[NSColorWell:0x7fc50b045800(28)]>",
        "<NSLayoutConstraint:0x7fc50b6b4ea0 H:[NSColorWell:0x7fc50b045800]-(NSSpace(8))-[NSTextField:0x7fc50b0435d0]>",
        "<NSLayoutConstraint:0x7fc50b6b3e20 NSButton:0x7fc50b6af140'Change\U2026'.leading == NSColorWell:0x7fc50b045800.leading>",
        "<NSLayoutConstraint:0x7fc50b6b4f00 H:[NSTextField:0x7fc50b0435d0]-(>=NSSpace(20))-|   (Names: '|':NSView:0x7fc50b041780 )>",
        "<NSLayoutConstraint:0x7fc50b6b3d00 H:[NSTextField:0x7fc50b6c1120]-(NSSpace(8))-[NSButton:0x7fc50b6af140'Change\U20 26']>",
        "<NSLayoutConstraint:0x7fc50b6bc9c0 H:[NSTextField:0x7fc50b6c1120(>=209)]>",
        "<NSLayoutConstraint:0x7fc50b6b31b0 H:|-(17)-[NSTextField:0x7fc50b6c1120]   (Names: '|':NSView:0x7fc50b041780 )>",
        "<NSAutoresizingMaskLayoutConstraint:0x7fc50cdc6d90 h=--& v=--& H:[NSView:0x7fc50b041780(0)]>"
    Will attempt to recover by breaking constraint
    <NSLayoutConstraint:0x7fc50b6bc9c0 H:[NSTextField:0x7fc50b6c1120(>=209)]>
    Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens. And/or, break on objc_exception_throw to catch this in the debugger.

(1) is probably a colour profile bug. When you next see the issue, go to System Preferences > Displays > Colour, and confirm that the correct colour profile is selected for the affected monitor. If it is, then deselect it by choosing another one, then reselect it. If your display regains its expected colour you can assume it's a colour profile bug. In my experience colour profiles are prone to this kind of behaviour, though Apple has made things more stable in the last year or so.

To XMP or not to XMP

I was bitten by the Lightroom 5.0 History bug (images developed in earlier versions of Lr lost complete histories if the history state was changed in the Develop module) and was able to recover because I had good backups. I've updated to 5.2 since, so I don't expect to run into that again. One thing I noticed during my recovery operation is that Lr will warn me if there is a mismatch between metadata in the catalog and metadata in the image file. Overwriting the metadata in the image with the metadata in the recovered catalog fixed the some issues with the effects of the bug, but it got me thinking -- what if the metadata hadn't been written to the image file at all?
I'm more of a video guy than a photo guy, and I set up Lr to automatically write metadata to the files because that's what I do for my video files when I use Premiere Pro. But I think my recovery would have been easier and less stressful if I hadn't had to see or base a decision on the intimidating metadata mismatch warning that Lr presents.
So I'm asking for general opinions -- what do you think about the pros and cons of having Lr automatically write metadata to XMP?
Jeff

Samoreen wrote:
But you will regularly forget Ctrl-S anyway .
Actually, I never forget. Or perhaps I should say if ever I do forget, it will be caught.
There are two times I save metadata:
1. When I've done enough editing I'd be bummed if it got lost, but I'm not finished yet.
2. When I'm finished.
finished means "finished for now" - most photos are published after they're finished, and re-published after they're finished again...
In the former case (1), I just don't worry about it too much, in the latter case (2) it's done as part of a "finalization ritual" which (takes snapshots of and also) assigns metadata to finished photos... I use the ChangeManager plugin for that, but there is more than one way to accomplish a goal. For example, Jeffrey Friedl has Folder Status plugin for "managing change" on a folder basis instead of photo basis. You can also follow a self-designed procedure which does not require plugins.
The concept is: once saving xmp becomes part of a workflow that includes assigning (and/or clearing) metadata, it's the assigned (or cleared) metadata that drives the relationship (status) between catalog settings and xmp on disk.
I turn xmp status indicators off, and rarely look at the metadata status collection(s). Why?
1. They sometimes say metadata needs to be saved when it doesn't.
2. They sometimes say metadata wasn't saved when it was.
3. They may seem to indicate you should read metadata when you shouldn't.
4. Metadata conflict status depends on date/time only, not contents, and so many "conflicts" are simply false alarms.
etc.
i.o.w. it's never been a reliable (nor robust) feature in Lightroom, and I just don't need it, since I have other "metadata status" metadata that I have complete control of, which *is* reliable.
If I ever get confused, ChangeManager's "Compare Catalog to Disk" feature gives a complete list of all differences between develop settings and metadata in catalog and those in xmp on disk.
I don't necessarily recommend everybody do things how I do them, since my way (although robust) employs plugins - it's not "as simple as possible", and there is something to be said for simplicity.
My main point is that if you can figure a way to assure xmp is saved when appropriate, manual method may be best.
If you can't or just don't want to, then auto method may be best for you. And of course there are those that rely on the catalog exclusively and never save xmp - that's another way to go.
UPDATE:
=======
Perhaps the most important aspect to me of saving manually: I want to save (finalized) xmp only after scrutinization, since part of the goal is NOT to save screw-ups in xmp! - they're already in the catalog .
=======
Rob
Message was UPDATED by: Rob Cole

Colour history bug

Similar Messages

Maybe you are looking for