1.3.5.11 Problem

[MikeFromMesa]

I realize that there is now an updated APB version that is RC2 and this problem involves RC1, but I wanted to get this posted as quickly as possible. I will then test with the RC2 version, but nothing in the RC2 release notes indicates that this has been addressed.

 

This explanation is a bit involved and may not, at first, seem like it applies to APB, but please be patient and read through the entire post.

 

I have been processing with CaptureOne as my workflow tool and using APB as my external editor. For most images this process works well and without any issues, but today I decided to use some Topaz plugins directly from C1 through the Topaz photoFXlab app to work on an image. The editing was just a test to see if the linkage worked and I sent an tif from C1 to the Topaz software, edited it and saved it back to C1. That part of the process worked but, as usual, the returned tif from Topaz was unreadable by C1, probably due to the alpha channel that Topaz appends and C1 can not read. My normal process for fixing this is to send the returned tif to AP or APB, flatten it and save it back. This has always fixed the problem in C1.

 

I sent the tif to APB RC1, flattened it and saved it back. The image was still unreadable by C1. That was very surprising as this process has never failed before, so I tried it again assuming that I did something wrong, perhaps forgetting to flatten the image. Again the process did not work. I then sent it to AP, repeated the flattening and saving process and the image displayed properly in C1 as it always had before. I then repeated the entire process, again routing a new tif image from C1 to Topaz, back to C1, up to APB, flatten and back to C1. Again, the image could not be read by C1. Again, sent the image to AP, flattened and back to C1 and again the image was fine, although this time I saved the intermediate images.

 

So something has changed in the way the tif was flattened and saved by RC1 that failed to create an image that was readable by C1. The same process, using AP, did not fail. The two images are of different size and I thought I should post this problem. RC1 is not doing the same thing to the tif that AP (and the old versions of APB) did and the result is that the saved image is no longer viewable in CaptureOne.

 

I have sent the two tifs to dropbox in case anyone wants them. The APB saved version is here. The AP saved version is here. 

 

 

[Andy Somerfield]

Hi Mike,

 

I know exactly what has caused this - we recently upgraded our TIFF exporter to export alpha channels..

 

I'll make a change for RC3 whereby it will not export an alpha channel if there are no transparent pixels in the document. Apologies for this inconvenience.

 

Thanks,

 

Andy.

[MikeFromMesa]

Hi Mike,

 

I know exactly what has caused this - we recently upgraded our TIFF exporter to export alpha channels..

 

I'll make a change for RC3 whereby it will not export an alpha channel if there are no transparent pixels in the document. Apologies for this inconvenience.

 

Thanks,

 

Andy.

Andy,

 

If it makes any difference APB loaded a tif and I saved it, I did not export it. Also, do you want me to test this with RC2?

 

ADDENDUM:

 

1) Tested with RC2. Same issue.

 

2) To be clear. The transfer from CaptureOne to APB was done using what C1 calls Open With. That does not convert the current image but just sends it to the specified editor with no changes.

[Andy Somerfield]

Yes - the "Save" and "Export" code are both using the new transparency code path - and both will get fixed :)

 

Thanks,

 

Andy.

[MikeFromMesa]

Andy,

 

This problem still exists in 1.3.5.12. I don't know if you expected the problem to be fixed in the latest release candidate, but it is not.

[Andy Somerfield]

Yes, sorry Mike - RC2 had released (just) by the time I posted - this fix will be in the RC3 (Monday) build :)

 

Thanks,

 

A

[MikeFromMesa]

Andy,

 

As sorry as I am to say this, version 1.3.5.13 did not fix this problem. I just tested it and the same problem exists as before. The tiff file saved by APB is not readable by CaptureOne although loading and saving it in AP does produce a version C1 can read.

 

I can send you a copy of the tiff if you feel it would be helpful.

 

[Andy Somerfield]

Yes please Mike - that would be very useful at this point. Please send to asomerfield@seriflabs.com..

 

Edit: Sorry - "loading and saving it in AP does produce a version C1 can read." - this new build will not fix TIFF files saved by previous versions without loading and saving first!

 

Cheers,

 

A

[MikeFromMesa]

Andy,

 

Done.

[Andy Somerfield]

Hi Mike,

 

Thanks for the image - it seems like it already has alpha! Doing Cmd-I in Finder shows "Alpha Channel: Yes" - then loading this image into APB and doing Select -> Alpha Range -> Select Partially transparent shows two vertical columns of not-quite-fully-opaque pixels (you may need to zoom in a little to see them).

 

This is why APB is writing an alpha channel when saving the file (before, it never wrote one - which was a bug).

 

I was able to fix the issue using Edit -> Matte on the image..

 

What made this image? 

 

Hope this helps,

 

Andy.

[MikeFromMesa]

Hi Mike,

What made this image? 

 

Hope this helps,

 

Andy.

The image was made by Topaz software called from CaptureOne through Topaz's photoFXlab. Specifically Adjust was used and the adaptive exposure and adaptive color settings were modified before the image was returned to CaptureOne.

 

There are some interesting variations to this CaptureOne -> Topaz -> CaptureOne -> APB -> scenario. If I use Topaz's Fusion Express 2 instead of photoFXlab this problem does not seem to occur. That requires that I make the complete round trip between CaptureOne and the plugin for each call rather than being able to apply each plugin's adjustments in a single call, but the result is visible in CaptureOne. Perhaps the culprit is photoFXlab. I will do some additional testing.

 

One more thing - if I call Photoshop Elements instead of APB when re-saving the modified image I do not have this problem. That is, Elements must remove the alpha channel(s). I will try what you suggested - using Edit -> Matte. Given my choice I do not particularly want Elements on my system as it takes up an enormous amount of space and does not do 10% of what AP does.

[MikeFromMesa]

Andy,

 

An observation and a question.

 

I have verified that Fusion Express does not cause this problem, even if the same changes are made to the image in the Topaz plugin, so the problem must originate in photoFXlab. Given that Topaz does not seem very interested in updating that I assume I will have to live with it or change to Fusion Express 2. In any case Edit -> Matte does indeed take care of the issue so I am good.

 

As an aside the problem does not appear if I use a jpg instead of a tif when I send the image to photoFXlab. I guess that makes sense as jpgs do not support layers.

 

My question (and I think this may be important) - If I go through this process and get an unreadable file in CaptureOne and then call Elements to fix the problem CaptureOne updates the thumbnail as soon as the image is saved back to CaptureOne but when I do the same with APB, fixing the problem with the Edit -> Matte command, the thumbnail does not get updated when the image is saved back, nor when the file is closed in APB, but only when APB exits. That makes me ask if APB has a lock of some kind on the image and is not releasing it until it exits. If so, should APB not release the lock when the file is closed? Or am I on the wrong track here?

 

Thanks for the speed that you addressed this issue. I can now remove Elements from my system.

[Andy Somerfield]

Thanks for the clarification Mike,

 

I think I've seen the thumbnail issue here - although at the time I didn't join the dots and realise it got fixed when the app quit - I agree, it sounds like we're keeping some sort of handle open somewhere. I'll take a look into that..

 

Andy.