Extract Clipping Path from TIFF Image about twelvemonkeys

[haraldk]

Sounds reasonable to me.

Linking the StackOverflow question for reference.

Just extracting the clipping path shouldn't be too hard. It can probably be made available through the image metadata in a standardized way.

But I agree it would be more useful if we could create an alpha channel to apply to the image, either by default, or using an ImageReadParam.

I'm not fully aware how these clipping paths are used, is this a Adobe/PhotoShop extension thing? Does "normal" TIFF viewers like OS X Preview or Windows equivalent display these images with or without clipping path applied? How does Adobe treat this clipping path?

Regards,

Harald K

[jasonwpalmer]

From what I have read it is an Adobe/Photoshop extension. The Clipping Path is embedded under TiffTag 34377 within an IRB. In my experience - Photoshop is the only renderer that recognizes it. Finder and Windows Explorer ignore it, but Photoshop will recognize it right away and display it as a Path in the Paths tab. So the same image will open up in Finder/Explorer with an opaque background color, while Photoshop will open it with a transparent background.

[haraldk]

Ok,

So what I've found is that tag 34377 is a collection of Photoshop Image Resouce Blocks. I already have code to parse these, so that should be no problem.

The clipping path is stored in resource id 2999 for Photshop, but as the path itself is an SVG, it is perhaps stored in a different resource?

If only Photoshop recognizes it, it might be better to leave it to client code to actually apply the mask. But we could make it easily available or perhaps optionally applied using a parameter.

Do you have a couple of sample files?

Harald K

[jasonwpalmer]

I tried to send you 3 TIFFs but it apparently failed so I'll send them one
at a time.

I am also curious if the code you have that reads the IRBs is something
that I could use and if you'd be willing to share it? If not, that's fine -
I still appreciate your help.

And again - let me know if there is anything else I can help with. I'd be
happy to contribute if I could.

On Thu, Sep 4, 2014 at 9:11 PM, Jason Palmer [email protected] wrote:

Here are a few more TIFFs with embedded clipping paths.

I am also curious if the code you have that reads the IRBs is something
that I could use and if you'd be willing to share it? If not, that's fine -
I still appreciate your help.

And again - let me know if there is anything else I can help with. I'd be
happy to contribute if I could.

On Thu, Sep 4, 2014 at 2:52 PM, Jason Palmer [email protected]
wrote:

Here's one. I'll send you more this evening.

Let me know what else I can help with.

Jason

On Thu, Sep 4, 2014 at 2:32 PM, Harald Kuhr [email protected]
wrote:

Ok,

So what I've found is that tag 34377 is a collection of Photoshop Image
Resouce Blocks
http://www.awaresystems.be/imaging/tiff/tifftags/photoshop.html. I
already have code to parse these, so that should be no problem.

The clipping path is stored in resource id 2999
http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577409_38034.

If only Photoshop recognizes it, it might be better to leave it to
client code to actually apply the mask. But we could make it easily
available or perhaps optionally applied using a parameter.

Do you have a couple of sample files?

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer

[jasonwpalmer]

Also - looking at the link you added for the IRBs - the entry right before 2999 is 2000-2997 Path Information. It looks like this is where you would find the SVG.

http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/#50577409_38034

[haraldk]

Thanks for the samples! I think that's fine for now.

Re. IRBs for clipping path, I think it must be another IRB for the paths in SVG format, as the mentioned IRBs in the Photoshop spec are all supposed to be in Photoshops own path format. Then again, I might be wrong.. ;-)

I'll have a look at your sample files ans see what I find!

Harald K

[haraldk]

Hmm..

Seems like your attachments were lost on in translation between email and GitHub message...

Can you try to upload them directly using GitHub?

Harald K

[haraldk]

..and finally to your question about parsing Photoshop IRBs. :-)

For some stupid reason (to avoid too many inter-module dependencies combined with laziness at the time) I have two independent versions of PSD resource block parsing.

• One very simple and generic implementation in the imageio-metadata module, mostly aimed at reading IPTC data for JPEGs. Start by looking at the PSDReader class.
• And a more PSD-specific implementation in the imageio-psdmodule. Start by looking at the PSDImageResource class.

I hope to merge these in the future, but for now, this is what I've got. :-)

Harald K

[haraldk]

Hi,

Seems the Paths are in Adobe's format, as described in the docs linked above.

The good thing is that it is probably simpler to parse than SVG and doesn't require external dependencies. The downside is, well, we'll have to write it from scratch.

Not too hard, but I didn't fully understand the 32 bit fixed point numbers used (yet).

Have a nice weekend,

Harald K

[jasonwpalmer]

Well - the truth is, I love to write code. And I'd be happy to be a
contributor for 12 Monkeys. So I'll try to learn all that I can and I guess
we'll go from there.

Enjoy your weekend as well.

On Fri, Sep 5, 2014 at 1:05 PM, Harald Kuhr [email protected]
wrote:

Hi,

Seems the Paths are in Adobe's format, as described in the docs linked
above.

The good thing is that it is probably simpler to parse than SVG and
doesn't require external dependencies. The downside is, well, we'll have to
write it from scratch.

Not too hard, but I didn't fully understand the 32 bit fixed point numbers
used (yet).

Have a nice weekend,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[jasonwpalmer]

This might be of interest.

http://www.tonton-pixel.com/Photoshop%20Additional%20File%20Formats/custom-shapes-file-format.pdf

Regards

On Fri, Sep 5, 2014 at 1:22 PM, Jason Palmer [email protected] wrote:

Well - the truth is, I love to write code. And I'd be happy to be a
contributor for 12 Monkeys. So I'll try to learn all that I can and I guess
we'll go from there.

Enjoy your weekend as well.

On Fri, Sep 5, 2014 at 1:05 PM, Harald Kuhr [email protected]
wrote:

Hi,

Seems the Paths are in Adobe's format, as described in the docs linked
above.

The good thing is that it is probably simpler to parse than SVG and
doesn't require external dependencies. The downside is, well, we'll have to
write it from scratch.

Not too hard, but I didn't fully understand the 32 bit fixed point
numbers used (yet).

Have a nice weekend,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer

[haraldk]

Sounds great!

I love to write code myself, but always running low on time. So any contribution will be very welcome!

Clone the project and start hacking away! :-)

Harald K

[jasonwpalmer]

Did that yesterday.

And after 4 hours (of hacking) I have at least been able to get to the Path
data, actually parsing it is another matter. I also have limited time, but
I'm interested in this and looking forward to the end result. To be honest,
I have limited experience - so it can be a little intimidating looking at
your code base, but I'm confident if I can make progress - we can work out
the details and get the code up to snuff :-)

On Mon, Sep 8, 2014 at 5:45 AM, Harald Kuhr [email protected]
wrote:

Sounds great!

I love to write code myself, but always running low on time. So any
contribution will be very welcome!

Clone the project and start hacking away! :-)

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[jasonwpalmer]

​I was curious if you found any bugs with the code that I sent over. We
have been using it in production for a couple weeks now and it works well.
However, I have noticed that 1 out of about 50,000 images - it fails to
work. And when I try to do it with Image Magick on the bad image, I get the
same result in that the Path produced is wrong - or better yet the Path
produced seems to "clip" the entire image.

So I am curious if you found any bugs or maybe this is a Photoshop bug. I
know Image Magick isn't using Java, but it gives the same result.

Thoughts?​

Jason Palmer
Senior Software Engineer

[haraldk]

Hi Jason,

I've been quite busy (in the little time I have) with other stuff, so sorry, haven't been able to properly look at the code you sent.

It's on my todo-list though. :-)

Please send a few of the images that produces a bad path, though. That will help investigating why this happens.

Harald K

[jasonwpalmer]

Harald,

I've only encountered 2 of these images and I cannot find the first one,
however, I have attached the one I do have. If I remember correctly, github
doesn't like tif images - so I'm also sending it directly to you.

On Thu, Oct 9, 2014 at 5:43 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

I've been quite busy (in the little time I have) with other stuff, so
sorry, haven't been able to properly look at the code you sent.

It's on my todo-list though. :-)

Please send a few of the images that produces a bad path, though. That
will help investigating why this happens.

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[jasonwpalmer]

Harald,

I found out this particular image was edited overseas in India. I cannot
even verify that the Clipping Path was created in Photoshop and
furthermore, we had an in-house editor start from scratch and create a
Clipping Path with Photoshop and it is now displaying/clipping correctly. I
say all that to say, It might not be worth your time investigating this too
thoroughly.

Regards.

On Thu, Oct 9, 2014 at 6:08 AM, Jason Palmer [email protected] wrote:

Harald,

I've only encountered 2 of these images and I cannot find the first one,
however, I have attached the one I do have. If I remember correctly, github
doesn't like tif images - so I'm also sending it directly to you.

On Thu, Oct 9, 2014 at 5:43 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

I've been quite busy (in the little time I have) with other stuff, so
sorry, haven't been able to properly look at the code you sent.

It's on my todo-list though. :-)

Please send a few of the images that produces a bad path, though. That
will help investigating why this happens.

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer

[haraldk]

Ok,

Thanks! I hope to be able to spend more time on this next week.

Harald K

On 13. okt. 2014, at 14:13, jasonwpalmer [email protected] wrote:

Harald,

I found out this particular image was edited overseas in India. I cannot
even verify that the Clipping Path was created in Photoshop and
furthermore, we had an in-house editor start from scratch and create a
Clipping Path with Photoshop and it is now displaying/clipping correctly. I
say all that to say, It might not be worth your time investigating this too
thoroughly.

Regards.

On Thu, Oct 9, 2014 at 6:08 AM, Jason Palmer [email protected] wrote:

Harald,

I've only encountered 2 of these images and I cannot find the first one,
however, I have attached the one I do have. If I remember correctly, github
doesn't like tif images - so I'm also sending it directly to you.

On Thu, Oct 9, 2014 at 5:43 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

I've been quite busy (in the little time I have) with other stuff, so
sorry, haven't been able to properly look at the code you sent.

It's on my todo-list though. :-)

Please send a few of the images that produces a bad path, though. That
will help investigating why this happens.

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer
—
Reply to this email directly or view it on GitHub.

[haraldk]

Hi Jason,

Sorry for not following up on this as quickly as I was hoping to. Just to let you know I still have this on my todo-list.

Have been scratching my head for the best way to implement this, but I think keeping everything path-related (for TIFF, JPEG and PNG) in a separate module for now would cause the least problems for the future.

Best regards,

Harald K

[jasonwpalmer]

Sounds reasonable to me. It does overlap the existing modules and I can see
how it could cause problems if it isn't on it's own. And I can tell you
that we have been using it to display Search Results and it works great.

And I can definitely relate to time concerns - I have very little extra
time myself. I was only able to concentrate on this because we needed it.

On Mon, Oct 27, 2014 at 2:30 PM, Harald Kuhr [email protected]
wrote:

Hi Jason,

Sorry for not following up on this as quickly as I was hoping to. Just to
let you know I still have this on my todo-list.

Have been scratching my head for the best way to implement this, but I
think keeping everything path-related (for TIFF, JPEG and PNG) in a
separate module for now would cause the least problems for the future.

Best regards,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[haraldk]

Hi Jason,

Finally had some time to look at your code. And I think it looks very good. Great work, figuring out how to arrange the points correctly!

I've been re-arranging the code slightly and added antialiasing of the path, and now the results looks perfect! :-)
The code will be available as part of the project soon, in a module called imageio-clippath I think. Probably in a 3.1 or 3.2 release.

However, I'm also trying to generalize the code so that it works with paths embedded in JPEG, PNG and PSD as well as TIFF. The JPEG sample you sent, works fine. But I can't seem to find a path in the PNG file? Can you either verify that the sample you sent has a Photoshop path in it, or send me a new one? I'd also like to have a PSD sample, if you could get me one. Thanks. :-)

PS: I'm assuming that the images you have sent me so far can be distributed as part of the project, as test cases. If not, we'll have to come up with something else...

Again, many thanks for your contributions!

Best regards,

Harald K

[jasonwpalmer]

Harald,

Apparently I was wrong - you cannot embed a clipping path in a PNG.
Photoshop always rights it as an alpha channel instead. And I talked to the
boss and you are free to use any of our images as test cases and free to
distribute them as samples with the code. We would like if you could
mention that they are from itemMaster LLC, but we wouldn't require it.

I will forward you some images with clipping paths embedded.

Thanks.

On Tue, Nov 25, 2014 at 9:13 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

Finally had some time to look at your code. And I think it looks very
good. Great work, figuring out how to arrange the points correctly!

I've been re-arranging the code slightly and added antialiasing of the
path, and now the results looks perfect! :-)
The code will be available as part of the project soon, in a module called
imageio-clippath I think. Probably in a 3.1 or 3.2 release.

However, I'm also trying to generalize the code so that it works with
paths embedded in JPEG, PNG and PSD as well as TIFF. The JPEG sample you
sent, works fine. But I can't seem to find a path in the PNG file? Can you
either verify that the sample you sent has a Photoshop path in it, or send
me a new one? I'd also like to have a PSD sample, if you could get me one.
Thanks. :-)

PS: I'm assuming that the images you have sent me so far can be
distributed as part of the project, as test cases. If not, we'll have to
come up with something else...

Again, many thanks for your contributions!

Best regards,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[jasonwpalmer]

Harald,

Just so you know a little more about itemMaster. We are the one Free Source
for Product Images and Data. We provide an API that developers are free to
use to access all of our images and data for free. We never charge
developers a nickel to download and use our data or images. And we would be
happy to get our name out there for developers to use our API in their
applications for free. Unlike others in our industry we simply charge the
Manufacturers a small fee to photograph their products and scrape the data.
Feel free to signup for access if you like.

Of course it's also no problem for me to send you some images. You know we
also provide our images in TGA-16 format to use them with Space Planning
Software. Unbelievably, the TGA-16 files are sought after because they are
5-5-5 with an overlay bit which Space Planning software displays as an
alpha channel (even though this was not supported by the TGA specification
for 16 bit TGAs), which means the thumbnail images are half the size of the
same PNG. Admittedly, I didn't build an API around it, but I also have
source code that writes out the TGA-16 image files if you are interested.
We'd be happy to share with 12 monkeys. And even though we think of TGA-16
as completely outdated, we get just about as many requests for TGA-16 as we
do for PNGs - amazingly. So it might very well be something you would add
to 12 monkeys API.

Anyway, I wanted to also thank you for sending me the skeleton code in the
beginning as that gave me a killer starting point to figure out how to
read/write the points. (I also wrote code using imageio-metadata that
re-sizes and writes the clipping path - which I'd be happy to share as
well. As long as you can forgive my simple approach :) I have only 2 years
of experience with Java, but I love to learn all I can.(:)) Really, you and
I both know it's in itemMaster's own best interest to have you add any of
this functionality to your API :)

Thanks Again for your time. I hope you don't mind if I shoot you a question
every now and again. I won't be a pest and I hope the baby is healthy and
happy.

On Tue, Nov 25, 2014 at 11:44 AM, Jason Palmer [email protected]
wrote:

Harald,

Apparently I was wrong - you cannot embed a clipping path in a PNG.
Photoshop always rights it as an alpha channel instead. And I talked to the
boss and you are free to use any of our images as test cases and free to
distribute them as samples with the code. We would like if you could
mention that they are from itemMaster LLC, but we wouldn't require it.

I will forward you some images with clipping paths embedded.

Thanks.

On Tue, Nov 25, 2014 at 9:13 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

Finally had some time to look at your code. And I think it looks very
good. Great work, figuring out how to arrange the points correctly!

I've been re-arranging the code slightly and added antialiasing of the
path, and now the results looks perfect! :-)
The code will be available as part of the project soon, in a module
called imageio-clippath I think. Probably in a 3.1 or 3.2 release.

However, I'm also trying to generalize the code so that it works with
paths embedded in JPEG, PNG and PSD as well as TIFF. The JPEG sample you
sent, works fine. But I can't seem to find a path in the PNG file? Can you
either verify that the sample you sent has a Photoshop path in it, or send
me a new one? I'd also like to have a PSD sample, if you could get me one.
Thanks. :-)

PS: I'm assuming that the images you have sent me so far can be
distributed as part of the project, as test cases. If not, we'll have to
come up with something else...

Again, many thanks for your contributions!

Best regards,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

Jason Palmer
Senior Software Engineer

[haraldk]

Hi Jason,

First of all: Thank you for providing sample files and letting me distribute them! Such contributions are very much appreciated!

I'll credit all the code with you as author (JavaDoc @author tag), and added a text file in the resources folder with the text "Sample images kindly provided by itemMaster LLC (https://www.itemmaster.com/).". Hope that is okay.

Re: TGA, I recently added read support for TGA images. It should work fine with normal 16 bit TGAs, but I suspect they don't support the transparency (bit mask) you have added. But I could add that, if you have some sample files, and perhaps some documentation on how to distinguish your 16 bit images from normal 16 bit TGAs (which I think is 5+5+5 and the last bit is just discarded). Please open a new issue for a new feature request.

If you also have write support, I'm very interested in adding that. Although it's probably not everyone first choice for a file format.. ;-)

Happy to be of help, and don't hesitate asking again.

Best regards,

Harald K

[jasonwpalmer]

Awesome Thanks. Now I'm famous :)

On Wed, Nov 26, 2014 at 9:20 AM, Harald Kuhr [email protected]
wrote:

Hi Jason,

First of all: Thank you for providing sample files and letting me
distribute them! Such contributions are very much appreciated!

I'll credit all the code with you as author (JavaDoc @author tag), and
added a text file in the resources folder with the text "Sample images
kindly provided by itemMaster LLC (https://www.itemmaster.com/).". Hope
that is okay.

Re: TGA, I recently added read support for TGA images. It should work fine
with normal 16 bit TGAs, but I suspect they don't support the transparency
(bit mask) you have added. But I could add that, if you have some sample
files, and perhaps some documentation on how to distinguish your 16 bit
images from normal 16 bit TGAs (which I think is 5+5+5 and the last bit is
just discarded). Please open a new issue for a new feature request.

If you also have write support, I'm very interested in adding that.
Although it's probably not everyone first choice for a file format.. ;-)

Happy to be of help, and don't hesitate asking again.

Best regards,

Harald K

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

Jason Palmer
Senior Software Engineer

[haraldk]

Fame, Fun & Fortune, here we come! ;-)

Harald K

[haraldk]

...and finally: 77e6600

Have a look, give it a try and see what you think. :-)

You should be able to do most path related operations using the static-methods-only Paths class.

I will probably release this as part of 3.1, some time during christmas..

Harald K

[haraldk]

Closing for now, reopen or file a new issue if you have strong feelings about the API that needs to be addressed. :-)

Harald K

[jasonwpalmer]

Awesome. Thanks Harald, it looks great. This will be easy to integrate and
it looks very straightforward and simple to use. I hope I can contribute
again in the near future.

On Tue, Dec 16, 2014 at 4:51 AM, Harald Kuhr [email protected]
wrote:

Closed #60 #60.

—
Reply to this email directly or view it on GitHub
#60 (comment).

Jason Palmer
Senior Software Engineer