kinow commented on PR #35: URL: https://github.com/apache/commons-imaging/pull/35#issuecomment-1606054447
>So, for our purposes, should we set the log Level to Level.FINE on the loggers named "org.apache.commons.imaging", "org.apache.commons.imaging.common", and "org.apache.commons.imaging.formats.jpeg"? Specifying exact class names would be way too granular (and generate too much source code) for us. JUL loggers are [hierarchical](https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html), >A Logger object is used to log messages for a specific system or application component. Loggers are normally named, using a hierarchical dot-separated namespace. Logger names can be arbitrary strings, but they should normally be based on the package name or class name of the logged component, such as java.net or javax.swing. (...) If you enable for `org.apache.commons.imaging` then you will enable all the loggers. If you would like to limit FINE log output to a package like jpeg, you can do that too like your example for `formats.jpeg`. >We are basically interested in getting a hint at where the parser encounters an error in the binary file data stream. In other words, where the file starts deviating from the specification, even when the error is recoverable. We would like to get a specification compliance hint. We do not want or need strict specification compliance enforcement. :+1: >I am sorry for not being able to describe more precisely what we would like to see from Commons Imaging. Anyway, thank you for you support. +1 Not a problem at all. I think this is what most users of the library want. In case it helps, what I normally do is try to parse the images with Apache Commons Imaging, then if I get an error, before even trying to tweak the log levels or debugging, I test it with `exiftool` and maybe GIMP. IIRC the command I normally use it `exiftool dump --html $img > output.html && firefox output.html` ? Or something similar that gives me the complete image data separated by segments, metadata, byte information, etc. exiftool is quite good at pointing whether the image is corrupt or if there's some structural errors. If exiftool looks good, but Imaging is not able to parse it, then it could be because we are being too strict regarding the standard (exiftool is a bit more lenient), or we are missing to handle something specified in an Adobe spec extension, or some color space that's not supported/handled, etc. In case you are able to identify that we are missing some logging you can always create a JIRA issue :slightly_smiling_face: just try to attach the test image, code snippet, and as much info as possible. Cheers -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
