ImageAlpha messing up colors (build 565)


#1

I’m having issues with the ImageAlpha node. It does not do the same thing as the ImageAlpha app, which I use all the time. Here’s my workflow and here’s my image.

If you use the bottom-left Read Files node (attached to the note that says “Entry point for trimming and PNG-conversion of logos”), the ImageAlpha step makes the logo opaque when it shouldn’t, and badly lowers the saturation of the colors.

If you reconnect the nodes to skip ImageAlpha, the resultant PNG looks fine, and if you drop it into the ImageAlpha app it behaves as expected.

What’s going on?

  • Retrobatch 1.1b2 (565)
  • ImageAlpha 1.5.1
  • macOS 10.13.6

#2

(Oh, I also forgot to mention, in the process of making that post I found that this Discourse installation hasn’t been set to allow uploads of .retrobatch files yet.)


#3

I think you’re getting “Instant Alpha” confused with “Image Alpha”. You’ve got the Instant Alpha node setup right after the Change Color Profile node. Did you mean to do that?


#4

Yes. That bottom path is meant to knock out the corner color, trim to the new edges, reduce palette with ImageAlpha, then write and open in ImageOptim. It does join into the main path’s ImageAlpha node, doesn’t it? That’s where the problem is happening. If none of this makes sense then maybe I uploaded the wrong version of the file… will check later at a computer


#5

No, it seems like I uploaded the right thing. The selected node in this screenshot is the one causing the problem, using the image provided in the node path beginning with “Workflow Notes” there at the bottom left.


#6

OK, I see the desaturation now. Yes- that is weird. I’ll dig into it and figure out what’s going on.

FWIW, Retrobatch calls the pngquant program inside of ImageAlpha, and doesn’t directly open the app. I wonder what it’s doing differently…


#7

My first, completely-uninformed thought was that maybe the Instant Alpha [sic] node isn’t exactly doing an internal conversion from JPEG to a normal PNG the same way it would if you wrote a real PNG file and sent it through pngquant. Let me know if my guess is right! :slightly_smiling_face:


#8

When ImageAlpha does its thing, the internal representation of the image isn’t PNG or JPEG- it’s just a giant bucket of uncompressed pixels at that point. So I don’t think that’s what is doing it.


#9

Alright- I found the bug. It’s fixed now in the latest. RB was basically throwing out the CMYK conversion that was done earlier before handing the pixels off to pngquant. You can grab the new build from here: http://flyingmeat.com/download/latest/#retrobatch


#10

Ahhh, it works great. Thanks so much!