GIMP 2.99.6 Released But Still No Idea When GIMP 3.0 Will Be Ready

[idash]

It's ironic that GIMP is basically the last major program to be ported to the latest version of the "GIMP Tool Kit", and GTK3 is technically not even the latest anymore.
Regardless, I'm using the beta version anyway and it seems to be in a good shape, so I guess it's not gonna be too long before the stable release.

Also looking forward to the Adjustment Layers equivalent, but it sounds like it's gonna a while before that gets implemented.

[microcode]

The amazing thing about PNG is that they go to all the trouble of having a unit enum in the physical resolution field.... and only have one unit, which is not even a common unit of resolution (pixels per meter) and which can not be converted losslessly in a round trip... and in the API documentation they even include the conversion ratio for inches to micrometers, but completely miss that the field can't hold common resolutions like 300dpi, 600dpi, and 150dpi correctly.

It's so dumb.

[MadeUpName]

The insane PNG file sizes are the killer for me. They make TIFF look like JPEGs.

[billyswong]

The amazing thing about PNG is that they go to all the trouble of having a unit enum in the physical resolution field.... and only have one unit, which is not even a common unit of resolution (pixels per meter) and which can not be converted losslessly in a round trip... and in the API documentation they even include the conversion ratio for inches to micrometers, but completely miss that the field can't hold common resolutions like 300dpi, 600dpi, and 150dpi correctly.

It's so dumb.

Not to mention those stupid abuse of some photo editors dumping a default "72dpi" to digital/screen-use image files. Unless an image is to be printed out, neither "dpi" nor "pixels per meter" make sense to a file. Projectors don't have a fixed physical size of their pixels. The only thing that matters is if they are projecting "hiDPI", i.e. choosing a particular choice of image and text resolution in document and UI display compared to the old standard. For example, image A may be intended to companion with 100% Ui, image B for 150% UI, image C for 200% UI etc.

Even for printing, it still make no sense for a traditional photo taken by camera to embed a physical size, as photos are traditionally printed to photo papers of whatever size the users want. There is no "correct" photo paper size for a film. The only case that one may "want" dpi communicated is professional / commercial printing. But for them, what would have been a lot more useful is to embed the margin or bleeding (in unit of pixels) to the file, such that it won't need to communicate out of band or drawing the mark within the image. Some shops may want those marks drawn in a particular way and some shops may not want those marks be drawn at all. Some shops may need almost no bleed and some shops may want a lot. If there is a standardized way to communicate the margin / bleeding as image metadata, the same file can be sent to different shops and print into products of different sizes, or just showing it in digital display, with no modification.

[quaz0r]

how has a new project not popped up by now to be the latest modern gimplike program? this is literally like if netscape navigator was still the main web browser available for lunix. seriously wtf. next theyll be looking for cobol programmers or something just to keep chucking this dead horse a few more feet down the road one painful centimeter at a time

[DMJC]

how has a new project not popped up by now to be the latest modern gimplike program? this is literally like if netscape navigator was still the main web browser available for lunix. seriously wtf. next theyll be looking for cobol programmers or something just to keep chucking this dead horse a few more feet down the road one painful centimeter at a time

OK Guy, go write a better photoshop and go get all their marketshare. Oh wait, you can't because of momentum. It would take years to rebuild what GIMP has done, you could maybe take Krita and port the interface over to a GIMP knock off interface. But otherwise you're talking probably 10 years of work.

[hrkristian]

how has a new project not popped up by now to be the latest modern gimplike program? this is literally like if netscape navigator was still the main web browser available for lunix. seriously wtf. next theyll be looking for cobol programmers or something just to keep chucking this dead horse a few more feet down the road one painful centimeter at a time

Good luck with that.

Image mapulation is not an easy thing to just throw together.

That's not even getting into the absolute nightmare of navigating all the patents Adobe are hoarding.
There's stuff you cannot legally do in the western world because of ridiculous patents.

We don't even have a proper and well-maintained Paint equivalent on Linux. That should tell you all you need to know.
Edit: I checked out Pinta and it seems it's hard its first update in 5 years, maybe there's hope there after all.

[mavit]

this is literally like if netscape navigator was still the main web browser available for lunix.

It pretty-much is; it's just that it's called Firefox nowadays.

[microcode]

Not to mention those stupid abuse of some photo editors dumping a default "72dpi" to digital/screen-use image files. Unless an image is to be printed out, neither "dpi" nor "pixels per meter" make sense to a file. Projectors don't have a fixed physical size of their pixels. The only thing that matters is if they are projecting "hiDPI", i.e. choosing a particular choice of image and text resolution in document and UI display compared to the old standard. For example, image A may be intended to companion with 100% Ui, image B for 150% UI, image C for 200% UI etc.

Even for printing, it still make no sense for a traditional photo taken by camera to embed a physical size, as photos are traditionally printed to photo papers of whatever size the users want. There is no "correct" photo paper size for a film. The only case that one may "want" dpi communicated is professional / commercial printing. But for them, what would have been a lot more useful is to embed the margin or bleeding (in unit of pixels) to the file, such that it won't need to communicate out of band or drawing the mark within the image. Some shops may want those marks drawn in a particular way and some shops may not want those marks be drawn at all. Some shops may need almost no bleed and some shops may want a lot. If there is a standardized way to communicate the margin / bleeding as image metadata, the same file can be sent to different shops and print into products of different sizes, or just showing it in digital display, with no modification.

The main way that physical resolution is used is in scanning and pre-print, both cases where resolution is specified on devices in DPI in almost all machines.