StefanOltmann / exif-viewer

Free online EXIF Viewer (made with Kotlin/WASM)
http://stefan-oltmann.de/exif-viewer
GNU Affero General Public License v3.0
29 stars 1 forks source link

Suggestion - don't cut the PNG `tEXt` chunk #9

Closed Nadahar closed 8 months ago

Nadahar commented 8 months ago

I really like your viewer, especially the hex viewer part.

The very popular https://github.com/AUTOMATIC1111/stable-diffusion-webui puts the generation parameters in the tEXt chunk and this far it's hard to find software that will display it (outside the stable-diffusion-webui itself). I also think the tEXt chunk is used by other ML image generators.

Ideally this should apply to the iTXt chunk as well, and if your really want to "take it all the way" remember that this one is UTF-8 encoded πŸ˜‰

For now I've just been using a normal hex viewer for this, but it's more convenient using something that understand "chunks".

Here is an example image generated by me so that it's safe to use:

00041-257608607

StefanOltmann commented 8 months ago

Thank you, I will look into it. πŸ™‚

StefanOltmann commented 8 months ago

@Nadahar

The text in your provided sample file is rather extensive, and viewing it in the HEX format would result in a lengthy display. The purpose of the file structure view is to offer a quick overview of the file, facilitating the identification of potential issues. I created this tool to assist in analyzing problematic files sent by users of Ashampoo Photos.

Considering your specific use case, I believe incorporating a dedicated box to display the content of PNG text chunks, particularly those lacking semantic interpretation as EXIF, IPTC, or XPM, would be more beneficial. To address this, I have introduced a new box exclusively designed for that purpose.

What are your thoughts on this enhancement? :)

image.png

Nadahar commented 8 months ago

@StefanOltmann That is absolutely perfect and a much better solution. You even parsed the "key" (parameters) as well πŸ‘

I was thinking of a solution like that, but felt that it was "way too much to ask" for this "corner case use". I thus felt that removing the limit for the chunk(s) in question was more reasonable.

I did consider trying to make a PR with a new "box" just like you have made - but I was unable to get the Kotlin plugin for Eclipse to install on my Eclipse version. There's a lot of configuration in place to make my tools work like I want them to, so I'm very hesitant to upgrade Eclipse when it's working like I want it to πŸ˜‰ Thus, I didn't go through with it - and I don't know if I would have succeeded either as I'm completely unfamiliar with Kotlin.

Nadahar commented 8 months ago

I see that this is already "live", and it looks perfect to me. A big thank you πŸ‘

StefanOltmann commented 8 months ago

@Nadahar

I'm delighted that you like it! πŸ™‚

Regarding the issue with the Kotlin plugin for Eclipse, I faced a similar challenge when transitioning from being a Java developer on Eclipse for 15 years to adopting Kotlin three years ago. While Eclipse is an excellent IDE, its support for Kotlin is not good. That led me to switch to IntelliJ IDEA, which, despite occasional quirks, offers more features, including helpful linters.

If you want to learn Kotlin, I highly recommend reading "Kotlin in Action", a fantastic book authored by Kotlin developers specifically for Java developers. It provides a clear understanding of how Java concepts translate into Kotlin and illustrates the equivalent Kotlin code for various Java constructs.

Personally, I've grown to adore Kotlin! ❀️ It addresses many of Java's shortcomings, boasts a more concise syntax, and maintains compatibility with every Java library on the JVM. Additionally, Kotlin Multiplatform fulfills Java's longstanding "Run everywhere" promise. By now seeing somewhere Java code I have this strong gut feeling that Iβ€˜m looking at legacy code someone should port to Kotlin. I felt this way working on metadata-extractor yesterday. πŸ˜„

The motivation behind porting the metadata component of Apache Commons Imaging to Kotlin (Ashmapoo Kim) was to utilize this library across all platforms (including iOS, native, web, etc.). A similar approach was taken with the Adobe XMP Core port. I would have preferred to port metadata-extractor, because Apache Commons Imaging supports less formats and has quite complicated code, but I choose that for its write support. I don’t believe that metadata-extractor will ever see write support. Nonetheless, I've incorporated some features and derived ISO BMFF code from the metadata-extractor implementation in the meantime, so Ashampoo Kim improved over Apache Commons Imaging. Also the original has some bugs they refuse to fix.

I express a wish for more Java libraries to transition to Kotlin, as Kotlin's Multiplatform capabilities make the code effortlessly run everywhere. Although I've never been a web developer due to my aversion to JavaScript, Kotlin's support for WASM enabled me to seamlessly run my library in the browser with minimal effort.

In essence, Kotlin is simply awesome. πŸ™‚

StefanOltmann commented 8 months ago

I see that this is already "live"

Yes, for WASM apps GitHub pages can be used. Every commit deploys a new version. πŸ™‚ That’s a great feature.

Nadahar commented 8 months ago

I know Eclipse keeps falling "further and further behind" and I've seen many recommendations to move to IntelliJ (for a multitude of reasons). This far I've resisted, for a couple of reasons. First because I don't want to end up depending on a "pay to play toolset" where they can rewrite the rules at any time, making you essentially forced to buy/rent/whatever. Second, I just love Eclipse for Java - I think it's brilliant. I don't use Eclipse for other languages, I use VS Code for "light stuff", Notepad++ in really simple cases, Lazarus for Pascal, VS for C/C++ etc. Whenever I'm not in Eclipse I feel really lost because of all the stuff I use "all the time" that I find so essential. I'm thinking of the "intimate knowledge" of the code, the brilliant refactoring, formatting and reference lookups, "advanced" regex search and replace, the plugins etc. Other IDEs have similar features, but they all feel "very rudimentary" and lacking whenever I try to use them.

I wasn't really planning to switch to Kotlin - and I'm sure you're right that it's better to find a more suitable IDE if that was the case. I was just thinking that I could use Eclipse to modify the existing code a bit - which usually isn't too difficult (although I have no idea if some special "challenges" would present themselves in this case).

I'm rather invested in a quite large Java project, even though I've done very little development for the last couple of years, it kind of "locks me in" to Java for the foreseeable future. That said, I've never really liked Java that much (primarily because of the lack of low-level, optimized abilities) - but like anything, when you have worked enough with something you get really familiar with it and it "feel better" than other tools where you are less capable.

In some ways I'm sorry that I didn't go for C++ many years ago, as despite all it's "challenges", I think that would be the language that would best fit my "requirement". However, every time I touch it, I'm repelled by the crazy type system, the lack of documentation, the poor IDEs, the complete lack of any "consistent" coding style, the terrible string handling etc.

So, while I'm sure Kotlin has many nice properties, it's not in the cards for me at this time. That said, WASM seems awesome (I despise JavaScript too), so if I ever want to do some web stuff, I'll strongly consider looking more into it.