WebP Photoshop plug-in

2,243 views
Skip to first unread message

Brendan Bolles

unread,
Jun 18, 2013, 1:09:29 PM6/18/13
to webp-d...@webmproject.org
Hey everyone, I've got the first draft of a new WebP Photoshop plug-in for you to try. I guess I'll say this is the first beta. It should work in any version of Photoshop in recent memory (including the new version just released today!). Here are download links for Mac and Windows:



I'm releasing it as open source under the BSD license. It's hosted here on GitHub:


In that repository you'll also see that I'm working on a WebM plug-in for Premiere, but that still has a little ways to go.


More details coming in a follow-up post.

Apologies to Toby from Telegraphics who released his WebP plug-in 2.5 years ago. I wanted to experiment with the latest lossless and alpha channel features, so I built my own.



Brendan

Brendan Bolles

unread,
Jun 18, 2013, 1:21:35 PM6/18/13
to webp-d...@webmproject.org
Here's my initial, very primitive output options dialog that doesn't even label the quality slider properly yet:

As you can see, you can save lossless or turn that off and set your quality level. If you have transparency or a channel in the channels palette, you can save with an alpha. If you hold down shift when a WebP file is opening, you get a similar dialog for how to deal with the alpha.

As you know, there are many different compression options in WebP. I would love to have a dialog letting people fiddle with them all, but I'm also mindful of having an easy, non-confusing interface. Perhaps we can have a second dialog available for people who really want to dive in.

That said, what other options do people think should appear in the simple dialog?


Brendan


Дмитрий Вержиковский

unread,
Jun 18, 2013, 1:25:33 PM6/18/13
to webp-d...@webmproject.org
I use russian Photoshop CS6 64 and I have trouble.
See attach.

вторник, 18 июня 2013 г., 20:09:29 UTC+3 пользователь Brendan Bolles написал:
error-in-ru-photoshop.png

Brendan Bolles

unread,
Jun 18, 2013, 1:55:16 PM6/18/13
to webp-d...@webmproject.org
Hmm, I can't read Russian. Did you try to open a WebP file?

Is the plug-in installed properly? Copy the .8bi to your Photoshop plug-ins folder. Make sure you use the right 64/32-bit version of the plug-in for the Photoshop you're using on Windows.

You can make sure the plug-in is installed by looking for Help > About Plug-In > WebP.


Brendan

Brendan Bolles

unread,
Jun 18, 2013, 2:10:52 PM6/18/13
to webp-d...@webmproject.org
OK, one more rapid-fire post on the subject for the moment. Some additional thoughts I had:

1. I'm very grateful for the libwebp library, which made building this plug-in very easy. (I wish libvpx were as straight forward.) It'll be a piece of cake to add more encoding options once we decide what those should be. But I also wish libwebp could do a little more. For example, the sample code for saving ICC profiles, EXIF, and XMP is a little convoluted and there is no sample for how to read it back in. I'd hope you'd just be able to point libwebp to a memory buffer and it would take care of the rest.

2. I get all kinds of linking errors on Windows when building a static library (Visual Studio 2008). I'm not sure what's going on; the problems persisted even after I imported the libwebp files right into my project. Fortunately I was able to download the pre-built libraries and they worked fine, but does anyone know what the problem may be? My projects are in the GitHub repo if you want to take a look. Xcode had no problems.

3. I was kind of surprised to see that setting quality to 100 still made for a visually lossy WebP, while JPEG can make a visually lossless file. (Of course WebP lossless compression is visually lossless.) Is this a limitation of VP8 compression?

4. I'm very happy that the high quality lossless compression is in WebP. Any chance it will come to WebM?

5. I hear that WebM is getting support for 10-bit. How about WebP? Or how about 16-bit? I come from a video/film production background and those features would be appreciated in that field.


Brendan

Pascal Massimino

unread,
Jun 18, 2013, 2:59:56 PM6/18/13
to WebP Discussion
Brendan,

sorry i can't test the plug-in right away (i don't have a PS installed right now!). 
Just some remarks:

On Tue, Jun 18, 2013 at 8:10 PM, Brendan Bolles <fnor...@gmail.com> wrote:
OK, one more rapid-fire post on the subject for the moment. Some additional thoughts I had:

1. I'm very grateful for the libwebp library, which made building this plug-in very easy. (I wish libvpx were as straight forward.) It'll be a piece of cake to add more encoding options once we decide what those should be. But I also wish libwebp could do a little more. For example, the sample code for saving ICC profiles, EXIF, and XMP is a little convoluted and there is no sample for how to read it back in. I'd hope you'd just be able to point libwebp to a memory buffer and it would take care of the rest.

there's an example about how to read EXIF/XMP/ICC in the README.mux file (agreed, html doc is still lacking):


Do you think a generic WebPGetMetadata(...) would be useful?

 

2. I get all kinds of linking errors on Windows when building a static library (Visual Studio 2008). I'm not sure what's going on; the problems persisted even after I imported the libwebp files right into my project. Fortunately I was able to download the pre-built libraries and they worked fine, but does anyone know what the problem may be? My projects are in the GitHub repo if you want to take a look. Xcode had no problems.

do you have the error log? That could be helpful to identify the problem...
 

3. I was kind of surprised to see that setting quality to 100 still made for a visually lossy WebP, while JPEG can make a visually lossless file. (Of course WebP lossless compression is visually lossless.) Is this a limitation of VP8 compression?

Hmm... VP8 has an inherent limitation that the minimum quantizer step is '4', whereas JPEG can go as low as '1'. But it shouldn't be visible.
Maybe try to set -sns 0 and/or -segments 1, so you are guaranteed that have the minimal quantizer everywhere. Maybe what you're seeing
is banding artifacts that occurred during the RGB->YUV conversion (that is, outside of the codec per se).
 

4. I'm very happy that the high quality lossless compression is in WebP. Any chance it will come to WebM?

Well, i'm not sure it would fit equally for _moving_ pictures. 


5. I hear that WebM is getting support for 10-bit. How about WebP? Or how about 16-bit? I come from a video/film production background and those features would be appreciated in that field.


i've got some experiment going about this, but keep in mind that WebP is more designed to be the final image format (the one you send over the wire) rather
than an editing format (where you want to preserve as many bit-depth for samples as possible, for later editing).


Otherwise, regarding the parameters exposed in your UI: i think one slider for quality is ok. It should be that simple :)
And even, you could go as far as disabling it when the 'lossless' box is checked. After all, lossless is lossless...

(but yes, there's a lot of other parameters you could expose, but we're trying to make the defaut setting just 'work' as is)

hope it helps,
skal
 

Brendan

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.
 
 

oX Triangle

unread,
Jun 18, 2013, 3:51:54 PM6/18/13
to webp-d...@webmproject.org
you know that -q and -m has still a little effect on lossless

Brendan Bolles

unread,
Jun 18, 2013, 6:40:25 PM6/18/13
to webp-d...@webmproject.org
On Tuesday, June 18, 2013 11:59:56 AM UTC-7, skal wrote:
there's an example about how to read EXIF/XMP/ICC in the README.mux file (agreed, html doc is still lacking):



Ah ha, thanks for pointing that out! I was looking at the code for cwebp, which does not use the muxer. Yes, it's fairly straight forward and well-documented. I'm now reading and writing ICC, EXIF, and XMP (well, actually Photoshop doesn't seem to want to give me XMP). Here's a new beta:


The only downside to the muxer is that it holds everything in memory before you WebPMuxAssemble() and write the file, right? Might be a problem for really big files.

The new beta is only on Mac because using the muxer breaks linking on Windows for me, even using the pre-built libraries. I've pasted in the errors below.

Notice that I am able to link to the WebPDemux function that I am actually using, but it is the internal functions that don't link. This is similar to the errors I was getting for all functions when building the library myself. Since you aren't using the muxer in cwebp, maybe that's why you haven't seen this in your own Windows build.

1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxInternal referenced in function WebPDemux
1>WebP.obj : error LNK2019: unresolved external symbol WebPNewInternal referenced in function WebPMuxNew
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxDelete referenced in function "void __cdecl DoReadContinue(struct Globals *)" (?DoReadContinue@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxReleaseIterator referenced in function "void __cdecl DoReadContinue(struct Globals *)" (?DoReadContinue@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxGetFrame referenced in function "void __cdecl DoReadContinue(struct Globals *)" (?DoReadContinue@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxReleaseChunkIterator referenced in function "void __cdecl DoReadStart(struct Globals *)" (?DoReadStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxGetChunk referenced in function "void __cdecl DoReadStart(struct Globals *)" (?DoReadStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxGetI referenced in function "void __cdecl DoReadStart(struct Globals *)" (?DoReadStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPMuxDelete referenced in function "void __cdecl DoWriteStart(struct Globals *)" (?DoWriteStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPMuxAssemble referenced in function "void __cdecl DoWriteStart(struct Globals *)" (?DoWriteStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPMuxSetChunk referenced in function "void __cdecl DoWriteStart(struct Globals *)" (?DoWriteStart@@YAXPEAUGlobals@@@Z)
1>WebP.obj : error LNK2019: unresolved external symbol WebPMuxSetImage referenced in function "void __cdecl DoWriteStart(struct Globals *)" (?DoWriteStart@@YAXPEAUGlobals@@@Z)
1>build\x64\Release\WebP.8bi : fatal error LNK1120: 12 unresolved externals

Brendan Bolles

unread,
Jun 18, 2013, 7:00:35 PM6/18/13
to webp-d...@webmproject.org
On Tuesday, June 18, 2013 11:59:56 AM UTC-7, skal wrote:
Brendan,

sorry i can't test the plug-in right away (i don't have a PS installed right now!).

If you have a spare computer (or virtual machine) around, you can always install it as a trial for 30 days. But only once per (virtual) machine.


 4. I'm very happy that the high quality lossless compression is in WebP. Any chance it will come to WebM?

Well, i'm not sure it would fit equally for _moving_ pictures. 


Lossless does not fit for playing back in real time, but it would be a really big deal for the production phase where you want to store all your work losslessly before converting to some lossy codec for delivery.

There are plenty of still image formats that compress losslessly but hardly any movie formats. QuickTime has some lossless codecs, but then you're using closed-source QuickTime, which often does weird things to your image and you can't figure out why. But it's the only production movie format around right now, except for maybe DNxHD which is high-quality but not actually lossless.

Part of the success with QuickTime is that it can be used for both production and delivery. Now with H.264/MP4 and WebM, delivery is in the hands of open source formats. I would love for lossless WebM to replace QuickTime in production as well.

 


5. I hear that WebM is getting support for 10-bit. How about WebP? Or how about 16-bit? I come from a video/film production background and those features would be appreciated in that field.


i've got some experiment going about this, but keep in mind that WebP is more designed to be the final image format (the one you send over the wire) rather
than an editing format (where you want to preserve as many bit-depth for samples as possible, for later editing).


I hear you. Honestly, I'm not as worried about WebP because there are other still image formats that already do this (for example, PNG will do 16-bit). But there is no freely available movie format that can do a higher bit depth. And really, WebM is the only truly open source movie format I think.

 
Brendan

Brendan Bolles

unread,
Jun 18, 2013, 7:05:25 PM6/18/13
to webp-d...@webmproject.org
One more question:

I know that when you save lossless you always save an alpha channel. Is there any way when reading the file to know there was no alpha originally and ignore it?


Brendan

Urvang Joshi

unread,
Jun 18, 2013, 7:08:49 PM6/18/13
to webp-d...@webmproject.org
Hi Brendan,
There is a bit for 'hinting' that alpha is not used in the lossless format:

Let me again stress that this should be taken as a hint (that is, a wrong value in that bit is not considered an error).




Brendan

Brendan Bolles

unread,
Jun 18, 2013, 7:28:49 PM6/18/13
to webp-d...@webmproject.org
On Tuesday, June 18, 2013 4:08:49 PM UTC-7, Urvang Joshi wrote:
Hi Brendan,
There is a bit for 'hinting' that alpha is not used in the lossless format:

Let me again stress that this should be taken as a hint (that is, a wrong value in that bit is not considered an error).


Thanks for pointing that out. I see it here in picture.c:

picture->colorspace |= WEBP_CSP_ALPHA_BIT;


The alpha being completely opaque sounds like a good reason to treat it like a flattened document in Photoshop.

Is there a good way to access that bit with libwebp? Maybe before actually decoding the bitstream?


Brendan

Urvang Joshi

unread,
Jun 18, 2013, 7:54:44 PM6/18/13
to webp-d...@webmproject.org
Hi,


You can use WebPGetFeatures()  to check the presence of alpha or you can use WebPMuxGetFeatures() to get all the feature flags (alpha, icc, xmp, exif, animation).

James Zern

unread,
Jun 18, 2013, 8:00:40 PM6/18/13
to webp-d...@webmproject.org


On Tuesday, June 18, 2013 4:54:44 PM UTC-7, Urvang Joshi wrote:
Hi,


On Tue, Jun 18, 2013 at 4:28 PM, Brendan Bolles <fnor...@gmail.com> wrote:
On Tuesday, June 18, 2013 4:08:49 PM UTC-7, Urvang Joshi wrote:
Hi Brendan,
There is a bit for 'hinting' that alpha is not used in the lossless format:

Let me again stress that this should be taken as a hint (that is, a wrong value in that bit is not considered an error).


Thanks for pointing that out. I see it here in picture.c:

picture->colorspace |= WEBP_CSP_ALPHA_BIT;


The alpha being completely opaque sounds like a good reason to treat it like a flattened document in Photoshop.

Is there a good way to access that bit with libwebp? Maybe before actually decoding the bitstream?

You can use WebPGetFeatures()  to check the presence of alpha or you can use WebPMuxGetFeatures() to get all the feature flags (alpha, icc, xmp, exif, animation).

The demux interface offers this as well through WebPDemuxGetI(demux, WEBP_FF_FORMAT_FLAGS);

James Zern

unread,
Jun 18, 2013, 8:04:22 PM6/18/13
to webp-d...@webmproject.org


On Tuesday, June 18, 2013 3:40:25 PM UTC-7, Brendan Bolles wrote:
[...]


The new beta is only on Mac because using the muxer breaks linking on Windows for me, even using the pre-built libraries. I've pasted in the errors below.

Notice that I am able to link to the WebPDemux function that I am actually using, but it is the internal functions that don't link. This is similar to the errors I was getting for all functions when building the library myself. Since you aren't using the muxer in cwebp, maybe that's why you haven't seen this in your own Windows build.

1>WebP.obj : error LNK2019: unresolved external symbol WebPDemuxInternal referenced in function WebPDemux
1>WebP.obj : error LNK2019: unresolved external symbol WebPNewInternal referenced in function WebPMuxNew
[...]

The muxer and demuxer are not part of libwebp, but live in separate libraries.
If you're using the nmake file to build libwebp you can get these by specifying 'all' as the target or name the library specifically:

> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpdemux.lib CFG=release-static
> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpmux.lib CFG=release-static

Brendan Bolles

unread,
Jun 18, 2013, 9:43:40 PM6/18/13
to webp-d...@webmproject.org
On Tuesday, June 18, 2013 4:54:44 PM UTC-7, Urvang Joshi wrote:
You can use WebPGetFeatures()  to check the presence of alpha or you can use WebPMuxGetFeatures() to get all the feature flags (alpha, icc, xmp, exif, animation).


Yep, this works. Thanks!

I think the key is to use WebPGetFeatures() on the bitstream itself, and not the whole file which it can also parse. This WEBP_CSP_ALPHA_BIT bit is in the bitstream, while it appears the overall file has its own flags, which you get with WebPDemuxGetI(d, WEBP_FF_FORMAT_FLAGS), and the two don't agree on the alpha in this case.


Brendan

Brendan Bolles

unread,
Jun 19, 2013, 5:11:34 AM6/19/13
to webp-d...@webmproject.org
On Tuesday, June 18, 2013 5:04:22 PM UTC-7, James Zern wrote:
> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpdemux.lib CFG=release-static
> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpmux.lib CFG=release-static

Thanks, James, this does work for x86! Which makes me think I have to study the Makefile.vc and possibly reproduce the settings in my vcproj. Still don't understand why I'm getting this problem.

How would I build these libraries for x64? This only seems to build x86 libraries in an x64 directory:

nmake /f Makefile.vc ..\obj\release-static\x64\lib\libwebpdemux.lib CFG=release-static ARCH=x64
nmake /f Makefile.vc ..\obj\release-static\x64\lib\libwebpmux.lib CFG=release-static ARCH=x64

Sorry, I'm not very familiar with nmake. All the Adobe SDKs come with vcproj samples, so that's what I'm used to.

Brendan

Urvang Joshi

unread,
Jun 19, 2013, 6:49:20 AM6/19/13
to webp-d...@webmproject.org
Note that WebPGetFeatures(), WebPMuxGetFeatures() and WebPDemuxGetI(d, WEBP_FF_FORMAT_FLAGS) should all agree on whether the image has alpha (whether you pass just the bitstream or the full file). Have you seen a case where they don't?

Brendan Bolles

unread,
Jun 19, 2013, 11:15:23 AM6/19/13
to webp-d...@webmproject.org
On Wednesday, June 19, 2013 3:49:20 AM UTC-7, Urvang Joshi wrote:
Note that WebPGetFeatures(), WebPMuxGetFeatures() and WebPDemuxGetI(d, WEBP_FF_FORMAT_FLAGS) should all agree on whether the image has alpha (whether you pass just the bitstream or the full file). Have you seen a case where they don't?
 

Yes, they don't agree whenever I save a lossless image without alpha. I took this to be normal because I hear that lossless compression always gets alpha added. Also, couldn't you store multiple images in a file, some with alpha and some without? Then there would be no file-wide answer to the alpha question. My code looks like this:

WebPData webp_data = { (const uint8_t *)buf, file_size };

WebPDemuxer *demux = WebPDemux(&webp_data);

if(demux)
{
uint32_t width = WebPDemuxGetI(demux, WEBP_FF_CANVAS_WIDTH);
uint32_t height = WebPDemuxGetI(demux, WEBP_FF_CANVAS_HEIGHT);
uint32_t flags = WebPDemuxGetI(demux, WEBP_FF_FORMAT_FLAGS);
bool has_alpha = (flags & ALPHA_FLAG);
// check the bitstream to see if we REALLY have an alpha
// (lossless images are always compressed with an alpha)
WebPIterator iter;
if(has_alpha && WebPDemuxGetFrame(demux, 0, &iter) )
{
WebPBitstreamFeatures features;
VP8StatusCode status = WebPGetFeatures(iter.fragment.bytes, iter.fragment.size, &features);
has_alpha = features.has_alpha;
WebPDemuxReleaseIterator(&iter);
}
}


In this case has_alpha initially gets set to true, and then the second time gets set to false. Maybe I'm doing something wrong when I save the image? The only time I set if there's an alpha or not is when I decide to create the WebPPicture using WebPPictureImportRGBA() or WebPPictureImportRGB().

You can see my code on GitHub.


Brendan

Pascal Massimino

unread,
Jun 19, 2013, 11:28:13 AM6/19/13
to WebP Discussion
Brendan,

On Wed, Jun 19, 2013 at 8:15 AM, Brendan Bolles <fnor...@gmail.com> wrote:
On Wednesday, June 19, 2013 3:49:20 AM UTC-7, Urvang Joshi wrote:
Note that WebPGetFeatures(), WebPMuxGetFeatures() and WebPDemuxGetI(d, WEBP_FF_FORMAT_FLAGS) should all agree on whether the image has alpha (whether you pass just the bitstream or the full file). Have you seen a case where they don't?
 

Yes, they don't agree whenever I save a lossless image without alpha. I took this to be normal because I hear that lossless compression always gets alpha added.

yes, lossless always save the A/R/G/B quadruplets, no matter what. Of course, if the image is fully opaque, the A channel is trivial and gets easily compressed.

 
Also, couldn't you store multiple images in a file, some with alpha and some without?

yes, that possible in animations. Images don't have to be all in lossy or lossless format, either. It can be varied on a per-frame basis.

 
Then there would be no file-wide answer to the alpha question.

iirc, we just take the common lower denominator: if there's any frame that has alpha, then the file is considered
to have alpha globally.

 
My code looks like this:

WebPData webp_data = { (const uint8_t *)buf, file_size };

WebPDemuxer *demux = WebPDemux(&webp_data);

if(demux)
{
uint32_t width = WebPDemuxGetI(demux, WEBP_FF_CANVAS_WIDTH);
uint32_t height = WebPDemuxGetI(demux, WEBP_FF_CANVAS_HEIGHT);
uint32_t flags = WebPDemuxGetI(demux, WEBP_FF_FORMAT_FLAGS);
bool has_alpha = (flags & ALPHA_FLAG);
// check the bitstream to see if we REALLY have an alpha
// (lossless images are always compressed with an alpha)
WebPIterator iter;
if(has_alpha && WebPDemuxGetFrame(demux, 0, &iter) )
{
WebPBitstreamFeatures features;
VP8StatusCode status = WebPGetFeatures(iter.fragment.bytes, iter.fragment.size, &features);
has_alpha = features.has_alpha;
WebPDemuxReleaseIterator(&iter);
}
}


In this case has_alpha initially gets set to true, and then the second time gets set to false. Maybe I'm doing something wrong when I save the image? The only time I set if there's an alpha or not is when I decide to create the WebPPicture using WebPPictureImportRGBA() or WebPPictureImportRGB().

Well, actually if you import an image with WebPPictureImportRGBA() and use the lossy format, then libwebp will try to
detect if there's a trivial fully opaque alpha values. In such case, the output will be marked as 'no alpha'.

skal

Brendan Bolles

unread,
Jun 19, 2013, 11:42:19 AM6/19/13
to webp-d...@webmproject.org
On Wednesday, June 19, 2013 8:28:13 AM UTC-7, skal wrote:
Brendan,

On Wed, Jun 19, 2013 at 8:15 AM, Brendan Bolles <fnor...@gmail.com> wrote:
Then there would be no file-wide answer to the alpha question.

iirc, we just take the common lower denominator: if there's any frame that has alpha, then the file is considered
to have alpha globally.

OK, so in other words it's perfectly normal to be told there's alpha in the file but not in the actual image you're getting.

I guess you could argue that this shouldn't be the case when your file only has a single image, but that sounds like a change in libwebp. I think I'm doing everything right on my end. Check my code if you disagree!


Brendan

James Zern

unread,
Jun 19, 2013, 3:16:30 PM6/19/13
to webp-d...@webmproject.org


On Wednesday, June 19, 2013 2:11:34 AM UTC-7, Brendan Bolles wrote:
On Tuesday, June 18, 2013 5:04:22 PM UTC-7, James Zern wrote:
> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpdemux.lib CFG=release-static
> nmake /f Makefile.vc ..\obj\release-static\x86\lib\libwebpmux.lib CFG=release-static

Thanks, James, this does work for x86!
 
Great! 

Which makes me think I have to study the Makefile.vc and possibly reproduce the settings in my vcproj. Still don't understand why I'm getting this problem.

For this inspecting the cl command line on output might be a bit simpler.
 

How would I build these libraries for x64? This only seems to build x86 libraries in an x64 directory:

nmake /f Makefile.vc ..\obj\release-static\x64\lib\libwebpdemux.lib CFG=release-static ARCH=x64
nmake /f Makefile.vc ..\obj\release-static\x64\lib\libwebpmux.lib CFG=release-static ARCH=x64

ARCH is usually auto-detected depending on the flavor of cl.exe in your PATH. You can toggle between them using vcvarsall.bat (in the VC directory of your install): vcvarsall.bat amd64|x86. Another option is to open up a 'Visual Studio ... x64 Command Prompt', these shortcuts are generally installed with VS in your start menu.


Sorry, I'm not very familiar with nmake. All the Adobe SDKs come with vcproj samples, so that's what I'm used to.

I understand, it's not the easiest to deal with. Though it would require python adding a gyp file to this project might be nice, you'd then be able to get vcproj and xcode -- for the autoconf/make adverse -- project generation (relatively) simply.

Pascal Massimino

unread,
Jun 20, 2013, 3:11:38 AM6/20/13
to WebP Discussion
Brendan,

some additional thoughts regarding options to expose:


On Tue, Jun 18, 2013 at 11:59 AM, Pascal Massimino <pascal.m...@gmail.com> wrote:
Brendan,

sorry i can't test the plug-in right away (i don't have a PS installed right now!). 
Just some remarks:

On Tue, Jun 18, 2013 at 8:10 PM, Brendan Bolles <fnor...@gmail.com> wrote:
OK, one more rapid-fire post on the subject for the moment. Some additional thoughts I had:

1. I'm very grateful for the libwebp library, which made building this plug-in very easy. (I wish libvpx were as straight forward.) It'll be a piece of cake to add more encoding options once we decide what those should be. But I also wish libwebp could do a little more. For example, the sample code for saving ICC profiles, EXIF, and XMP is a little convoluted and there is no sample for how to read it back in. I'd hope you'd just be able to point libwebp to a memory buffer and it would take care of the rest.

there's an example about how to read EXIF/XMP/ICC in the README.mux file (agreed, html doc is still lacking):


Do you think a generic WebPGetMetadata(...) would be useful?

 

2. I get all kinds of linking errors on Windows when building a static library (Visual Studio 2008). I'm not sure what's going on; the problems persisted even after I imported the libwebp files right into my project. Fortunately I was able to download the pre-built libraries and they worked fine, but does anyone know what the problem may be? My projects are in the GitHub repo if you want to take a look. Xcode had no problems.

do you have the error log? That could be helpful to identify the problem...
 

3. I was kind of surprised to see that setting quality to 100 still made for a visually lossy WebP, while JPEG can make a visually lossless file. (Of course WebP lossless compression is visually lossless.) Is this a limitation of VP8 compression?

Hmm... VP8 has an inherent limitation that the minimum quantizer step is '4', whereas JPEG can go as low as '1'. But it shouldn't be visible.
Maybe try to set -sns 0 and/or -segments 1, so you are guaranteed that have the minimal quantizer everywhere. Maybe what you're seeing
is banding artifacts that occurred during the RGB->YUV conversion (that is, outside of the codec per se).
 

4. I'm very happy that the high quality lossless compression is in WebP. Any chance it will come to WebM?

Well, i'm not sure it would fit equally for _moving_ pictures. 


5. I hear that WebM is getting support for 10-bit. How about WebP? Or how about 16-bit? I come from a video/film production background and those features would be appreciated in that field.


i've got some experiment going about this, but keep in mind that WebP is more designed to be the final image format (the one you send over the wire) rather
than an editing format (where you want to preserve as many bit-depth for samples as possible, for later editing).


Otherwise, regarding the parameters exposed in your UI: i think one slider for quality is ok. It should be that simple :)
And even, you could go as far as disabling it when the 'lossless' box is checked. After all, lossless is lossless...

(but yes, there's a lot of other parameters you could expose, but we're trying to make the defaut setting just 'work' as is)

i may be useful to have an option (off by default) to remove the EXIF and XMP chunks. And also to possibly
'burn in' the color profile (that is: modify the color samples to incorporate the ICC, and discard the ICC chunk afterward).

The rationale is: if you're 'saving for the web' your final image (no further editing), you likely want it to be as small as possible.
And these XMP chunk can be quite verbose (and so are the EXIF, often).

Another sub-possibility: trim these EXIF/XMP chunks to only keep some essential info like author/title/GPS/etc., discarding
all the other side information. Not sure if Photoshop's sdk come with the right editing/skimming tools for doing that, though.
You probably don't want to embark on a hand-written EXIF/XMP editing code yourself :)

skal

Brendan Bolles

unread,
Jun 21, 2013, 4:48:00 PM6/21/13
to webp-d...@webmproject.org
On Thursday, June 20, 2013 12:11:38 AM UTC-7, skal wrote:
i may be useful to have an option (off by default) to remove the EXIF and XMP chunks. And also to possibly
'burn in' the color profile (that is: modify the color samples to incorporate the ICC, and discard the ICC chunk afterward).


My PNG plug-in has a similar option to say you want to "Save Metadata", so I could make one of those for WebP as well. The user also has the ability to remove those things from the document in Photoshop.

One thing PNG offers which is kind of nice is an sRGB chunk—just a simple flag to say that the file is in sRGB without actually embedding an sRGB profile inside.


Brendan

oX Triangle

unread,
Jun 22, 2013, 5:28:58 PM6/22/13
to webp-d...@webmproject.org
have u test it with new photoshop (creative cloud)?
its compatible?

Brendan Bolles

unread,
Jun 23, 2013, 5:19:26 PM6/23/13
to webp-d...@webmproject.org
On Saturday, June 22, 2013 2:28:58 PM UTC-7, oX Triangle wrote:
have u test it with new photoshop (creative cloud)?
its compatible?

Yep, it should work in versions of Photoshop from CS3 to the just-released Photoshop CC (13.0). Actually, it will probably work in even older versions, especially on Windows. Plus other hosts that support Photoshop plug-ins.


Brendan

Brendan Bolles

unread,
Jun 23, 2013, 5:24:43 PM6/23/13
to webp-d...@webmproject.org
OK, thanks for the feedback, everyone. I've got everything building everywhere. I've added a few features, so there's a new beta:



The dialog has also been updated:

I look forward to hearing your feedback. At the moment I don't plan on adding any more features.


Brendan


Dmitry Verzhikovsky

unread,
Jun 24, 2013, 2:16:11 AM6/24/13
to webp-d...@webmproject.org
Perfect work on Photoshop CC x64 (Eng).
Thanks!


2013/6/24 Brendan Bolles <fnor...@gmail.com>


Brendan


--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/groups/opt_out.
 
 



--

Regards, Verzjikovskiy Dmitriy!
ver....@gmail.com
icq: 293-202-615
skype: ver.dima


Pascal Massimino

unread,
Jun 24, 2013, 3:42:12 AM6/24/13
to WebP Discussion
Brendan,


nice!
Just: what is 'Alpha 1' doing? the naming of the option is a little obscure...

oX Triangle

unread,
Jun 24, 2013, 4:07:02 AM6/24/13
to webp-d...@webmproject.org
i think its the method-paramater or?

Brendan Bolles

unread,
Jun 24, 2013, 4:49:11 AM6/24/13
to webp-d...@webmproject.org
On Monday, June 24, 2013 12:42:12 AM UTC-7, skal wrote:
nice!
Just: what is 'Alpha 1' doing? the naming of the option is a little obscure...

That's the default name of the topmost non-RGB channel in the channels palette.

If the user renames it, the name will be reflected in the dialog.

If there a multiple additional channels, the user will have to move the one they want to the top spot. I am too lazy to create a menu with the names of all their channels.


Brendan


oX Triangle

unread,
Jun 25, 2013, 1:07:35 AM6/25/13
to webp-d...@webmproject.org
have test it.. works great! thanks

i have another question
its possible for you to write another plugin?
to import/export archives(includes images)
with use of 7z.dll and UnRAR.dll

i work with comicbooks (cbr/cbz/cb7) contain many images in a renamed archive
it would be nice to work with photoshop without
switching to matched tools for extract/recompress :D

toby

unread,
Jun 26, 2013, 10:01:38 PM6/26/13
to webp-d...@webmproject.org


On Tuesday, 18 June 2013 13:09:29 UTC-4, Brendan Bolles wrote:
Hey everyone, I've got the first draft of a new WebP Photoshop plug-in for you to try. ...

Apologies to Toby from Telegraphics who released his WebP plug-in 2.5 years ago. I wanted to experiment with the latest lossless and alpha channel features, so I built my own.


More options are always good.

I've recently enhanced my plugin with ICC profile and Lossless support: http://telegraphics.com.au/sw/product/webpformat
It's available for Mac (CS2/PowerPC through to Intel CS3-CS6; not tested on CS7) and Windows (32 & 64 bit).

Lossy alpha is being worked on, but like you, I have some questions :)

--Toby

 


Brendan

Brendan Bolles

unread,
Jul 18, 2013, 11:42:46 PM7/18/13
to webp-d...@webmproject.org
Hey oX, I hard-coded compression method 6 per your request. No UI to set the method (for now), I just always use 6. I put links to a new beta in the README on GitHub.

I don't think I'm going to let the user specify file size instead of quality because I don't want to further clutter the UI. Also, I'm lazy.

You could always fork my GitHub repo and add it yourself....


Brendan

oX Triangle

unread,
Dec 17, 2013, 10:50:19 AM12/17/13
to webp-d...@webmproject.org

Brendan Bolles

unread,
Dec 17, 2013, 4:09:30 PM12/17/13
to webp-d...@webmproject.org
On Tuesday, December 17, 2013 7:50:19 AM UTC-8, oX Triangle wrote:


Good eye! All that's changed is I'm using the latest libwebp. 

oX Triangle

unread,
Dec 18, 2013, 2:58:49 AM12/18/13
to webp-d...@webmproject.org
Good eye! All that's changed is I'm using the latest libwebp. 

tnx.. im try to crawling the web daily to search for news
for my facebook-group "webp alliance" to help this project ;-)
Reply all
Reply to author
Forward
0 new messages