Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
First the prelim: Jomic is fantastic. THANK YOU. Question: In the year(s?) I've been using Jomic, a cbr file will occasionally open with image colors effectively reversed- displaying as pseudo "negatives". I haven't been able to isolate the reason for this. My solution has been to unpack the file and view the jpegged pages individually, which sidesteps the display problem. But even after re-zipping the file, the images still display as negatives. So, uh, why am this be?
Jack (OS X Leopard, MacPro with stuff)
Are the images in the CBR encoded as TIFF?
There have been issues with Java's TIFF codec, for instance Sun bug #4511413 and Sub bug #4906850. And from the bug descriptions its not quite clear if all of them have been resolved.
I've also noticed inverse images from time to time, though mostly when reading PDF. Internally, PDF documents often use TIFF to embed images.
Nope- they are jpgs, alright. I don't think it's something to do with Jomic specifically, however. When I open them in Zipeg, for instance, they also preview as negatives within Zipeg. However, AFTER the file has been unpacked, those same jpg images display correctly.
But then, if I re-compress that same set of images / folder as a ZIP file (using the built-in OS X "compress" menu function)-, once again, the images display in the *negative*. S'weird.
oh, and same deal running Snow Leopard and now Lion.
I found these posted in Apple's support discussions- which sounds like a similar issue- at least, the same problem- and is pegged to a display problem when jpegs are in CMYK rather than RGB colorspace. But the jpegs I'm looking at are already in RGB, not CMYK. So still stymied. I'll keep looking…
Answer- I think I figured it out, it's caused by JPEGS with nonspecific / unassigned RGB color profiles. The CBR files displaying as "negatives" have jpegs that were created with uncalibrated color spaces. They are RGB, not CMYK, but don't have specifically-assigned color spaces. Opening these individual jpegs in Photoshop (CS5) titles them as " RGB/8# " rather than " RGB/8 " - and their file info (again, in Photoshop CS5) notes them as "Color Space: Uncalibrated" via the "File Info" function, under the "Camera Data" tab.
So it appears the way to fix this would be to open the individual JPEGs, then re-save them with assigned color spaces for them to appear correctly in Jomic. I'm guessing this is a Mac OS X - only thing and that Windows does not have this problem-
Just tested in Jomic, and yes, after embedding the first JPEG with an sRGB profile while leaving the remainder as-is, the re-compressed cbr file displays the first jpeg correctly, while the remainder are still displaying as negatives.
Thanks for your great analysis! I wonder if there is a way to recognize such JPEG images in Java after reading. It shouldn't be too difficult to add a default color space programmatically.
good question, I'm wondering the same thing, obviously, but sadly have 0 knowledge about Java, etc. I did a google search on your "recognize color profile JPEG images in Java" and the first result I got was this (see link), which might point towards an eventual solution- maybe it has something to do with the process of "flattening", wtf idk ha. Stackoverflow.com in general seems to be a popular place for these kinds of discussions
Oh- I just had a thought- maybe an alternate / better solution would be to have a default color profile *assigned* (or effectively swapped out) by the Jomic app itself, rather than read from the file- that way it would't matter whether or not a color profile wasn't already embedded, or incorrect, or whatever. If that is possible- again, I have no clue.