RE: Another website update
Ben Galbraith wrote: I changed FOP to check a different region of the file for the text Adobe Photoshop, which does indeed confirm that Photoshop generated the file. Can you facilitate that patch being applied, if such falls within your responsibilities? Yes, I'll be glad to do that. Right now, we have a code freeze pending the upcoming 0.20.5 release, but I will work on getting it applied after the release. If you can, would you also add two attachments to the bug, one being a Photoshop-generated image, and the other being generated by another application, that will illustrate the problem and the solution? Smaller is better as long as the effect is clear. Please identify the generating application in both cases. Thanks, and thanks again for your efforts here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another website update
Victor Mote wrote: Yes, I'll be glad to do that. Right now, we have a code freeze pending the upcoming 0.20.5 release, but I will work on getting it applied after the release. If you can, would you also add two attachments to the bug, one being a Photoshop-generated image, and the other being generated by another application, that will illustrate the problem and the solution? Smaller is better as long as the effect is clear. Please identify the generating application in both cases. Thanks, and thanks again for your efforts here. Done! Let me know if I can help any further on this issue. If other applications out there mimic Photoshop and invert the CMYK values, this patch could still not solve all the CMYK/JPEG problems -- but if this is the case, there is no automated solution and users will need the ability to control the inversion manually (or find a tool that will invert the CMYK values previous to inserting them in FOP). Take care, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another website update
Ben Galbraith wrote: Sun's new Java Advanced Imaging I/O Tools 1.0-RC plug-in writes CMYK JPGs in such a way that FOP believes the CMYK sample values are inverted when they are not. This leads to CMYK JPGs looking really, really bad. Is this a problem from JAI's side or from FOP's side? IOW, should FOP be able to tell from the file itself whether to invert or not? Or is Sun writing the image wrong? Or is this a limitation in the JPG format? When I force FOP to interpret the CMYK JPG as not inverted (by modifying the source code), they work as they should. Can we document this issue on the website for posterity? Yes, but I want to understand the issue better first. A likely fix would be to add a configuration option to FOP that forces JPGs to either be inverted or not inverted, regardless of what FOP thinks it should do? The code that presently determines whether or not to invert (JpegImage.java [fop-0_20_2-maintain] 1.1.2.3, 214-215; see also 172-182) is rather approximate. Depending on the answer to my question above, is it possible to make FOP's logic more definite? I would lean more toward such a solution, if it is feasible, than toward a configuration option that would force one result or another for all images in the document. I'd be happy to contribute such a patch, if there is interest from the community / developers. Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Thanks again for your efforts here. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another website update
Victor Mote wrote: Sun's new Java Advanced Imaging I/O Tools 1.0-RC plug-in writes CMYK JPGs in such a way that FOP believes the CMYK sample values are inverted when they are not. This leads to CMYK JPGs looking really, really bad. Is this a problem from JAI's side or from FOP's side? IOW, should FOP be able to tell from the file itself whether to invert or not? Or is Sun writing the image wrong? Or is this a limitation in the JPG format? Alas, we're bumping up against my limitations here. Here's my understanding: The JPG spec. is rather vague when it comes to color spaces, preferring to leave that as an implementation detail. Thus, there's some freedom in how vendors encode color space information with their images. JPEG stores metadata in various markers. One marker, the APPE marker, is used by Adobe to store various data dealing with color space encoding. Other vendors / users have opted to use the Adobe's APPE marker specification to store color space information as well, building on Adobe's work. The problem is that Adobe inverts the CMYK color space values. FOP therefore takes a shortcut and whenever it finds the APPE marker, it assumes that Adobe has written the image and thus the values must be inverted. The code does *not* check if the values are in fact inverted, which in a comment in acknowledges it should. In this case, it would appears that JAI follows what seems to be a popular industry practice and uses the APPE marker to store information about the color space encoding, but does *not* invert the colors and I can only assume correctly records this information in the APPE marker. Thus, the problem we're experiencing. To be fair, it appears that other popular products make the same assumption (such as iText), and to be honest, I might be misunderstanding this issue. Depending on the answer to my question above, is it possible to make FOP's logic more definite? I would lean more toward such a solution, if it is feasible, than toward a configuration option that would force one result or another for all images in the document. I think it is possible to patch FOP to properly detect whether or not to invert the image from the APPE marker values, rather than the presence of the marker. I'm not sure how to do it, yet. I 'spose I should figure it out! Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Sure, I'll start tracking it down in my spare time. Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another website update
Ben Galbraith wrote: I think it is possible to patch FOP to properly detect whether or not to invert the image from the APPE marker values, rather than the presence of the marker. I'm not sure how to do it, yet. I 'spose I should figure it out! Excellent. Do you have any interest in helping us track down the more robust solution (if it exists)? Sure, I'll start tracking it down in my spare time. That is greatly appreciated. It sounds like you have a sizeable head-start (over me anyway) on the details, and my guess is that without your efforts it will be awhile before any of the developers would be able to do much on this. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another website update
Victor Mote wrote: That is greatly appreciated. It sounds like you have a sizeable head-start (over me anyway) on the details, and my guess is that without your efforts it will be awhile before any of the developers would be able to do much on this. I've created a bug in Bugzilla, 21420, which documents this issue. I've attached a patch to that bug which I've tested and appears to solve the problem. In short, it turns out that Adobe CMYK JPG's appear to be the only ones that inexplicably inverse the pixel sample values, and that checking for the Adobe APPE marker is *not* a good way to confirm that Photoshop generated the image, as other applications use the Adobe APPE marker, which has become a sort of ad hoc standard. I changed FOP to check a different region of the file for the text Adobe Photoshop, which does indeed confirm that Photoshop generated the file. Can you facilitate that patch being applied, if such falls within your responsibilities? Thanks! Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
