Depreciated and troublesome old-style JPEG
Helmut Jarausch
my brand new Kyocera-1028MFP sends a file xxx.tif which disables Gimp
after it has issued the messages
Depreciated and troublesome old-style JPEG compression mode, please
convert to new-style JPEG compression and notify the vendor of writing
software.
And then
Improper call to JPEG library in state 0
On the other hand, an image view like eog has no problems to show the
image.
What am I missing?
Many thanks for a hint,
Helmut.
--
Owen
Well which version of gimp? I am curious why the jpeg plugin is called
when opening a tiff
Owen
Helmut Jarausch
It's the GIT-version.
Helmut.
Floyd L. Davidson
TIFF formatted files can use JPEG compression.
>It's the GIT-version.
>Helmut.
If you are using the 2.7 development source code there
is little point in complaining here about a "bug". It
is a development version! And as such it virtually
always contains code that is new, incomplete, untested
and changing at regular intervals.
For whatever unknown reasons, I've not been able to use
code from the development tree since last July. On my
system clicking the mouse on any dialog box up/down button
to adjust a parameter results in the value repeatedly being
incremented. I download a new version about once a month and
compile it to see what happens, but so far it hasn't been
fixed. I just bide my time and wait...
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
John K. Herreshoff
> Helmut Jarausch <jara...@igpm.rwth-aachen.de> wrote:
>>On Tue, 21 Dec 2010 23:31:18 -0800, Owen wrote:
>>
>>> On Dec 22, 12:48Â am, Helmut Jarausch <jarau...@skynet.be> wrote:
>>>> Hi,
>>>>
>>>> my brand new Kyocera-1028MFP sends a file  xxx.tif which disables Gimp
The 2.7 tarballs work OK. I'm using 2.7.1 and I'm not looking back at 2.6
(yet) There are some bugs in it, but nothing that brings the program down.
John.
--
Using the Cubic at home.
Floyd L. Davidson
>Floyd L. Davidson wrote:
>> Helmut Jarausch <jara...@igpm.rwth-aachen.de> wrote:
>>>On Tue, 21 Dec 2010 23:31:18 -0800, Owen wrote:
>>>> On Dec 22, 12:48� am, Helmut Jarausch <jarau...@skynet.be> wrote:
>>>>> Hi,
>>>>>
Those are pretty old now. A lot of water has gone under the
bridge for the GIT archive code.
Floyd L. Davidson
>
>If you are using the 2.7 development source code there
>is little point in complaining here about a "bug". It
>is a development version! And as such it virtually
>always contains code that is new, incomplete, untested
>and changing at regular intervals.
>
>For whatever unknown reasons, I've not been able to use
>code from the development tree since last July. On my
>system clicking the mouse on any dialog box up/down button
>to adjust a parameter results in the value repeatedly being
>incremented. I download a new version about once a month and
>compile it to see what happens, but so far it hasn't been
>fixed. I just bide my time and wait...
I've just downloaded the current GIT archive, and the above
described problem has been fixed. At this point I haven't
used it enough to say that all is well, but at least it's
past that particular bump in the road.
John K. Herreshoff
> fl...@apaflo.com (Floyd L. Davidson) wrote:
>>
>>If you are using the 2.7 development source code there
>>is little point in complaining here about a "bug". It
>>is a development version! And as such it virtually
>>always contains code that is new, incomplete, untested
>>and changing at regular intervals.
>>
>>For whatever unknown reasons, I've not been able to use
>>code from the development tree since last July. On my
>>system clicking the mouse on any dialog box up/down button
>>to adjust a parameter results in the value repeatedly being
>>incremented. I download a new version about once a month and
>>compile it to see what happens, but so far it hasn't been
>>fixed. I just bide my time and wait...
>
> I've just downloaded the current GIT archive, and the above
> described problem has been fixed. At this point I haven't
> used it enough to say that all is well, but at least it's
> past that particular bump in the road.
>
Floyd, I'm totally dumb about git. I want to checkout 2.7.1, but when I
start git clone git://git.gnome.org/gimp, I get the impression that I'm
going to download everything on the server, rather than just 2.7.1. Can you
tell me how to get just 2.7.1?
TIA.
John K. Herreshoff
Nevermind. I'm still mostly dumb about git, but git clone ... just
downloaded 2.7.1, which I'm now building.
Floyd L. Davidson
>>
>> start git clone git://git.gnome.org/gimp, I get the impression that I'm
>> going to download everything on the server, rather than just 2.7.1. Can
>> you tell me how to get just 2.7.1?
>>
>> TIA.
>>
>> John.
>>
>
>Nevermind. I'm still mostly dumb about git, but git clone ... just
>downloaded 2.7.1, which I'm now building.
That's good... because I'm equally dumb about git. I've
got about two things figured out about it, and clone is
one of them. I've got a script that I use, which allows
either updating an existing archive or building a
completely new one. That's it.
I've discovered the latest source code requires use of a
new API for Scheme and Python scripts. All of the
gimp-drawable-* functions have been replaced with a new
set named gimp-item-*. That's fine, except at this
point I haven't been able to figure out how to get an
"item", as opposed to a "drawable" (an image or a
layer). Hence none of my Python scripts will work, and
none of the various distributed Scheme scripts work
either.
I'm still looking for an example of a Python script that
someone else has built for the latest 2.7 code in order
to get an idea what has to be done differently. One
thing is very clear though, when they do release it as
2.8 there will have to be a huge scramble to update all
the many scripts!
John K. Herreshoff
I got it up and running, and it was throwing error messages about something
having changed in ufraw, and of course it choked on the python script that I
use, so I'm back to 2.7.1 for now. I'd guess that they will just run a
script on all of the plugins to change what needs to be changed and Udi will
make updates to ufraw when necessary.
I'm actually liking the single window mode as it keeps the floating windows
around when they are used. It beats what I had with PSP-4 and -7 back in
the windoze daze. Now I have to decide whether I want to replace the
1600x1200 monitor that I have now with a 1920x1200. The extra 320
horizontal pixels would come in handy with the single window mode.
Floyd L. Davidson
>Floyd L. Davidson wrote:
>> "John K. Herreshoff" <No...@Not.here> wrote:
>> I've discovered the latest source code requires use of a
>> new API for Scheme and Python scripts. All of the
>> gimp-drawable-* functions have been replaced with a new
>> set named gimp-item-*. That's fine, except at this
>> point I haven't been able to figure out how to get an
>> "item", as opposed to a "drawable" (an image or a
>> layer). Hence none of my Python scripts will work, and
>> none of the various distributed Scheme scripts work
>> either.
>>
>> I'm still looking for an example of a Python script that
>> someone else has built for the latest 2.7 code in order
>> to get an idea what has to be done differently. One
>> thing is very clear though, when they do release it as
>> 2.8 there will have to be a huge scramble to update all
>> the many scripts!
>>
>
>I got it up and running, and it was throwing error messages about something
>having changed in ufraw, and of course it choked on the python script that I
>use, so I'm back to 2.7.1 for now. I'd guess that they will just run a
>script on all of the plugins to change what needs to be changed and Udi will
>make updates to ufraw when necessary.
I don't use the interaction between GIMP and UFRAW (which
I use only standalone). Hence I'm not sure what might be
going on there.
The change in the API for scripts is interesting. At
this point it appears that the interface to Python is
simply broken and it is not possible to call either the
new functions or the old ones being replaced. Until the
maintainers fix it there isn't any way to make most
Python scripts work.
But yes, once that is fixed it will apparently be easy
enough to use a script to fix most of the resulting
changes. It won't be able to get everything, and it
won't be able to include use of the change in
functionality. It seems that layers, masks, and so on
are going to be able to be grouped together and operated
on as a unit. For example made visible or not with a
single command. That might be the start of adding
"adjustment layers" to GIMP.
However, for now... once again it is back off to the
last version that works; and then wait patiently.
Last thing I saw suggested they were hoping to get 2.8 out
the door in the first half of 2011, so I do expect all these
different little nagging things to be addressed soon.
>I'm actually liking the single window mode as it keeps the floating windows
>around when they are used. It beats what I had with PSP-4 and -7 back in
>the windoze daze. Now I have to decide whether I want to replace the
>1600x1200 monitor that I have now with a 1920x1200. The extra 320
>horizontal pixels would come in handy with the single window mode.
I've been using dual montors for years, and have never
used single window mode. I guess that's a "Windows
user" holdover that you might want to try getting over!
It's a carry over from MS Windows originating from a
single user single tasking system where each program
controlled the whole screen. Unix of course started
life with multiple users and tasks, so the very idea
that an app controls the whole screen is foreign. The
way users learn to manage their screen is different as a
result. (For example, I almost always have programs
from three different boxes displaying on my screen at
all times. It's not just different apps, it's whole
different networks.)
Ilya Zakharevich
>>I'm actually liking the single window mode as it keeps the floating windows
>>around when they are used. It beats what I had with PSP-4 and -7 back in
>>the windoze daze. Now I have to decide whether I want to replace the
>>1600x1200 monitor that I have now with a 1920x1200. The extra 320
>>horizontal pixels would come in handy with the single window mode.
>
> I've been using dual montors for years, and have never
> used single window mode. I guess that's a "Windows
> user" holdover that you might want to try getting over!
No. AFAIK, the SWM-for-GIMP is a holdover of brain-damaged design of
X11 windowing. The GIMP developers do not have resources to make
multiple-window mode work "as desired", so they switch to code which
does not involve interaction with WM. (And given that "windowing"
part of X11 interface is not documented, I do not see how they hoped
to make it work...)
> It's a carry over from MS Windows originating from a
> single user single tasking system where each program
> controlled the whole screen. Unix of course started
> life with multiple users and tasks
Again, you make it the opposite to the actual facts. Unix was
designed with single-user single-task mentality (this is why IPC APIs
are so silly). Windows started as single-user multiple-tasks - it was
just very badly managed at the start (and people are eating the
backward compatibility consequences).
Ilya
Floyd L. Davidson
>On 2010-12-24, Floyd L. Davidson <fl...@apaflo.com> wrote:
>>>I'm actually liking the single window mode as it keeps the floating windows
>>>around when they are used. It beats what I had with PSP-4 and -7 back in
>>>the windoze daze. Now I have to decide whether I want to replace the
>>>1600x1200 monitor that I have now with a 1920x1200. The extra 320
>>>horizontal pixels would come in handy with the single window mode.
>>
>> I've been using dual montors for years, and have never
>> used single window mode. I guess that's a "Windows
>> user" holdover that you might want to try getting over!
>
>No. AFAIK, the SWM-for-GIMP is a holdover of brain-damaged design of
>X11 windowing. The GIMP developers do not have resources to make
>multiple-window mode work "as desired", so they switch to code which
>does not involve interaction with WM. (And given that "windowing"
>part of X11 interface is not documented, I do not see how they hoped
>to make it work...)
That is hilarious. The multiple-window mode works exactly as
desired, and has from day one. The single window mode was an
add on when the program was ported to Windows.
>> It's a carry over from MS Windows originating from a
>> single user single tasking system where each program
>> controlled the whole screen. Unix of course started
>> life with multiple users and tasks
>
>Again, you make it the opposite to the actual facts. Unix was
>designed with single-user single-task mentality (this is why IPC APIs
>are so silly). Windows started as single-user multiple-tasks - it was
>just very badly managed at the start (and people are eating the
>backward compatibility consequences).
And that is just plain silly.
Get yourself a good book on the origins of those two
OS's. Or use google. The UNIX kernel, for example, was
multitasking by design before any code was ever written!
It was intended to replace the then under development OS
called Multics. Windows came from MS-DOS, which wasn't
even really an OS but actually just a program loader
(originally a translation of CP/M-80 to 8086 assembler),
where each individual program controlled virtually all
of the computer's resources.
This is all very well known and documented history.
Hence there is no point in posting such offbase
statements.
Jernej Simončič
> That is hilarious. The multiple-window mode works exactly as
> desired, and has from day one. The single window mode was an
> add on when the program was ported to Windows.
Obviously you have no idea what most users want - single window mode has
been one of the most requested features practically forever. Also, it
wasn't added when GIMP was ported to Windows 10 years ago - it's only
available in the bleeding edge not-for-everyday-use versions - and it's not
even completely finished yet.
--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
Floyd L. Davidson
>on Fri, 24 Dec 2010 18:13:37 -0900, Floyd L. Davidson wrote:
>
>> That is hilarious. The multiple-window mode works exactly as
>> desired, and has from day one. The single window mode was an
>> add on when the program was ported to Windows.
>
>Obviously you have no idea what most users want - single window mode has
>been one of the most requested features practically forever. Also, it
>wasn't added when GIMP was ported to Windows 10 years ago - it's only
>available in the bleeding edge not-for-everyday-use versions - and it's not
>even completely finished yet.
What has "what most users want" got to do with what I
said?
My point was that it was added *for* user who are used
to Windows, and came *after and because* GIMP had been
ported to Windows. The fact that it isn't even complete
yet just proves my point!
GIMP was originally developed and designed for X11, and
has virtually always worked well in terms of what the
designers intended for that environment. Generally
those users who've had extensive X11 experience in a
unix environment don't want to be shackled (and that is
indeed exactly how we view it) with the trappings of the
Windows environment.
The vast majority of Windows users, who generally are
not computer techies, just want everything to be what
they are familiar with. *That* *is* *not*
*unreasonable* *on* *their* *part*. But it is just
hilarious to hear them claim is is the "right" way, just
because it is the mechanism Bill Gates used to make a
lot of money. Gates is as good as it gets at making
money. Unix was designed by guys where are the best at
making Operating Systems (and windowing systems). Take
your choice, but there isn't really much debate about
which is technically better.
Michael Schumacher
> One thing is very clear though, when they do release it as
> 2.8 there will have to be a huge scramble to update all
> the many scripts!
Note that the old-style functions are still there, all that happens is
deprecation warnings.
All future 2.x versions will keep them around - API compatibility is
maintained through a major version.
Regards,
Michael
Floyd L. Davidson
>On 24 Dez., 04:25, fl...@apaflo.com (Floyd L. Davidson) wrote:
>
>> One thing is very clear though, when they do release it as
>> 2.8 there will have to be a huge scramble to update all
>> the many scripts!
>
>Note that the old-style functions are still there, all that happens is
>deprecation warnings.
Well, that's not quite true! But to begin with, nobody
really wants to get deprecation warnings anyway. So
even if that were the only problem it would be enough.
But the old functions, according to the help and given
what happens when they are used, require an "item"
rather than a "drawable". For example from Python a
call to gimp_drawable_set_name now requires the first
argument to be a type "item". There seems to be no way
to generate such a thing in Python yet. I'm assuming
that is a problem with the Python interface because it's
working with Scheme scripts, and I also assume it will
soon enough be corrected. But in the mean time it is
impossible to change the name of a layer.
>All future 2.x versions will keep them around - API compatibility is
>maintained through a major version.
That's true, and it will eventually (when the kinks are
straightened out) make things work well. But dealing
with the bleeding edge of the development code is always
fraught with incomplete changes. It's always sort of a
hunt and peck operation to pick out a relatively
"stable" snapshot to use for awhile.
Michael Schumacher
> Michael Schumacher <schu...@gmx.de> wrote:
>>On 24 Dez., 04:25, fl...@apaflo.com (Floyd L. Davidson) wrote:
>>
>>> One thing is very clear though, when they do release it as
>>> 2.8 there will have to be a huge scramble to update all
>>> the many scripts!
>>
>>Note that the old-style functions are still there, all that happens is
>>deprecation warnings.
>
> Well, that's not quite true! But to begin with, nobody
> really wants to get deprecation warnings anyway. So
> even if that were the only problem it would be enough.
>
> But the old functions, according to the help and given
> what happens when they are used, require an "item"
> rather than a "drawable".
More precisely, they require an item ID. Valid examples would be:
gimp.pdb.gimp_drawable_set_name(2, 'Foo')
gimp.pdb.gimp_item_set_name(2, 'Bar')
This should work on a newly opened image in a new gimp session, and
should change the name of the Background layer. In a script, the 2
should be replaced by a variable holding the id of the drawable.
But in this case, I wouldn't use the PDB detour - the Drawable class has
a name member, so changing the name of a layer in an image can be done
as follows:
gimp.image_list()[0].layers[0].name = 'Baz'
HTH,
Michael
--
GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp
Plug-ins > http://registry.gimp.org | .de: http://gimpforum.de
Floyd L. Davidson
>fl...@apaflo.com (Floyd L. Davidson) writes:
>
>> Michael Schumacher <schu...@gmx.de> wrote:
>>>On 24 Dez., 04:25, fl...@apaflo.com (Floyd L. Davidson) wrote:
>>>
>>>> One thing is very clear though, when they do release it as
>>>> 2.8 there will have to be a huge scramble to update all
>>>> the many scripts!
>>>
>>>Note that the old-style functions are still there, all that happens is
>>>deprecation warnings.
>>
>> Well, that's not quite true! But to begin with, nobody
>> really wants to get deprecation warnings anyway. So
>> even if that were the only problem it would be enough.
>>
>> But the old functions, according to the help and given
>> what happens when they are used, require an "item"
>> rather than a "drawable".
>
>More precisely, they require an item ID. Valid examples would be:
>
>gimp.pdb.gimp_drawable_set_name(2, 'Foo')
>gimp.pdb.gimp_item_set_name(2, 'Bar')
Neither of those work. If the original call was this:
pdb.gimp_drawable_set_name(layer, imagename)
Then either of those functions will error, saying that
layer is not the right parameter type. If an integer is
used, as in your examples, the error is that the
parameter is out of range.
>This should work on a newly opened image in a new gimp session, and
>should change the name of the Background layer. In a script, the 2
>should be replaced by a variable holding the id of the drawable.
>
>But in this case, I wouldn't use the PDB detour - the Drawable class has
>a name member, so changing the name of a layer in an image can be done
>as follows:
>
>gimp.image_list()[0].layers[0].name = 'Baz'
Success! That works. I had tried accessing it via the
image_list, but I don't have anything explaining what
the structure actually is, and never managed to hit the
right syntax for a name.
Unfortunately, this appears to all for naught. I backed
out of the newer version to code downloaded back in May,
and recompiled it rather than just re-installed the
previous compile. I had to back out of the newer
versions of GTK+ libraries too. Unfortunately I can't
seem to re-create whatever the same environment was, and
now this latest version of GIMP does the same thing
other newer versions have done previously.
When a slider is moved (for example in the
Image->Color->Brightness and Contrast dialog box) it
won't stop. Clicking on the increment or decrement
causes it to start changing and go all the way to the
limit. Clicking on the slider does the same.
Oddly, plugins like the UnsharpMask tool don't do that,
but the builtins do. It is certainly something to do
with the way the GTK+ libraries are
configured/installed/interfaced, but I'm not able to
track that down. Given the fact that plugins work and
builtins don't, I'm assuming the actual fault is
something in the GIMP code as opposed to the GTK+ code,
but that isn't certain.
Michael Schumacher
> Michael Schumacher <schu...@gmx.de> wrote:
>>gimp.pdb.gimp_drawable_set_name(2, 'Foo')
>>gimp.pdb.gimp_item_set_name(2, 'Bar')
>
> Neither of those work. If the original call was this:
>
> pdb.gimp_drawable_set_name(layer, imagename)
>
> Then either of those functions will error, saying that
> layer is not the right parameter type. If an integer is
> used, as in your examples, the error is that the
> parameter is out of range.
Yeah, that's why I wrote "should work on a new image". If the drawable
ID of the layer isn't 2, then it will fail with the out of range error,
because this drawable ID isn't assigned.
The layer variable in your exyample is actually a Drawable object, I
guess? Have you tried to use its id in this case?
>>gimp.image_list()[0].layers[0].name = 'Baz'
>
> Success! That works. I had tried accessing it via the
> image_list, but I don't have anything explaining what
> the structure actually is, and never managed to hit the
> right syntax for a name.
Python's dir() command is useful for that. For example,
dir(gimp) lists all members of the gimp module,
dir(gimp.Drawable) performs the same for the Drawable class.
The Python console (http://docs.gimp.org/en/gimp-filters-python-fu.html)
is really helpful for those quick interactive tests.
Floyd L. Davidson
>fl...@apaflo.com (Floyd L. Davidson) writes:
>> Michael Schumacher <schu...@gmx.de> wrote:
>
>>>gimp.pdb.gimp_drawable_set_name(2, 'Foo')
>>>gimp.pdb.gimp_item_set_name(2, 'Bar')
>>
>> Neither of those work. If the original call was this:
>>
>> pdb.gimp_drawable_set_name(layer, imagename)
>>
>> Then either of those functions will error, saying that
>> layer is not the right parameter type. If an integer is
>> used, as in your examples, the error is that the
>> parameter is out of range.
>
>Yeah, that's why I wrote "should work on a new image". If the drawable
>ID of the layer isn't 2, then it will fail with the out of range error,
>because this drawable ID isn't assigned.
It just fails. Or, at least for a range of 0 through 3
or 4. I assumed, from my results, that the integers
weren't sequential from 0 up, though by that time in the
script I'm working with there have been a few layers
added and deleted, so I might just be that I didn't try
high enough. Regardless, what I needed was to find the
correct ID for the one remaining layer.
>The layer variable in your exyample is actually a Drawable object, I
>guess? Have you tried to use its id in this case?
Yes and yes. It always complains that it is the wrong
type. The "Help" says they are all type INT32, but
obviously in Python it's more than that.
>>>gimp.image_list()[0].layers[0].name = 'Baz'
>>
>> Success! That works. I had tried accessing it via the
>> image_list, but I don't have anything explaining what
>> the structure actually is, and never managed to hit the
>> right syntax for a name.
>
>Python's dir() command is useful for that. For example,
>
>dir(gimp) lists all members of the gimp module,
>dir(gimp.Drawable) performs the same for the Drawable class.
>
>The Python console (http://docs.gimp.org/en/gimp-filters-python-fu.html)
>is really helpful for those quick interactive tests.
That's very useful.
My biggest problem is that I'm not a Python programmer, and
only mess with it on the rare occasions (such as when various
things in GIMP become depricated). I have usually forgotten
what little I knew... :-)
On the other problem, with the sliders taking of by
themselves, I've found a work around. It's not really a
fix, but it'll do. Seems that it works just fine if the
Image->View->Use GEGL option is selected. It turns out
getting that to be enabled by default wasn't as easy as
changing just some option somewhere, but I've now got a
patch that adds a little code to three files and makes
using GEGL for all operations the default.
(Image->Colors->Use GEGL is also defaulted to true.)
So right now it looks like I'm happy for the immediate
future!
Thank you for the pointers above, because that wasn't
something I would ever have figured out on my own.
Michael Schumacher
> Michael Schumacher <schu...@gmx.de> wrote:
>>The layer variable in your exyample is actually a Drawable object, I
>>guess? Have you tried to use its id in this case?
>
> Yes and yes. It always complains that it is the wrong
> type. The "Help" says they are all type INT32, but
> obviously in Python it's more than that.
The full example, taken directly from GIMP's Python console:
>>> gimp.image_list()[0].layers[0].ID
2
>>> gimp.pdb.gimp_drawable_set_name(2, 'Foo')
>>> gimp.pdb.gimp_item_set_name(2, 'Bar')
>>> gimp.pdb.gimp_drawable_set_name(gimp.image_list()[0].layers[0].ID, 'Foo')
>>> gimp.pdb.gimp_item_set_name(gimp.image_list()[0].layers[0].ID, 'Bar')
>>>
Again, this is a newly opened image in a new gimp session, so the
drawable ID of the background layer is the usual 2.